Build Solr
-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de
From: Uwe Schindler
Sent: Tuesday, May 25, 2021 4:12 PM
To: dev@solr.apache.org
Cc: 'David Smiley'
Subject: RE: Proposal to pin the Lucene snapshot version on
...@thetaphi.de
From: Uwe Schindler
Sent: Tuesday, May 25, 2021 4:09 PM
To: dev@solr.apache.org
Cc: 'David Smiley'
Subject: RE: Proposal to pin the Lucene snapshot version on main
Hi,
as alternative to the jenkins-build-number I could also use the commit hash
(jenkins has a env va
tps://www.thetaphi.de
eMail: u...@thetaphi.de <mailto:u...@thetaphi.de>
From: Uwe Schindler mailto:u...@thetaphi.de> >
Sent: Tuesday, May 25, 2021 3:35 PM
To: dev@solr.apache.org <mailto:dev@solr.apache.org>
Cc: 'David Smiley' mailto:dsmi...@apache.org> >
S
phi.de
From: Uwe Schindler
Sent: Tuesday, May 25, 2021 3:52 PM
To: dev@solr.apache.org
Cc: 'David Smiley'
Subject: RE: Proposal to pin the Lucene snapshot version on main
Hi,
it’s working, the first prerelease:
You have to add this folder as a Maven Repository (so each
Sent: Tuesday, May 25, 2021 3:35 PM
To: dev@solr.apache.org
Cc: 'David Smiley'
Subject: RE: Proposal to pin the Lucene snapshot version on main
Hi,
David, can you have a look at this:
<https://ci-builds.apache.org/job/Solr/job/Lucene-prerelease-main/ws/build/maven-
-local) looks fine?
-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de
From: Uwe Schindler
Sent: Tuesday, May 25, 2021 3:06 PM
To: dev@solr.apache.org
Subject: RE: Proposal to pin the Lucene snapshot version on main
Hi,
sorry f
Sent: Tuesday, May 25, 2021 2:01 PM
To: Uwe Schindler
Cc: dev@solr.apache.org; Cassandra Targett
Subject: Re: Proposal to pin the Lucene snapshot version on main
Thanks again for volunteering Uwe. I'm wondering what the status of this is?
There was recently a major change in Lucene to
Thanks again for volunteering Uwe. I'm wondering what the status of this
is? There was recently a major change in Lucene to move SpanQueries, and I
think we're going to feel it in Solr. If not, it's just a matter of time
before there is some other impactful change.
~ David Smiley
Apache Lucene/
> 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
Hi,
Sure!
I will play a little bit around. If needed, I can add some property to the
lucene build to locate a "local repo" (I think we have that already).
I just have to figure out, if some local repo, copied to some Webserver works
well as a full M2 repository, especially how to handle multiple
Sounds great Uwe! Can you do it please?
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Fri, May 7, 2021 at 1:55 AM Uwe Schindler wrote:
> Hi Cassandra. Sure, We can create a job on ASF Jenkins that is only
> manually triggered.
> It builds the ma
No, these are not "releases".
> If the general public is being instructed to download a package, then
that package has been released
We will not be instructing the general public to download this stuff. It's
internal, and it's temporary before we get to an actual 9.0 release.
~ David Smiley
Apa
Is this allowed by ASF policy? Are the Lucene “releases” that we are making
something that needs to be voted on and approved by the Lucene PMC?
https://apache.org/legal/release-policy.html#what
> In our case, that means any publication outside the group of people on
the product dev list.
Solr dev
Hi Cassandra. Sure, We can create a job on ASF Jenkins that is only manually
triggered.
It builds the maven artifacts into a local file system repo. As post build job
we publish the output folder on nighties repo like the ref guide.
The version number is passed as -DreleaseVersion system propert
It could be a manual process if that’s what you think is easiest and it could
still be on nightlies. It’s just a curl command to push something up:
https://nightlies.apache.org/authoring.html. If it is a manual process, I think
it would be better for it to be hosted in a place any of us could ac
I asked on the Lucene dev list about possible use of the Nightlies server.
We don't want to pollute nightlies on a regular basis (I think); this would
be an on-demand thing. As such, I'm not sure a CI server is the best way
to approach this vs a manual script publishing to an ASF personal Home
spa
Some that come to mind,
SOLR-5944
SOLR-13350
LUCENE-9302 / SOLR-14381
On Mon, May 3, 2021 at 11:31 PM Jan Høydahl
wrote:
> Can you give an example of a recent solr feature that needed such a
> workflow - I.e where it would be very annoying to have to do the Lucene
> part first and then the sol
Can you give an example of a recent solr feature that needed such a workflow -
I.e where it would be very annoying to have to do the Lucene part first and
then the solr part, using a local snapshot version?
Jan Høydahl
> 3. mai 2021 kl. 17:32 skrev Ishan Chattopadhyaya :
>
>
> One of the oth
One of the other problems I have with maven, besides where will the
snapshots go, is the local development workflow. If I were to work on a
feature that needs changes to both Lucene and Solr, I would need to make
Lucene changes in a separate git repo, push them to local Maven, have solr
build again
I agree, Cassandra. The nightlies are a very good option that is very easy
to get started with.
On Mon, May 3, 2021 at 9:55 AM Cassandra Targett
wrote:
> I’m sort of surprised no one has mentioned the
> https://nightlies.apache.org/ server, which could be used for this
> purpose. Jenkins can pus
I’m sort of surprised no one has mentioned the https://nightlies.apache.org/
server, which could be used for this purpose. Jenkins can push to it, and
nothing gets deleted until we decide to delete it (or overwrite it). Solr
Operator builds go there as do drafts of the Ref Guide pre-publication
RE "an external system like Maven" -- we're merely talking about adding
another JAR repo to the list of repos we already have. Heck, for this
limited purpose, we could even use http://home.apache.org/~dsmiley/ Note
that the Lucene project already uses home dirs of some users for benchmark
data.
> Let’s not complicate things.
By bringing in external systems like Maven, I think we're complicating
things even though a straight forward way (git submodules) exists.
On Sat, May 1, 2021 at 5:00 PM Jan Høydahl
wrote:
> Sub modules is for organizing internal repos, not for pulling in external
>
Sub modules is for organizing internal repos, not for pulling in external deps.
Let’s not complicate things. And once we switch main to 10.x we’d need to use
pure jar dependencies in branch_9x to depend upon actually released and voted
Lucene binaries.
We need some tooling to smoothly work with
> What submodules don't solve is releases - if you're
> on a
particular unreleased Lucene version then releasing
> Solr would still mean you need some kind of
> "public" pinned Lucene release for the
> Mavenworld.
Can we then update the submodule to point to the release tag or sha that
Lucene got
> 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
I think adding git submodule means that we have to add back in all the
build code for it. At which point, I'd rather just copy and commit the
code they have so we don't have to learn another git system. I've
heard submodules don't play nice with Jenkins, but don't have any
direct experience with th
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? Manually wouldn't
necessarily be bad, even if a first step, considering this is likely to
only last
Can we give submodules a try for few weeks and then take an informed
decision?
On Sat, 1 May, 2021, 12:32 am Ishan Chattopadhyaya, <
ichattopadhy...@gmail.com> wrote:
> I fully support git submodules. +1 dawid.
> Most of the problems with it that people complain about, are perceived
> problems, n
I fully support git submodules. +1 dawid.
Most of the problems with it that people complain about, are perceived
problems, not real ones.
On Fri, 30 Apr, 2021, 10:50 pm Dawid Weiss, wrote:
> We've had that discussion before -- this is where git submodules are
> excellent to work with - you know
We've had that discussion before -- this is where git submodules are
excellent to work with - you know exactly which version you had for
each commit... this said, there are other pitfalls to using submodules
so it's not all rosy either.
On Fri, Apr 30, 2021 at 4:41 PM Mike Drob wrote:
>
> Note th
release with
such a dependency.
Uwe
-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Jan Høydahl
> Sent: Friday, April 30, 2021 4:46 PM
> To: dev@solr.apache.org
> Subject: Re: Proposal to pin the Lucene
Solr can build a 9.0.0-solr-20210430 version and push it to internal ASF repo,
can't we?
Jan
> 30. apr. 2021 kl. 16:41 skrev Mike Drob :
>
> Note that this happened again last night, and Jason was able to
> quickly fix it. But it makes things like 'git bisect' impossible to
> chase a bug becaus
Note that this happened again last night, and Jason was able to
quickly fix it. But it makes things like 'git bisect' impossible to
chase a bug because none of the older versions will compile.
I don't think we can pin to a SNAPSHOT version because there are no
guarantees about how long those versi
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
Hi,
+1 to pin.
Kind Regards,
Furkan KAMACI
On Thu, Apr 29, 2021 at 10:45 PM David Smiley wrote:
> +1 Jan, that sounds complementary to what I propose. We'd get
> notifications via Jenkins that there are some compatibility issues. But
> we'd still pin a version and upgrade at a time of our ch
+1 Jan, that sounds complementary to what I propose. We'd get
notifications via Jenkins that there are some compatibility issues. But
we'd still pin a version and upgrade at a time of our choosing.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Th
It could be feasible to let Jenkins do a periodic run (weekly?) of main branch
with lucene SNAPSHOT. We can perhaps define a gradle property to override
lucene version? -Dlucene.version=10.0.0-SNAPSHOT which Jenkins could easily
trigger. I think a similar thought has been discussed before.
Jan
We should still have some way of detecting these breakages early rather
than later (or worse yet after lucene has released something). The easiest
time to fix a problem is before someone else built on top of it.
On Thu, Apr 29, 2021 at 11:15 AM Jason Gerlowski
wrote:
> +1
>
> On Thu, Apr 29, 202
+1
On Thu, Apr 29, 2021 at 11:12 AM Jan Høydahl
wrote:
>
> +1 to pin. There will probably be a few more months until 9.0 given that 8.9
> must be released first etc.
>
> Jan
>
> 29. apr. 2021 kl. 17:08 skrev David Smiley :
>
> There have been some discussions previously about whether to pin the
+1 to pin. There will probably be a few more months until 9.0 given that 8.9
must be released first etc.
Jan
> 29. apr. 2021 kl. 17:08 skrev David Smiley :
>
> There have been some discussions previously about whether to pin the Lucene
> snapshot version until 9.0 is out, so that we update it
There have been some discussions previously about whether to pin the Lucene
snapshot version until 9.0 is out, so that we update it manually instead of
it being ~daily. Most recently in Slack but also this thread "Solr fails
with current lucene-9.0.0-SNAPSHOT (LUCENE-9387)". I think the rate of
s
42 matches
Mail list logo
