I've created https://issues.apache.org/jira/browse/SOLR-13452 Update the
lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
I've also pushed a new branch with my current work, linked to in that issue.
- Mark
bq. Just curious, what motivates "*I’ve also disabled transitive
dependencies and found a way to easily make modules transitive in the face
of that (fingers crossed)*"
Well, our community is a bit religious about transitive dependencies, so
it's unlikely we get by without objection to allowing the
Just curious, what motivates "*I’ve also disabled transitive dependencies
and found a way to easily make modules transitive in the face of that
(fingers crossed)*"
On Mon, May 6, 2019 at 10:31 PM Mark Miller wrote:
> I finally got a go ahead from Uwe on Twitter, so looks like we can start
> in
I finally got a go ahead from Uwe on Twitter, so looks like we can start in
earnest.
Give me a day or two to get my experimentación branch in order and I’ll
share.
Like I said, I grabbed Dat’s buildSrc module which has the forbidden apis
and project checkout checks.
Then I integrated in a way th
As the ol' "Ant guy" curmudgeon, with no active clout, . I'm all for this
modernization effort +1Kudos to Mark, and others, for prodding ahead on
this long discussed and overdue overhaul.
Erik
> On May 6, 2019, at 3:12 AM, Mark Miller wrote:
>
> Yes, but hopefully just pract
On 5/6/2019 7:37 AM, Erick Erickson wrote:
I want to be clear about my question of whether we’d use Gradle for master and
continue to use Ant for 8x.
It is _totally_ and _completely_ a matter of what would be easiest and up to
the people who are doing the heavy lifting. If moving both to Gradl
I want to be clear about my question of whether we’d use Gradle for master and
continue to use Ant for 8x.
It is _totally_ and _completely_ a matter of what would be easiest and up to
the people who are doing the heavy lifting. If moving both to Gradle would be
easiest, that has my vote. If a
Yes, but hopefully just practically useful stuff :)
I think a lot of the cruft and pain now is that we banged and smashed and
pried ant+ivy to act like a modern build system at the expense of
performance issues and a lack of simple features and sophisticated hacks to
get around some of the perform
> Switching to gradle means deleting tons of crap - all sorts of work arounds
> and ant abuse go away.
True. But other things will creep in. Take a look at any larger gradle
build -- there's lots of groovy-code magic in there...
To be clear: I do think the switch over to gradle is worth it (for
I don't know that we need or want to do side by side, it's just doable. If
we did do that, certainly the goal would be to keep it short. Whatever
keeps people from pulling the rug out from under me if I work on this
further.
Any other bike-shedding to be done or major concerns?
This really will b
I agree that an easier-to-understand build is an important virtue we should
try to achieve here (for the reasons you mentioned). Our build is too
complex and non-standard. Any other benefits are icing on the cake.
RE "side by side"; that could weigh us down maintaining more; I hope this
isn't lo
We can indeed make them work side by side.
- Mark
On Sun, May 5, 2019 at 11:36 AM Erick Erickson
wrote:
> I don’t know enough about the differences to even think consider
> complaining.
>
> Is the proposal that we use Gradle for master and continue to use ant for
> 8x? As long as the two build
I'm not particularly moved by any performance differences. And the gradle
daemon is not my friend.
I see the main benefits of gradle as:
Our current ant+ivy+maven system is an insanely complicated Frankenstein.
It's high barrier of entry for new devs and does our project a disservice.
Adding or c
Sure, maybe. My feelings towards Gradle range from love to fury (and
quite frequently in short time spans). For example I'm sort of
wondering what will happen to those build machines (which aren't
exactly speed beasts) when you launch multiple builds on different
JVMs; gradle is fast once it has an
I think you're right on the tests part.
Task that are run by the QA Bot (
https://issues.apache.org/jira/browse/SOLR-13049?focusedCommentId=16832997&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16832997
) could benefit from caching though right?
On Sun, May 5, 201
I think most of the build time is spent in tests. Since we're using
randomization I don't think you'd gain much from caches?
Dawid
On Sun, May 5, 2019 at 8:24 PM Varun Thacker wrote:
>
> Over the last few months, I've realized the power of build caches.
>
> In the future could we have remote cac
Over the last few months, I've realized the power of build caches.
In the future could we have remote caches for Jenkins? In which case the
Lucene/Solr QA bot will be significantly faster as well? And then it could
just run against all patches and even block commits that violate it?
On Sun, May 5
I don’t know enough about the differences to even think consider complaining.
Is the proposal that we use Gradle for master and continue to use ant for 8x?
As long as the two build systems can exist side by side (i.e. we can build
master by executing some Gradle target and continue to build 8x w
We already dump out to groovy to do anything interesting, so I doubt there
is much we can't replicate.
- Mark
On Sat, May 4, 2019 at 9:09 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> Would beasting of tests be possible through gradle?
>
> On Sun, May 5, 2019 at 7:33 AM Mark Mill
Would beasting of tests be possible through gradle?
On Sun, May 5, 2019 at 7:33 AM Mark Miller wrote:
>
> I looked into this a little more.
>
> Seems if we just do it with master and going forward, we don’t need multi
> version support - Uwe seems to have taken it out with the move to Java 11?
>
I looked into this a little more.
Seems if we just do it with master and going forward, we don’t need multi
version support - Uwe seems to have taken it out with the move to Java 11?
I can handle regenerate.
The other quality checks shouldn’t be crazy.
So I guess we can probably do this, but be
I've got my own lucene-solr gradle branch as well.
I stole the BuildPlugin and CheckWorkingCopy from Dat's branch, but also
made some changes.
* Similar to above above, I don't move the src files so it can keep things
up to date without lots of pain.
* I used a plugin that lets us define versions
Cool Diego,
I will take a look on this. Thanks a lot!
nced
> BEFORE far-flung remote repositories
>
> by properly tuning local cache-proxies you can bypass high-latency remote
> repositories and "accelerate your build process"
>
> /greets/
> martin-
> --
> *From:* Gézapeti
> *Sent:*
___
From: Gézapeti
Sent: Monday, March 4, 2019 5:45 PM
To: dev@lucene.apache.org
Cc: markrmil...@gmail.com
Subject: Re: Call for help: moving from ant build to gradle
I'd be happy to help with the gradle migration.
I could not find a jira that covers it, only LUCENE-5755, which was closed a
I'd be happy to help with the gradle migration.
I could not find a jira that covers it, only LUCENE-5755, which was closed
a long time ago.
Where can I join the discussion about this?
Thanks for the pointers,
gp
On Thu, Feb 7, 2019 at 8:23 PM Vladimir Kroz
wrote:
> +1 for moving to gradle. I'm
+1 for moving to gradle. I'm happy to help.
On Wed, Dec 19, 2018 at 8:25 AM Mark Miller wrote:
> +1. Gradle is the alpha and the omega of build systems. I will help.
>
> - Mark
>
> On Sun, Nov 4, 2018 at 1:13 PM Đạt Cao Mạnh
> wrote:
>
>> Hi guys,
>>
>> Recently, I had a chance of working on mo
+1. Gradle is the alpha and the omega of build systems. I will help.
- Mark
On Sun, Nov 4, 2018 at 1:13 PM Đạt Cao Mạnh wrote:
> Hi guys,
>
> Recently, I had a chance of working on modifying different build.xml of
> our project. To be honest that was a painful experience, especially the
> numbe
@lucene.apache.org At: 11/05/18 22:34:50
To: dev@lucene.apache.org<mailto:dev@lucene.apache.org>
Subject: Re: Call for help: moving from ant build to gradle
Edward:
Of course. You may have to coordinate how to get your contributions
added to the patch is all.
I'd coordinate with Dat first
/05/18 22:34:50To: dev@lucene.apache.org
Subject: Re: Call for help: moving from ant build to gradle
Edward:
Of course. You may have to coordinate how to get your contributions
added to the patch is all.
I'd coordinate with Dat first though just for efficiency's sake. Just
work with
Yago Riveiro smiled at you
Spark by Readdle
Edward:
Of course. You may have to coordinate how to get your contributions
added to the patch is all.
I'd coordinate with Dat first though just for efficiency's sake. Just
work with the branch/gradle version of the code from the main Git
repo.
On Mon, Nov 5, 2018 at 2:22 PM Edward Ribeiro wrote
Is this work open to contribution of non committers?
Edward
Em seg, 5 de nov de 2018 15:01, Gus Heck I'm quite fond of gradle, and even wrote a very simple plugin for
> uploading and downloading solr configs to zookeeper from gradle. +1 to use
> gradle.
>
> I'll definitely check it out and give
I'm quite fond of gradle, and even wrote a very simple plugin for uploading
and downloading solr configs to zookeeper from gradle. +1 to use gradle.
I'll definitely check it out and give it a whirl, maybe I'll help some if I
can.
On Sun, Nov 4, 2018 at 2:13 PM Đạt Cao Mạnh wrote:
> Hi guys,
>
>
: u...@thetaphi.de
>
> > -Original Message-
> > From: Erick Erickson
> > Sent: Monday, November 5, 2018 4:27 PM
> > To: dev@lucene.apache.org
> > Subject: Re: Call for help: moving from ant build to gradle
> >
> > Seems more efficient to put
ginal Message-
> From: Erick Erickson
> Sent: Monday, November 5, 2018 4:27 PM
> To: dev@lucene.apache.org
> Subject: Re: Call for help: moving from ant build to gradle
>
> Seems more efficient to put it on a branch for easier collaboration.
> On Mon, Nov 5, 2018 at 7
mentation (XSLT). Also the transcoder to Java 9+ for MR-JARs is still
>>> missing as a “compile”-like task (I can help with that).
>>>
>>>
>>>
>>> Should we all commit to the branch for proceeding?
>>>
>>> Uwe
>>>
>>>
&g
-
>>
>> Uwe Schindler
>>
>> Achterdiek 19, D-28357 Bremen
>> <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen&entry=gmail&source=g>
>>
>> http://www.thetaphi.de
>>
>> eMail: u...@thetaphi.de
>>
>>
>>
gt; Achterdiek 19, D-28357 Bremen
> <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen&entry=gmail&source=g>
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Đạt Cao Mạnh
> *Sent:* Sunday, November 4, 2018 8:13 PM
> *To:*
vember 4, 2018 8:13 PM
To: Solr/Lucene Dev
Subject: Call for help: moving from ant build to gradle
Hi guys,
Recently, I had a chance of working on modifying different build.xml of our
project. To be honest that was a painful experience, especially the number of
steps for adding a new mod
Hi guys,
Recently, I had a chance of working on modifying different build.xml of our
project. To be honest that was a painful experience, especially the number
of steps for adding a new module in our project. We reach the limitation
point of Ant and moving to Gradle seems a good option since it ha
41 matches
Mail list logo
