I can dedicate a bit to it if someone makes a Jira so i completely
understand the issue.
- Houston
On Tue, Aug 13, 2024 at 8:29 PM Jason Gerlowski
wrote:
> Hi David,
>
> Maybe this deserves its own thread?
>
> I also see the behavior you described - the openApiGenerate task
> appears to regener
Hey all,
It's time once again to start thinking ahead to this month's virtual meetup!
As always, two questions:
1. Does anyone have an interest in organizing? Duties are light but
it's an important job. I'm happy to organize by default if there
aren't any volunteers in the next day or two. (A
Hi David,
Maybe this deserves its own thread?
I also see the behavior you described - the openApiGenerate task
appears to regenerate on each build. Perhaps this is "expected" when
using the task's "cleanOutput=true" setting? Or maybe the task just
doesn't track "inputs" the way Gradle tasks typ
> It's not just that.
Indeed, I saw that you also added spotless and tidy to the gradle build
files and provided a gradle plugin for the dependency checks. I definitely
and unintentionally talked down your work in that PR, sorry for that.
I started a couple weeks ago a migration without knowing t
Hi Christos,
I'd like to follow the same approach in Solr, as it would allow us to sync
> some of the dependencies and keep all versions in one file.
>
It's not just that. It's also a switch from palantir's dependency
resolution mechanism to gradle's.
I think it's a good direction, because palant
If I do "gw compile" twice without doing anything, we should expect a
fully up-to-date gradle build. Instead, openApiGenerate outputs a
bunch of stuff (perhaps it's our most noisy task?) including that it
cleaned the output and did generation. My expectation is that it
should do nothing and idea
It could be discussed at our next community meetup. Or a dedicated
one for this topic if it will dominate.
On Tue, Aug 13, 2024 at 12:21 PM Tim Allison wrote:
>
> All,
>
> Let me know how I can help. If there’s any way we can move people to
> tika-pipes, that’d be best.
>
> We have a Solr emitte
All,
Let me know how I can help. If there’s any way we can move people to
tika-pipes, that’d be best.
We have a Solr emitter already in Tika, but that might add too much
complexity for people just beginning.
I’m strongly in favor of extricating Tika’s dependencies from Solr’s for
all of the reas
Thanks for offering to help port this!
I noticed that change is Lucene 10 only; I think a build change of
that magnitude should also be Solr 10 only, thus the main branch. We
might want to delay such a change for another release or so in order
for dependency backports to 9 to go smoothly. There'
I am not involved with SOLR-17334 PR-2527 (Coordinator node stuff). I
took a look and I don't think you should hold up the release over
this. It's an enhancement, not a bug, despite its title. The PR is
apparently not ready; there is supposedly a draft PR that I don't see.
Shrug.
On Mon, Aug 12
Alternatively, just like we did with the DataImportHandler (DIH)[1],
we migrate the Tika stuff to an independent project/home on GitHub and
people install it if they need it. Like the DIH, Solr's Tika
integration is quite popular/used so I expect it'll be maintained
instead of abandoned. At that
11 matches
Mail list logo
