> I think Dawid argued that the check is good to notify the
> committer that there may be uncommitted changes, but I doubt this helps.
> A warning would be fine.
>
Reviving the dead (beetlejuice, beetlejuice, ...) but here's an example
where validation.git.failOnModified helped me
figure out that
> There isn't a singular "classpath"
> (DependencySet? in Gradle). I think there are multiple "classpaths"
> for many things (e.g. compiling main sourceSet vs compiling test
> sourceSet) for each module (many modules).
These configurations are from the java plugin in gradle and most of them
are
>
> I couldn't find a way to identify redundant constraints either for
> cleaning up in the long run the constraints. Any ideas how this could be
> tackled?
>
Exactly. It's a problem I keep struggling with elsewhere as well. The only
workflow I managed to figure out was to keep the constraints cen
Hi Christos,
> I am just not very happy with the repetitive constraints and the need to
> include transitive dependencies in the version catalog whenever there is a
> version mismatch that needs to be synced.
I share your pain - there is added verbosity here. I haven't found an
elegant way to d
> 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.
>
That's fine. I'm not that happy with everything that's in the Lucene buil
Hi Christos,
CCing dev@solr so that it stays in the archives.
I wanted to reach out to you to ask how you would resolve dependency
> conflicts with the carrotsearch dependency checks plugin. I am using the
> same dependencies.gradle file as in the Lucene project in Solr and I have
> found a way 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
> Thanks for your reply Dawid. So it is not automated and we have to check
> for changes in the License and Notice files whenever we update a
> dependency. Is that correct?
>
Yes, that should be the practice, I think. This license metadata isn't
standardized at all and it'll be difficult to automa
Hi Chrisos,
I think these files are placed manually when you add/ remove a dependency.
You should also manually review the license and check if it's really
compatible with the ASL (and what it contains). I typically cherry-picked
the license file from the library's repository (at whatever the depe
> I just made a second test task and used the gradle code from the test task
> as building blocks.
This isn't something that is built into the "standard" gradle though and if
you're building upon their internal APIs they do change quite frequently -
I found it quite a burden to keep custom-code o
cuter.java#L117-L120
Again - these are internal APIs, I don't think it's something that can be
fixed from the outside.
Dawid
On Sun, Oct 9, 2022 at 9:18 AM Dawid Weiss wrote:
>
> You'd need to rewrite the default test task in gradle, Shawn. This is a
> known
You'd need to rewrite the default test task in gradle, Shawn. This is a
known issue I mentioned here:
https://markmail.org/message/vjpfc2jwocroz7nd
Essentially, test assignment and scheduling is all gradle-internal APIs. I
gave up on trying to improve this after my few other issues reported to
gr
HashMap<>();
I wonder why this doesn't seem to be used from request to request in my
case, eh.
Dawid
On Mon, Aug 29, 2022 at 3:07 PM Dawid Weiss wrote:
>
> Hi,
>
> I have a situation here with Solr 8.11.2 in stand-alone mode, a large
> (200GB+) index with multi-valu
Hi,
I have a situation here with Solr 8.11.2 in stand-alone mode, a large
(200GB+) index with multi-valued doc value string fields. The problem is
that faceting over these fields takes a long time. Before you say: "well,
duh, of course" I wanted to point out that it takes a long time for *every*
q
> There's a "hole" in the git-history in new solr repo, so filling that hole
> with the missing commits is a valid wish - so you can brose the entire
> history of Solr from one repo, and investigate recent changes to a file
> from IDE. I guess now GIT would lie to you and tell you that the previous
> I did mean that we should be pushing the tags as well as their associated
> commits.
>
You can even edit them by hand so you can definitely have references
pointing at void...
I already expressed my opinion on the matter but I won't object if you wish
to do it. The problem I see is that it's re
story of a file in different release
> versions, even if that specific release happened
> under apache/lucene-solr.
>
> - Houston
>
> On Tue, Jan 4, 2022 at 2:02 PM Dawid Weiss wrote:
>>
>> > As mentioned in SOLR-15874, we are not hosting the tags for the latest 8.x
>
> As mentioned in SOLR-15874, we are not hosting the tags for the latest 8.x
> releases in the split apache/solr and apache/lucene repositories. All release
> tags made prior to the repository split exist in the new repos, so I see no
> reason that the newer 8.x tags cannot exist in the new repo
> FWIW: the test-suite-level "no runnable tests" errors usually crop up for me
> when specifying tests with wildcard expressions, e.g.:
> `-Dtests.class='org.apache.solr.search.facet.*'` (with `DebugAgg` being the
> culprit in that case). I just ignore these "no runnable tests" errors (though
>
> The test.seed will cause the randomized testing to choose the same
> locale/timezone/encoding/etc so that if you're hitting a bug that only shows
> up with swahili or for the kiribati timezone it will reproduce reliably.
Correct. Some things will be "derived" from this property at build
time (
ave one, and in other Jekyll sites that I
> maintain, we do have a Gemfile and Gemfile.lock.May be worth adding if
> Antora doesn’t land in Solr 9?
>
>
> On Nov 12, 2021, at 3:05 AM, Dawid Weiss (Jira) wrote:
>
>
>[
> https
Hello everyone!
Please welcome Michael Gibney as the latest Solr committer. Michael
- it's a tradition for you to introduce yourself. I realize the
Lucene/ Solr invitations are in parallel, but you should do it on both
mailing lists (for future committers' sake).
Welcome!
Dawid
Congratulations and welcome, Ilan.
On Wed, Sep 22, 2021 at 3:32 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> I am pleased to announce that Ilan Ginzburg has accepted the Solr PMC's
> invitation to join.
>
> Congratulations and welcome, Ilan!
>
>
built from. Multiple commits with the same short(end) hash are possible
> -- Multiple commits with identical (full) commits is not.
>
> Folks may think that using git tags is useful enough for figuring this
> out from official releases, but being able to look at the jar metadata
> f
ty / supply
> > chain tools. We know a lot of these are total crap but people in the
> > corporate world have to suffer under them.
> >
> > Its super-easy to use a short hash here and avoid problems.
> >
> > On Thu, Sep 16, 2021 at 3:03 AM Dawid Weiss wrote:
>
gt; ability to read these manifests and print stuff to stdout, e.g. if
> there was ANY interop at all here.
>
> But there isn't. So IMO it makes no sense to cause confusion and chaos
> by adding an unnecessarily long git commit hash.
>
> On Wed, Sep 15, 2021 at 3:26 PM D
This is valid manifest line-breaking though... Can we read the manifest
properly on the smoke tester side somehow (for example, run a Java process
that reads and extracts the required attribute)? This way we wouldn't care
about the implementation details of how manifest wraps the lines (or
escapes
Congratulations and welcome, Alessandro!
Dawid
On Mon, Sep 6, 2021 at 2:41 PM Jan Høydahl wrote:
>
> I am pleased to announce that Alessandro Benedetti has accepted the PMC's
> invitation to join.
>
> Congratulations and welcome, Alessandro!
>
Congratulations and welcome, András!
Dawid
On Thu, Sep 2, 2021 at 12:01 AM Jan Høydahl wrote:
>
> Hi all,
>
> Please join me in welcoming András Salamon as the latest Solr committer.
> András, it's tradition for you to introduce yourself with a brief bio.
>
> Congratulations and Welcome!
> Jan
>
Hello everyone,
Just FYI - SOLR-15602 has a patch that upgrades Gradle to 7.2 and adds
support for JDK16 as the base JVM for development. I've tried a bunch
of tasks on that build and they pass for me but I would really
appreciate if you could apply this patch locally and try out the
workflows/ ta
t as input for its external links).
Dawid
On Thu, Aug 26, 2021 at 3:53 PM Mike Drob wrote:
>
> I am very against packages split across multiple jars/modules, so would
> imagine that a package move is necessary
>
> On Thu, Aug 26, 2021 at 8:04 AM Dawid Weiss wrote:
>&g
This fails for me locally:
:solr:documentation:checkBrokenLinks
and yet github actions passed (they do run the same command). I see
the following offender:
[root]/solr/main/solr/documentation/build/site/benchmark/org/apache/solr/bench/MiniClusterState.html
BROKEN LINK:
[root]/solr/main/solr/do
Hi Alexis,
It'd be great to see improvements to gradle in both Solr and Lucene, thank
you! There are already some improvements (and upgrades) made on the Lucene
side - I just didn't have time to port these over to Solr.
Dawid
On Wed, Aug 25, 2021 at 4:32 PM Alexis Tual wrote:
> Hi,
>
> I'm Ale
> I just have to figure out, if some local repo, copied to some Webserver
> works well as a full M2 repository, especially how to
You should set up publishing to push to a maven repository without wiping
it first (the current build does it intentionally so that you can inspect
the artifacts). Thi
> Other than literally adding the git submodule, would we do anything else to
> modify the gradle build so that or do we (and Jenkinsfile) have to manually
> do a step to install Lucene before proceeding?
Technically you add a submodule and then make a composite build from
Solr side. I can provi
re are no
> guarantees about how long those versions stick around. Maybe we can
> ask Lucene to release a 9.0.0-alpha just so that we have some kind of
> tag that we can stick to, with the understanding that this alpha tag
> has no guarantees about future compatibility.
>
> On Fri, A
Sorry to be late to the party but cordial congratulations, Eric!
Dawid
On Sat, Apr 24, 2021 at 2:19 AM Jan Høydahl wrote:
>
> I am pleased to announce that Eric Pugh has accepted an invitation to join
> the Solr PMC!
>
> Congratulations, and welcome aboard!
>
> Jan
> ---
But how do you pin to an intermediate version without a snapshot maven
repository that would keep those pinned artifacts?
Dawid
On Thu, Apr 29, 2021 at 9:45 PM David Smiley wrote:
>
> +1 Jan, that sounds complementary to what I propose. We'd get notifications
> via Jenkins that there are some
You need an extra step to install curl on Windows. I know it may seem
esoteric but I bet there are still a fair share of folks who are on Windows.
D.
On Wed, Apr 28, 2021 at 11:04 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> We should remove the post tool
> Altogether. Curl is g
> We should wait until Lucene 9 is released and then switch to a fixed version.
> This was the plan from beginning and is also fine if it takes more months or
> half a year until Lucene releases 9.0.
I think the question was about temporary holds when something in
Lucene changes in an incompatib
. But that's a bridge we can cross if we come to it I guess, and
> I'm thread hijacking at this point. Thanks guys.
>
> On Thu, Apr 15, 2021 at 8:28 AM Dawid Weiss wrote:
> >
> > > Wrt SNAPSHOT, I think we just need to be patient until Lucene releases
> &
> Wrt SNAPSHOT, I think we just need to be patient until Lucene releases 9.0.0,
> then we can depend on that instead, and choose our own timing for upgrading.
You can pin the dependency to a particular snapshot revision... the
problem is those revisions don't stay in snapshot repositories forever
ttp://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Fri, Apr 2, 2021 at 11:02 AM Michael Sokolov wrote:
>>>
>>> +1 it would be nice to be able to sort these out differently with filters
>>>
>>> On Fri, Apr 2, 2021 at 3:54 AM Dawid Weiss wro
Hi folks!
I know the development repository for 8x stays in the previous location but
can we (should we) update the mailing list address on Solr 8x build jobs to
point at bui...@solr.apache.org?
D.
Hi Chris,
I checked out commit 507f79158458c450e1f3d2e8ad6ab3e1c3902403 and ran check
and indeed it didn't show any errors. Ecj config does have unused imports
-> error though. Puzzling.
D.
On Fri, Mar 26, 2021 at 5:59 PM Chris Hostetter
wrote:
>
> Not sure what's going on, if this has to do
Unless this code is used millions of millions of times I would just use a
code pattern that is understood by any developer - senior and junior... A
volatile or even initialization under a plain monitor. Those fancy memory
guards are great for low-level data structures but they are really hard to
un
46 matches
Mail list logo
