Re: Call for help: moving from ant build to gradle

[Mark Miller]

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

Re: Call for help: moving from ant build to gradle

[Mark Miller]

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 them now. If you take
a look at Dawid's issue investing Gradle in like 2014, this is one of the
first things to come up. It's why we have them disabled with Ivy.

Now of course you can enable them and just exclude certain transitive deps,
but this is often done lazily and right now we are pretty tight with what
we bring in. Turning on transitive will have ZooKeeper bring in spotbugs
and netty stuff for example. As people add dependencies, it's much more
likely with transitive off that they won't think they need to accept those
unnecessary deps and they won't have to trial and error to exclude them
(won't often happen).

Okay, great, so Gradle let's you turn off transitive deps. Unfortunately,
this is only easy to do universally, including the other modules/projects
you import. So every module not only has to import lucene-test-framework,
but also junit and carrot stuff. Not only do you have to pull in
solr-server, but you have to specify and get right every jetty dep, in
every module that uses it. User consumers are prob put in the same
position. With ant+ivy now we actually get module transitivity, but not 3rd
party dep transitivity.

Gradle let's you be selective, but it's completely rigged to want you to
selectively turn off transitivity, not turn it on. This is a bit of a
problem in terms of enforcement over time, and is a cumbersome config to
apply to every dep we add.

So I've worked out a way to make it easy to specify a transitive project,
eg testImplementationTran project(':lucene:test-framework'). Now that was a
bit painful to get working, though a small amount of code. And then a bit
more painful to get working in a way that the project gives you it's deps,
but then *they* are not transitive. I've done something that appears to
work, but I'm still vetting it. I'm not sure my eclipse ide is as happy as
cmd line gradle is about it.

May have to abandon, but I'm doing my best to match the current accepted
situation in an enforcement and convenient way.

- Mark



On Tue, May 7, 2019 at 11:10 AM Gus Heck  wrote:

> 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 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 that you don’t have to move src or test
>> resource files - ideal in general, but also critical for keeping things up
>> to date during dev.
>>
>> I also grabbed Palantirs versión consistency plugin that ensures
>> consistent version resolution across modules and has better version locking
>> than Gradle, with a root dependency/version lock file with one dependency
>> per line that gets written out.
>>
>> I’m also almost done moving version specifications to a root properties
>> file as that plugin expects.
>>
>> I’ve also disabled transitive dependencies and found a way to easily make
>> modules transitive in the face of that (fingers crossed)
>>
>> I’ve also started adding some of the regenerate stuff, automata and what
>> not, still have to do jflex and do some testing.
>>
>> Currently everything is building and tests are passing, but there is a
>> bit around dependencies and versioning I want to clean up before sharing
>> for collaboration.
>>
>> Mark
>>
>>
>> --
>> - Mark
>>
>> http://about.me/markrmiller
>>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>


-- 
- Mark

http://about.me/markrmiller

Re: Call for help: moving from ant build to gradle

[Gus Heck]

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 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 that you don’t have to move src or test
> resource files - ideal in general, but also critical for keeping things up
> to date during dev.
>
> I also grabbed Palantirs versión consistency plugin that ensures
> consistent version resolution across modules and has better version locking
> than Gradle, with a root dependency/version lock file with one dependency
> per line that gets written out.
>
> I’m also almost done moving version specifications to a root properties
> file as that plugin expects.
>
> I’ve also disabled transitive dependencies and found a way to easily make
> modules transitive in the face of that (fingers crossed)
>
> I’ve also started adding some of the regenerate stuff, automata and what
> not, still have to do jflex and do some testing.
>
> Currently everything is building and tests are passing, but there is a bit
> around dependencies and versioning I want to clean up before sharing for
> collaboration.
>
> Mark
>
>
> --
> - Mark
>
> http://about.me/markrmiller
>


-- 
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

Re: Call for help: moving from ant build to gradle

[Mark Miller]

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 that you don’t have to move src or test resource
files - ideal in general, but also critical for keeping things up to date
during dev.

I also grabbed Palantirs versión consistency plugin that ensures consistent
version resolution across modules and has better version locking than
Gradle, with a root dependency/version lock file with one dependency per
line that gets written out.

I’m also almost done moving version specifications to a root properties
file as that plugin expects.

I’ve also disabled transitive dependencies and found a way to easily make
modules transitive in the face of that (fingers crossed)

I’ve also started adding some of the regenerate stuff, automata and what
not, still have to do jflex and do some testing.

Currently everything is building and tests are passing, but there is a bit
around dependencies and versioning I want to clean up before sharing for
collaboration.

Mark


-- 
- Mark

http://about.me/markrmiller

Re: Call for help: moving from ant build to gradle

[Erik Hatcher]

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 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 performance issues, and ...
> 
> We also like to pretend we have such great control over our dependencies, but 
> we are one of the worst behaved libraries in terms of managing our 
> dependencies in maven central and unnecessary stuff we ship and wrong stuff 
> we ship for various modules.
> 
> A lot of that is just because it's hard to do otherwise with our system.
> 
> With groovy its much easier to clean that up and also verify it stays that 
> way. There are enough hoops to accomplishing that in our current system that 
> no one deals with it.
> 
> It won't all be amazing, but it will be better for sure and we will certainly 
> have more developer help than in the past.
> 
> - Mark
> 
> On Mon, May 6, 2019 at 1:36 AM Dawid Weiss  > wrote:
> > 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 the
> reasons you mentioned, if not anything else).
> 
> Dawid
> 
> On Mon, May 6, 2019 at 8:03 AM Mark Miller  > wrote:
> >
> > 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 be a lot of work - one of those the last 20% takes 80% of 
> > the time type things.
> >
> > Please, please, please, stop me now.
> >
> > - Mark
> >
> >
> > On Sun, May 5, 2019 at 11:39 PM David Smiley  > > wrote:
> >>
> >> 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 long term.
> >>
> >> ~ David Smiley
> >> Apache Lucene/Solr Search Developer
> >> http://www.linkedin.com/in/davidwsmiley 
> >> 
> >>
> >>
> >> On Sun, May 5, 2019 at 6:23 PM Mark Miller  >> > wrote:
> >>>
> >>> 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 systems can exist side by side (i.e. we 
>  can build master by executing some Gradle target and continue to build 
>  8x with Ant like we always have) the minor inconvenience doesn’t merit 
>  standing in the way of progress.
> 
>  If that’s the case I don’t particularly care if we continue to use Ant 
>  with 8x forever. Or maybe some ambitious person can work on bringing 8x 
>  to Gradle after it has some mileage on master.
> 
>  And I have great faith that you wouldn’t be putting in the work unless 
>  you thought it was worth it ;)
> 
>  Erick
> 
>  > On May 4, 2019, at 10:31 PM, Mark Miller   > > wrote:
>  >
>  > 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 
>  > mailto:ichattopadhy...@gmail.com>> wrote:
>  > 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 can handle regenerate.
>  > >
>  > > The other quality checks shouldn’t be crazy.
>  > >
>  > > So I guess we can probably do this, but 

Re: Call for help: moving from ant build to gradle

[Shawn Heisey]

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 Gradle would be 
easiest, that has my vote. If a split process would be easier, then that has my 
vote.

And, frankly, if nobody has speaks up they don’t get a vote AFAIC.


When I try to understand the build system, I get lost.  That might 
continue to happen even with a switch to gradle, of course.  Just having 
somebody work on the build system is likely to clean it up and make it 
easier to understand ... whether we migrate or not.


I do like your idea of doing the work in master, letting it bake for a 
while to work out the kinks, and if it turns out really nice, 
backporting it to the stable branch.


Thanks,
Shawn

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Call for help: moving from ant build to gradle

[Erick Erickson]

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 split process would be easier, then that has my 
vote.

And, frankly, if nobody has speaks up they don’t get a vote AFAIC.

Erick


> On May 6, 2019, at 12:12 AM, Mark Miller  wrote:
> 
> 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 performance issues, and ...
> 
> We also like to pretend we have such great control over our dependencies, but 
> we are one of the worst behaved libraries in terms of managing our 
> dependencies in maven central and unnecessary stuff we ship and wrong stuff 
> we ship for various modules.
> 
> A lot of that is just because it's hard to do otherwise with our system.
> 
> With groovy its much easier to clean that up and also verify it stays that 
> way. There are enough hoops to accomplishing that in our current system that 
> no one deals with it.
> 
> It won't all be amazing, but it will be better for sure and we will certainly 
> have more developer help than in the past.
> 
> - Mark
> 
> On Mon, May 6, 2019 at 1:36 AM Dawid Weiss  wrote:
> > 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 the
> reasons you mentioned, if not anything else).
> 
> Dawid
> 
> On Mon, May 6, 2019 at 8:03 AM Mark Miller  wrote:
> >
> > 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 be a lot of work - one of those the last 20% takes 80% of 
> > the time type things.
> >
> > Please, please, please, stop me now.
> >
> > - Mark
> >
> >
> > On Sun, May 5, 2019 at 11:39 PM David Smiley  
> > wrote:
> >>
> >> 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 long term.
> >>
> >> ~ David Smiley
> >> Apache Lucene/Solr Search Developer
> >> http://www.linkedin.com/in/davidwsmiley
> >>
> >>
> >> On Sun, May 5, 2019 at 6:23 PM Mark Miller  wrote:
> >>>
> >>> 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 systems can exist side by side (i.e. we 
>  can build master by executing some Gradle target and continue to build 
>  8x with Ant like we always have) the minor inconvenience doesn’t merit 
>  standing in the way of progress.
> 
>  If that’s the case I don’t particularly care if we continue to use Ant 
>  with 8x forever. Or maybe some ambitious person can work on bringing 8x 
>  to Gradle after it has some mileage on master.
> 
>  And I have great faith that you wouldn’t be putting in the work unless 
>  you thought it was worth it ;)
> 
>  Erick
> 
>  > On May 4, 2019, at 10:31 PM, Mark Miller  wrote:
>  >
>  > 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 
>  >  wrote:
>  > 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 can handle regenerate.
>  > >
>  > > The other quality checks shouldn’t be crazy.
>  > >
>  > > So I guess we can probably do this, but before I focus on BS 
>  > > details, please speak up if you hate the idea of Gradle and you 

Re: Call for help: moving from ant build to gradle

[Mark Miller]

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 performance issues, and ...

We also like to pretend we have such great control over our dependencies,
but we are one of the worst behaved libraries in terms of managing our
dependencies in maven central and unnecessary stuff we ship and wrong stuff
we ship for various modules.

A lot of that is just because it's hard to do otherwise with our system.

With groovy its much easier to clean that up and also verify it stays that
way. There are enough hoops to accomplishing that in our current system
that no one deals with it.

It won't all be amazing, but it will be better for sure and we will
certainly have more developer help than in the past.

- Mark

On Mon, May 6, 2019 at 1:36 AM Dawid Weiss  wrote:

> > 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 the
> reasons you mentioned, if not anything else).
>
> Dawid
>
> On Mon, May 6, 2019 at 8:03 AM Mark Miller  wrote:
> >
> > 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 be a lot of work - one of those the last 20% takes 80%
> of the time type things.
> >
> > Please, please, please, stop me now.
> >
> > - Mark
> >
> >
> > On Sun, May 5, 2019 at 11:39 PM David Smiley 
> wrote:
> >>
> >> 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 long term.
> >>
> >> ~ David Smiley
> >> Apache Lucene/Solr Search Developer
> >> http://www.linkedin.com/in/davidwsmiley
> >>
> >>
> >> On Sun, May 5, 2019 at 6:23 PM Mark Miller 
> wrote:
> >>>
> >>> We can indeed make them work side by side.
> >>>
> >>> - Mark
> >>>
> >>> On Sun, May 5, 2019 at 11:36 AM Erick Erickson <
> erickerick...@gmail.com> 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 systems can exist side by side (i.e. we
> can build master by executing some Gradle target and continue to build 8x
> with Ant like we always have) the minor inconvenience doesn’t merit
> standing in the way of progress.
> 
>  If that’s the case I don’t particularly care if we continue to use
> Ant with 8x forever. Or maybe some ambitious person can work on bringing 8x
> to Gradle after it has some mileage on master.
> 
>  And I have great faith that you wouldn’t be putting in the work
> unless you thought it was worth it ;)
> 
>  Erick
> 
>  > On May 4, 2019, at 10:31 PM, Mark Miller 
> wrote:
>  >
>  > 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 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 can handle regenerate.
>  > >
>  > > The other quality checks shouldn’t be crazy.
>  > >
>  > > So I guess we can probably do this, but before I focus on BS
> details, please speak up if you hate the idea of Gradle and you have the
> clout to stop it.
>  > >
>  > >
>  > > Mark
>  > >
>  > >
>  > >
>  > >
>  > > On Sat, May 4, 2019 at 5:56 PM Mark Miller 
> wrote:
>  > >>
>  > >> 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 in a root props
> file like we currently do and ensures we use 

Re: Call for help: moving from ant build to gradle

[Dawid Weiss]

> 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 the
reasons you mentioned, if not anything else).

Dawid

On Mon, May 6, 2019 at 8:03 AM Mark Miller  wrote:
>
> 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 be a lot of work - one of those the last 20% takes 80% of 
> the time type things.
>
> Please, please, please, stop me now.
>
> - Mark
>
>
> On Sun, May 5, 2019 at 11:39 PM David Smiley  wrote:
>>
>> 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 long term.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Sun, May 5, 2019 at 6:23 PM Mark Miller  wrote:
>>>
>>> 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 systems can exist side by side (i.e. we can 
 build master by executing some Gradle target and continue to build 8x with 
 Ant like we always have) the minor inconvenience doesn’t merit standing in 
 the way of progress.

 If that’s the case I don’t particularly care if we continue to use Ant 
 with 8x forever. Or maybe some ambitious person can work on bringing 8x to 
 Gradle after it has some mileage on master.

 And I have great faith that you wouldn’t be putting in the work unless you 
 thought it was worth it ;)

 Erick

 > On May 4, 2019, at 10:31 PM, Mark Miller  wrote:
 >
 > 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 
 >  wrote:
 > 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 can handle regenerate.
 > >
 > > The other quality checks shouldn’t be crazy.
 > >
 > > So I guess we can probably do this, but before I focus on BS details, 
 > > please speak up if you hate the idea of Gradle and you have the clout 
 > > to stop it.
 > >
 > >
 > > Mark
 > >
 > >
 > >
 > >
 > > On Sat, May 4, 2019 at 5:56 PM Mark Miller  
 > > wrote:
 > >>
 > >> 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 in a root props file 
 > >> like we currently do and ensures we use the same versions in all 
 > >> modules even after auto conflict resolution (unlike gradle by default)
 > >> * It also locks versions so we can continue to pay attention to scary 
 > >> automatic dependency resolution changes
 > >> * implementation and api used instead of compile
 > >> * Things build and the majority of tests pass (Lucene's 
 > >> TestVirtualMethod does not for example)
 > >>
 > >> If someone like Uwe is serious about helping out with fun extras 
 > >> (regenerating sources, extracting data from ICU, quality checks, 
 > >> documentation (XSLT)), I'd look at contributing.
 > >>
 > >> - Mark
 > >>
 > >>
 > >> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh  
 > >> wrote:
 > >>>
 > >>> Cool Diego,
 > >>>
 > >>> I will take a look on this. Thanks a lot!
 > >>
 > >>
 > >>
 > >> --
 > >> - Mark
 > >>
 > >> http://about.me/markrmiller
 > >
 > > --
 > > - Mark
 > >
 > > http://about.me/markrmiller
 >
 >
 > --
 > - Mark
 >
 > 

Re: Call for help: moving from ant build to gradle

[Mark Miller]

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 be a lot of work - one of those the last 20% takes 80% of
the time type things.

Please, please, please, stop me now.

- Mark


On Sun, May 5, 2019 at 11:39 PM David Smiley 
wrote:

> 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 long term.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Sun, May 5, 2019 at 6:23 PM Mark Miller  wrote:
>
>> 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 systems can exist side by side (i.e. we
>>> can build master by executing some Gradle target and continue to build 8x
>>> with Ant like we always have) the minor inconvenience doesn’t merit
>>> standing in the way of progress.
>>>
>>> If that’s the case I don’t particularly care if we continue to use Ant
>>> with 8x forever. Or maybe some ambitious person can work on bringing 8x to
>>> Gradle after it has some mileage on master.
>>>
>>> And I have great faith that you wouldn’t be putting in the work unless
>>> you thought it was worth it ;)
>>>
>>> Erick
>>>
>>> > On May 4, 2019, at 10:31 PM, Mark Miller 
>>> wrote:
>>> >
>>> > 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 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 can handle regenerate.
>>> > >
>>> > > The other quality checks shouldn’t be crazy.
>>> > >
>>> > > So I guess we can probably do this, but before I focus on BS
>>> details, please speak up if you hate the idea of Gradle and you have the
>>> clout to stop it.
>>> > >
>>> > >
>>> > > Mark
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > On Sat, May 4, 2019 at 5:56 PM Mark Miller 
>>> wrote:
>>> > >>
>>> > >> 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 in a root props file
>>> like we currently do and ensures we use the same versions in all modules
>>> even after auto conflict resolution (unlike gradle by default)
>>> > >> * It also locks versions so we can continue to pay attention to
>>> scary automatic dependency resolution changes
>>> > >> * implementation and api used instead of compile
>>> > >> * Things build and the majority of tests pass (Lucene's
>>> TestVirtualMethod does not for example)
>>> > >>
>>> > >> If someone like Uwe is serious about helping out with fun extras
>>> (regenerating sources, extracting data from ICU, quality checks,
>>> documentation (XSLT)), I'd look at contributing.
>>> > >>
>>> > >> - Mark
>>> > >>
>>> > >>
>>> > >> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh <
>>> caomanhdat...@gmail.com> wrote:
>>> > >>>
>>> > >>> Cool Diego,
>>> > >>>
>>> > >>> I will take a look on this. Thanks a lot!
>>> > >>
>>> > >>
>>> > >>
>>> > >> --
>>> > >> - Mark
>>> > >>
>>> > >> http://about.me/markrmiller
>>> > >
>>> > > --
>>> > > - Mark
>>> > >
>>> > > http://about.me/markrmiller
>>> >
>>> >
>>> > --
>>> > - Mark
>>> >
>>> > http://about.me/markrmiller
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>>
>> --
>> - Mark
>>
>> http://about.me/markrmiller
>>
>

-- 
- Mark

http://about.me/markrmiller

Re: Call for help: moving from ant build to gradle

[David Smiley]

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 long term.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Sun, May 5, 2019 at 6:23 PM Mark Miller  wrote:

> 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 systems can exist side by side (i.e. we can
>> build master by executing some Gradle target and continue to build 8x with
>> Ant like we always have) the minor inconvenience doesn’t merit standing in
>> the way of progress.
>>
>> If that’s the case I don’t particularly care if we continue to use Ant
>> with 8x forever. Or maybe some ambitious person can work on bringing 8x to
>> Gradle after it has some mileage on master.
>>
>> And I have great faith that you wouldn’t be putting in the work unless
>> you thought it was worth it ;)
>>
>> Erick
>>
>> > On May 4, 2019, at 10:31 PM, Mark Miller  wrote:
>> >
>> > 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 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 can handle regenerate.
>> > >
>> > > The other quality checks shouldn’t be crazy.
>> > >
>> > > So I guess we can probably do this, but before I focus on BS details,
>> please speak up if you hate the idea of Gradle and you have the clout to
>> stop it.
>> > >
>> > >
>> > > Mark
>> > >
>> > >
>> > >
>> > >
>> > > On Sat, May 4, 2019 at 5:56 PM Mark Miller 
>> wrote:
>> > >>
>> > >> 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 in a root props file
>> like we currently do and ensures we use the same versions in all modules
>> even after auto conflict resolution (unlike gradle by default)
>> > >> * It also locks versions so we can continue to pay attention to
>> scary automatic dependency resolution changes
>> > >> * implementation and api used instead of compile
>> > >> * Things build and the majority of tests pass (Lucene's
>> TestVirtualMethod does not for example)
>> > >>
>> > >> If someone like Uwe is serious about helping out with fun extras
>> (regenerating sources, extracting data from ICU, quality checks,
>> documentation (XSLT)), I'd look at contributing.
>> > >>
>> > >> - Mark
>> > >>
>> > >>
>> > >> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh 
>> wrote:
>> > >>>
>> > >>> Cool Diego,
>> > >>>
>> > >>> I will take a look on this. Thanks a lot!
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> - Mark
>> > >>
>> > >> http://about.me/markrmiller
>> > >
>> > > --
>> > > - Mark
>> > >
>> > > http://about.me/markrmiller
>> >
>> >
>> > --
>> > - Mark
>> >
>> > http://about.me/markrmiller
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
> --
> - Mark
>
> http://about.me/markrmiller
>

Re: Call for help: moving from ant build to gradle

[Mark Miller]

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 systems can exist side by side (i.e. we can
> build master by executing some Gradle target and continue to build 8x with
> Ant like we always have) the minor inconvenience doesn’t merit standing in
> the way of progress.
>
> If that’s the case I don’t particularly care if we continue to use Ant
> with 8x forever. Or maybe some ambitious person can work on bringing 8x to
> Gradle after it has some mileage on master.
>
> And I have great faith that you wouldn’t be putting in the work unless you
> thought it was worth it ;)
>
> Erick
>
> > On May 4, 2019, at 10:31 PM, Mark Miller  wrote:
> >
> > 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 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 can handle regenerate.
> > >
> > > The other quality checks shouldn’t be crazy.
> > >
> > > So I guess we can probably do this, but before I focus on BS details,
> please speak up if you hate the idea of Gradle and you have the clout to
> stop it.
> > >
> > >
> > > Mark
> > >
> > >
> > >
> > >
> > > On Sat, May 4, 2019 at 5:56 PM Mark Miller 
> wrote:
> > >>
> > >> 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 in a root props file
> like we currently do and ensures we use the same versions in all modules
> even after auto conflict resolution (unlike gradle by default)
> > >> * It also locks versions so we can continue to pay attention to scary
> automatic dependency resolution changes
> > >> * implementation and api used instead of compile
> > >> * Things build and the majority of tests pass (Lucene's
> TestVirtualMethod does not for example)
> > >>
> > >> If someone like Uwe is serious about helping out with fun extras
> (regenerating sources, extracting data from ICU, quality checks,
> documentation (XSLT)), I'd look at contributing.
> > >>
> > >> - Mark
> > >>
> > >>
> > >> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh 
> wrote:
> > >>>
> > >>> Cool Diego,
> > >>>
> > >>> I will take a look on this. Thanks a lot!
> > >>
> > >>
> > >>
> > >> --
> > >> - Mark
> > >>
> > >> http://about.me/markrmiller
> > >
> > > --
> > > - Mark
> > >
> > > http://about.me/markrmiller
> >
> >
> > --
> > - Mark
> >
> > http://about.me/markrmiller
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
- Mark

http://about.me/markrmiller

Re: Call for help: moving from ant build to gradle

[Mark Miller]

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 changing things is painful. The maven shadow build is painful.

Switching to gradle means deleting tons of crap - all sorts of work arounds
and ant abuse go away.

gradle can be configured to do auto version resolution in a sensable way
for us - when done right, this is a large improvement over devs resolving
version conflicts on their own, ad hoc.

- Mark



On Sun, May 5, 2019 at 2:13 PM Dawid Weiss  wrote:

> 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 up-to-date daemon... but leaving
> stray processes behind on a CI machine is going to hurt sooner or
> later.
>
> Don't get me wrong -- I like gradle, really. But I've had enough "wtf"
> moments with it not to be too excited either. :)
>
> Dawid
>
> On Sun, May 5, 2019 at 8:50 PM Varun Thacker  wrote:
> >
> > 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=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16832997
> ) could benefit from caching though right?
> >
> > On Sun, May 5, 2019 at 11:39 AM Dawid Weiss 
> wrote:
> >>
> >> 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 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, 2019 at 9:37 AM Erick Erickson <
> erickerick...@gmail.com> 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 systems can exist side by side (i.e.
> we can build master by executing some Gradle target and continue to build
> 8x with Ant like we always have) the minor inconvenience doesn’t merit
> standing in the way of progress.
> >> >>
> >> >> If that’s the case I don’t particularly care if we continue to use
> Ant with 8x forever. Or maybe some ambitious person can work on bringing 8x
> to Gradle after it has some mileage on master.
> >> >>
> >> >> And I have great faith that you wouldn’t be putting in the work
> unless you thought it was worth it ;)
> >> >>
> >> >> Erick
> >> >>
> >> >> > On May 4, 2019, at 10:31 PM, Mark Miller 
> wrote:
> >> >> >
> >> >> > 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 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 can handle regenerate.
> >> >> > >
> >> >> > > The other quality checks shouldn’t be crazy.
> >> >> > >
> >> >> > > So I guess we can probably do this, but before I focus on BS
> details, please speak up if you hate the idea of Gradle and you have the
> clout to stop it.
> >> >> > >
> >> >> > >
> >> >> > > Mark
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > On Sat, May 4, 2019 at 5:56 PM Mark Miller <
> markrmil...@gmail.com> wrote:
> >> >> > >>
> >> >> > >> 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 in a root props
> file like we currently do and ensures we use the same versions in all
> modules even after auto conflict resolution (unlike gradle by default)
> >> >> > >> * It also locks versions so we can continue to pay attention to
> scary automatic dependency resolution changes
> >> >> > >> * implementation and api 

Re: Call for help: moving from ant build to gradle

[Dawid Weiss]

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 up-to-date daemon... but leaving
stray processes behind on a CI machine is going to hurt sooner or
later.

Don't get me wrong -- I like gradle, really. But I've had enough "wtf"
moments with it not to be too excited either. :)

Dawid

On Sun, May 5, 2019 at 8:50 PM Varun Thacker  wrote:
>
> 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=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16832997
>  ) could benefit from caching though right?
>
> On Sun, May 5, 2019 at 11:39 AM Dawid Weiss  wrote:
>>
>> 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 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, 2019 at 9:37 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 systems can exist side by side (i.e. we can 
>> >> build master by executing some Gradle target and continue to build 8x 
>> >> with Ant like we always have) the minor inconvenience doesn’t merit 
>> >> standing in the way of progress.
>> >>
>> >> If that’s the case I don’t particularly care if we continue to use Ant 
>> >> with 8x forever. Or maybe some ambitious person can work on bringing 8x 
>> >> to Gradle after it has some mileage on master.
>> >>
>> >> And I have great faith that you wouldn’t be putting in the work unless 
>> >> you thought it was worth it ;)
>> >>
>> >> Erick
>> >>
>> >> > On May 4, 2019, at 10:31 PM, Mark Miller  wrote:
>> >> >
>> >> > 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 
>> >> >  wrote:
>> >> > 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 can handle regenerate.
>> >> > >
>> >> > > The other quality checks shouldn’t be crazy.
>> >> > >
>> >> > > So I guess we can probably do this, but before I focus on BS details, 
>> >> > > please speak up if you hate the idea of Gradle and you have the clout 
>> >> > > to stop it.
>> >> > >
>> >> > >
>> >> > > Mark
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > > On Sat, May 4, 2019 at 5:56 PM Mark Miller  
>> >> > > wrote:
>> >> > >>
>> >> > >> 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 in a root props file 
>> >> > >> like we currently do and ensures we use the same versions in all 
>> >> > >> modules even after auto conflict resolution (unlike gradle by 
>> >> > >> default)
>> >> > >> * It also locks versions so we can continue to pay attention to 
>> >> > >> scary automatic dependency resolution changes
>> >> > >> * implementation and api used instead of compile
>> >> > >> * Things build and the majority of tests pass (Lucene's 
>> >> > >> TestVirtualMethod does not for example)
>> >> > >>
>> >> > >> If someone like Uwe is serious about helping out with fun extras 
>> >> > >> (regenerating sources, extracting data from ICU, quality checks, 
>> >> > >> documentation (XSLT)), I'd look at contributing.
>> >> > >>
>> >> > >> - Mark
>> >> > >>
>> >> > >>
>> >> > >> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh 
>> >> > >>  wrote:
>> >> > >>>
>> >> > >>> Cool Diego,
>> >> > >>>
>> >> > >>> I will take a look on this. Thanks a lot!
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >> --
>> >> > >> - Mark
>> >> > >>
>> >> > >> http://about.me/markrmiller
>> >> > >
>> >> > > --
>> >> > > - Mark
>> >> > >
>> >> > > 

Re: Call for help: moving from ant build to gradle

[Varun Thacker]

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=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16832997
) could benefit from caching though right?

On Sun, May 5, 2019 at 11:39 AM Dawid Weiss  wrote:

> 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 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, 2019 at 9:37 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 systems can exist side by side (i.e. we
> can build master by executing some Gradle target and continue to build 8x
> with Ant like we always have) the minor inconvenience doesn’t merit
> standing in the way of progress.
> >>
> >> If that’s the case I don’t particularly care if we continue to use Ant
> with 8x forever. Or maybe some ambitious person can work on bringing 8x to
> Gradle after it has some mileage on master.
> >>
> >> And I have great faith that you wouldn’t be putting in the work unless
> you thought it was worth it ;)
> >>
> >> Erick
> >>
> >> > On May 4, 2019, at 10:31 PM, Mark Miller 
> wrote:
> >> >
> >> > 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 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 can handle regenerate.
> >> > >
> >> > > The other quality checks shouldn’t be crazy.
> >> > >
> >> > > So I guess we can probably do this, but before I focus on BS
> details, please speak up if you hate the idea of Gradle and you have the
> clout to stop it.
> >> > >
> >> > >
> >> > > Mark
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > On Sat, May 4, 2019 at 5:56 PM Mark Miller 
> wrote:
> >> > >>
> >> > >> 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 in a root props
> file like we currently do and ensures we use the same versions in all
> modules even after auto conflict resolution (unlike gradle by default)
> >> > >> * It also locks versions so we can continue to pay attention to
> scary automatic dependency resolution changes
> >> > >> * implementation and api used instead of compile
> >> > >> * Things build and the majority of tests pass (Lucene's
> TestVirtualMethod does not for example)
> >> > >>
> >> > >> If someone like Uwe is serious about helping out with fun extras
> (regenerating sources, extracting data from ICU, quality checks,
> documentation (XSLT)), I'd look at contributing.
> >> > >>
> >> > >> - Mark
> >> > >>
> >> > >>
> >> > >> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh <
> caomanhdat...@gmail.com> wrote:
> >> > >>>
> >> > >>> Cool Diego,
> >> > >>>
> >> > >>> I will take a look on this. Thanks a lot!
> >> > >>
> >> > >>
> >> > >>
> >> > >> --
> >> > >> - Mark
> >> > >>
> >> > >> http://about.me/markrmiller
> >> > >
> >> > > --
> >> > > - Mark
> >> > >
> >> > > http://about.me/markrmiller
> >> >
> >> >
> >> > --
> >> > - Mark
> >> >
> >> > http://about.me/markrmiller
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Call for help: moving from ant build to gradle

[Dawid Weiss]

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 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, 2019 at 9:37 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 systems can exist side by side (i.e. we can 
>> build master by executing some Gradle target and continue to build 8x with 
>> Ant like we always have) the minor inconvenience doesn’t merit standing in 
>> the way of progress.
>>
>> If that’s the case I don’t particularly care if we continue to use Ant with 
>> 8x forever. Or maybe some ambitious person can work on bringing 8x to Gradle 
>> after it has some mileage on master.
>>
>> And I have great faith that you wouldn’t be putting in the work unless you 
>> thought it was worth it ;)
>>
>> Erick
>>
>> > On May 4, 2019, at 10:31 PM, Mark Miller  wrote:
>> >
>> > 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 
>> >  wrote:
>> > 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 can handle regenerate.
>> > >
>> > > The other quality checks shouldn’t be crazy.
>> > >
>> > > So I guess we can probably do this, but before I focus on BS details, 
>> > > please speak up if you hate the idea of Gradle and you have the clout to 
>> > > stop it.
>> > >
>> > >
>> > > Mark
>> > >
>> > >
>> > >
>> > >
>> > > On Sat, May 4, 2019 at 5:56 PM Mark Miller  wrote:
>> > >>
>> > >> 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 in a root props file 
>> > >> like we currently do and ensures we use the same versions in all 
>> > >> modules even after auto conflict resolution (unlike gradle by default)
>> > >> * It also locks versions so we can continue to pay attention to scary 
>> > >> automatic dependency resolution changes
>> > >> * implementation and api used instead of compile
>> > >> * Things build and the majority of tests pass (Lucene's 
>> > >> TestVirtualMethod does not for example)
>> > >>
>> > >> If someone like Uwe is serious about helping out with fun extras 
>> > >> (regenerating sources, extracting data from ICU, quality checks, 
>> > >> documentation (XSLT)), I'd look at contributing.
>> > >>
>> > >> - Mark
>> > >>
>> > >>
>> > >> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh  
>> > >> wrote:
>> > >>>
>> > >>> Cool Diego,
>> > >>>
>> > >>> I will take a look on this. Thanks a lot!
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> - Mark
>> > >>
>> > >> http://about.me/markrmiller
>> > >
>> > > --
>> > > - Mark
>> > >
>> > > http://about.me/markrmiller
>> >
>> >
>> > --
>> > - Mark
>> >
>> > http://about.me/markrmiller
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Call for help: moving from ant build to gradle

[Varun Thacker]

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, 2019 at 9:37 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 systems can exist side by side (i.e. we can
> build master by executing some Gradle target and continue to build 8x with
> Ant like we always have) the minor inconvenience doesn’t merit standing in
> the way of progress.
>
> If that’s the case I don’t particularly care if we continue to use Ant
> with 8x forever. Or maybe some ambitious person can work on bringing 8x to
> Gradle after it has some mileage on master.
>
> And I have great faith that you wouldn’t be putting in the work unless you
> thought it was worth it ;)
>
> Erick
>
> > On May 4, 2019, at 10:31 PM, Mark Miller  wrote:
> >
> > 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 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 can handle regenerate.
> > >
> > > The other quality checks shouldn’t be crazy.
> > >
> > > So I guess we can probably do this, but before I focus on BS details,
> please speak up if you hate the idea of Gradle and you have the clout to
> stop it.
> > >
> > >
> > > Mark
> > >
> > >
> > >
> > >
> > > On Sat, May 4, 2019 at 5:56 PM Mark Miller 
> wrote:
> > >>
> > >> 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 in a root props file
> like we currently do and ensures we use the same versions in all modules
> even after auto conflict resolution (unlike gradle by default)
> > >> * It also locks versions so we can continue to pay attention to scary
> automatic dependency resolution changes
> > >> * implementation and api used instead of compile
> > >> * Things build and the majority of tests pass (Lucene's
> TestVirtualMethod does not for example)
> > >>
> > >> If someone like Uwe is serious about helping out with fun extras
> (regenerating sources, extracting data from ICU, quality checks,
> documentation (XSLT)), I'd look at contributing.
> > >>
> > >> - Mark
> > >>
> > >>
> > >> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh 
> wrote:
> > >>>
> > >>> Cool Diego,
> > >>>
> > >>> I will take a look on this. Thanks a lot!
> > >>
> > >>
> > >>
> > >> --
> > >> - Mark
> > >>
> > >> http://about.me/markrmiller
> > >
> > > --
> > > - Mark
> > >
> > > http://about.me/markrmiller
> >
> >
> > --
> > - Mark
> >
> > http://about.me/markrmiller
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Call for help: moving from ant build to gradle

[Erick Erickson]

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 with Ant like 
we always have) the minor inconvenience doesn’t merit standing in the way of 
progress.

If that’s the case I don’t particularly care if we continue to use Ant with 8x 
forever. Or maybe some ambitious person can work on bringing 8x to Gradle after 
it has some mileage on master. 

And I have great faith that you wouldn’t be putting in the work unless you 
thought it was worth it ;)

Erick

> On May 4, 2019, at 10:31 PM, Mark Miller  wrote:
> 
> 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 
>  wrote:
> 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 can handle regenerate.
> >
> > The other quality checks shouldn’t be crazy.
> >
> > So I guess we can probably do this, but before I focus on BS details, 
> > please speak up if you hate the idea of Gradle and you have the clout to 
> > stop it.
> >
> >
> > Mark
> >
> >
> >
> >
> > On Sat, May 4, 2019 at 5:56 PM Mark Miller  wrote:
> >>
> >> 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 in a root props file like 
> >> we currently do and ensures we use the same versions in all modules even 
> >> after auto conflict resolution (unlike gradle by default)
> >> * It also locks versions so we can continue to pay attention to scary 
> >> automatic dependency resolution changes
> >> * implementation and api used instead of compile
> >> * Things build and the majority of tests pass (Lucene's TestVirtualMethod 
> >> does not for example)
> >>
> >> If someone like Uwe is serious about helping out with fun extras 
> >> (regenerating sources, extracting data from ICU, quality checks, 
> >> documentation (XSLT)), I'd look at contributing.
> >>
> >> - Mark
> >>
> >>
> >> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh  
> >> wrote:
> >>>
> >>> Cool Diego,
> >>>
> >>> I will take a look on this. Thanks a lot!
> >>
> >>
> >>
> >> --
> >> - Mark
> >>
> >> http://about.me/markrmiller
> >
> > --
> > - Mark
> >
> > http://about.me/markrmiller
> 
> 
> -- 
> - Mark
> 
> http://about.me/markrmiller


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Call for help: moving from ant build to gradle

[Mark Miller]

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 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 can handle regenerate.
> >
> > The other quality checks shouldn’t be crazy.
> >
> > So I guess we can probably do this, but before I focus on BS details,
> please speak up if you hate the idea of Gradle and you have the clout to
> stop it.
> >
> >
> > Mark
> >
> >
> >
> >
> > On Sat, May 4, 2019 at 5:56 PM Mark Miller 
> wrote:
> >>
> >> 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 in a root props file
> like we currently do and ensures we use the same versions in all modules
> even after auto conflict resolution (unlike gradle by default)
> >> * It also locks versions so we can continue to pay attention to scary
> automatic dependency resolution changes
> >> * implementation and api used instead of compile
> >> * Things build and the majority of tests pass (Lucene's
> TestVirtualMethod does not for example)
> >>
> >> If someone like Uwe is serious about helping out with fun extras
> (regenerating sources, extracting data from ICU, quality checks,
> documentation (XSLT)), I'd look at contributing.
> >>
> >> - Mark
> >>
> >>
> >> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh 
> wrote:
> >>>
> >>> Cool Diego,
> >>>
> >>> I will take a look on this. Thanks a lot!
> >>
> >>
> >>
> >> --
> >> - Mark
> >>
> >> http://about.me/markrmiller
> >
> > --
> > - Mark
> >
> > http://about.me/markrmiller
>


-- 
- Mark

http://about.me/markrmiller

Re: Call for help: moving from ant build to gradle

[Ishan Chattopadhyaya]

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 can handle regenerate.
>
> The other quality checks shouldn’t be crazy.
>
> So I guess we can probably do this, but before I focus on BS details, please 
> speak up if you hate the idea of Gradle and you have the clout to stop it.
>
>
> Mark
>
>
>
>
> On Sat, May 4, 2019 at 5:56 PM Mark Miller  wrote:
>>
>> 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 in a root props file like we 
>> currently do and ensures we use the same versions in all modules even after 
>> auto conflict resolution (unlike gradle by default)
>> * It also locks versions so we can continue to pay attention to scary 
>> automatic dependency resolution changes
>> * implementation and api used instead of compile
>> * Things build and the majority of tests pass (Lucene's TestVirtualMethod 
>> does not for example)
>>
>> If someone like Uwe is serious about helping out with fun extras 
>> (regenerating sources, extracting data from ICU, quality checks, 
>> documentation (XSLT)), I'd look at contributing.
>>
>> - Mark
>>
>>
>> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh  wrote:
>>>
>>> Cool Diego,
>>>
>>> I will take a look on this. Thanks a lot!
>>
>>
>>
>> --
>> - Mark
>>
>> http://about.me/markrmiller
>
> --
> - Mark
>
> http://about.me/markrmiller

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Call for help: moving from ant build to gradle

[Mark Miller]

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 before I focus on BS details,
please speak up if you hate the idea of Gradle and you have the clout to
stop it.


Mark




On Sat, May 4, 2019 at 5:56 PM Mark Miller  wrote:

> 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 in a root props file like
> we currently do and ensures we use the same versions in all modules even
> after auto conflict resolution (unlike gradle by default)
> * It also locks versions so we can continue to pay attention to scary
> automatic dependency resolution changes
> * implementation and api used instead of compile
> * Things build and the majority of tests pass (Lucene's TestVirtualMethod
> does not for example)
>
> If someone like Uwe is serious about helping out with fun extras
> (regenerating sources, extracting data from ICU, quality checks,
> documentation (XSLT)), I'd look at contributing.
>
> - Mark
>
>
> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh 
> wrote:
>
>> Cool Diego,
>>
>> I will take a look on this. Thanks a lot!
>>
>
>
> --
> - Mark
>
> http://about.me/markrmiller
>
-- 
- Mark

http://about.me/markrmiller

Re: Call for help: moving from ant build to gradle

[Mark Miller]

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 in a root props file like we
currently do and ensures we use the same versions in all modules even after
auto conflict resolution (unlike gradle by default)
* It also locks versions so we can continue to pay attention to scary
automatic dependency resolution changes
* implementation and api used instead of compile
* Things build and the majority of tests pass (Lucene's TestVirtualMethod
does not for example)

If someone like Uwe is serious about helping out with fun extras
(regenerating sources, extracting data from ICU, quality checks,
documentation (XSLT)), I'd look at contributing.

- Mark


On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh  wrote:

> Cool Diego,
>
> I will take a look on this. Thanks a lot!
>


-- 
- Mark

http://about.me/markrmiller

Re: Call for help: moving from ant build to gradle

[Đạt Cao Mạnh]

Cool Diego,

I will take a look on this. Thanks a lot!

Re: Call for help: moving from ant build to gradle

[Diego Ceccarelli]

Hi Đạt and all,

I made some progress starting from Đạt's patch:

- Now the patch compiles all the projects, and can be applied to the
upstream version
- I removed the changes to the source/test paths, and override the default
gradle paths to the one used by ant (so future commits will not create
conflicts)

I uploaded it in
https://github.com/diegoceccarelli/lucene-solr/tree/lucenesolr-gradle

You can play with the patch by running:

curl
https://github.com/diegoceccarelli/lucene-solr/commit/77b8cf36e93e1df2d23267dbe7dc16abf894fe58.patch
| git apply -v

from master, followed by './gradlew build'

There is still a lot of work to do:
- I didn't touch the tests (they might not compile)
- I tried to load it on intellij as a gradle project and it didn't work
- it doesn't produce a standalone jar
- some dependencies are probably out of sync, we should have something to
read them directly from the ivy configuration, or a script to convert
them..

Please let me know if you have any comments, PR are very welcome :)

Thanks,
Diego












On Thu, Mar 7, 2019 at 8:08 AM Martin Gainty  wrote:

> your argument that gradle is faster than maven is based on internal
> caching algorithm that gradle references
>
> IF you are *NOT* politically endangered from implementing maven i
> encourage you to take a hard look at
>
> "implementing caching of maven artifacts using cache-proxies"
>
> https://support.sonatype.com/hc/en-us/articles/115010182627-Understanding-Caching-Configuration
>
> <https://support.sonatype.com/hc/en-us/articles/115010182627-Understanding-Caching-Configuration>
> Understanding Caching Configuration – Sonatype Support
> <https://support.sonatype.com/hc/en-us/articles/115010182627-Understanding-Caching-Configuration>
> Proxy repositories use caching to improve build performance. The settings
> you can use to configure caching are described in this article
> support.sonatype.com
>
> as you can see speed is achieved when local proxy-cache is referenced
> 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:* 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 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 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 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
> has been widely used in many projects. There are several benefits of the
> moving here that I would like to mention
> * The capability of caching result in Gradle make running task much
> faster. I.e: rerunning forbiddenApi check in Gradle only takes 5 seconds
> (comparing to more than a minute of Ant).
> * Adding modules is much easier now.
> * Adding dependencies is a pleasure now since we don't have to run ant
> clean-idea and ant idea all over again.
> * Natively supported by different IDEs.
>
> On my very boring long flight from Montreal back to Vietnam, I tried to
> convert the Lucene/Solr Ant to Gradle, I finally achieved something here by
> being able to import project and run tests natively from IntelliJ IDEA
> (branch jira/gradle).
>
> I'm converting ant precommit for Lucene to Gradle. But there are a lot of
> things need to be done here and my limitation understanding in our Ant
> build and Gradle may make the work take a lot of time to finish.
>
> Therefore, I really need help from the community to finish the work and we
> will be able to move to a totally new, modern, powerful build tool.
>
> Thanks!
>
>
>
> --
> - Mark
>
> http://about.me/markrmiller
>
>
>
> --
> Best regards,
>
> Vladimir Kroz
> www.linkedin.com/in/*vkroz* <http://www.linkedin.com/in/vkroz>
> Phone: (707) 515-9195
>
>

Re: Call for help: moving from ant build to gradle

[Martin Gainty]

your argument that gradle is faster than maven is based on internal caching 
algorithm that gradle references

IF you are *NOT* politically endangered from implementing maven i encourage you 
to take a hard look at

"implementing caching of maven artifacts using cache-proxies"
https://support.sonatype.com/hc/en-us/articles/115010182627-Understanding-Caching-Configuration
[https://theme.zdassets.com/theme_assets/17748/b23a916dda693a523d66cc6230806788eaa710b6.png]<https://support.sonatype.com/hc/en-us/articles/115010182627-Understanding-Caching-Configuration>

Understanding Caching Configuration – Sonatype 
Support<https://support.sonatype.com/hc/en-us/articles/115010182627-Understanding-Caching-Configuration>
Proxy repositories use caching to improve build performance. The settings you 
can use to configure caching are described in this article
support.sonatype.com


as you can see speed is achieved when local proxy-cache is referenced 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: 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 
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 
mailto:vladimir.k...@gmail.com>> wrote:
+1 for moving to gradle. I'm happy to help.

On Wed, Dec 19, 2018 at 8:25 AM Mark Miller 
mailto:markrmil...@gmail.com>> 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 
mailto:caomanhdat...@gmail.com>> 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 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 has been widely used in 
many projects. There are several benefits of the moving here that I would like 
to mention
* The capability of caching result in Gradle make running task much faster. 
I.e: rerunning forbiddenApi check in Gradle only takes 5 seconds (comparing to 
more than a minute of Ant).
* Adding modules is much easier now.
* Adding dependencies is a pleasure now since we don't have to run ant 
clean-idea and ant idea all over again.
* Natively supported by different IDEs.

On my very boring long flight from Montreal back to Vietnam, I tried to convert 
the Lucene/Solr Ant to Gradle, I finally achieved something here by being able 
to import project and run tests natively from IntelliJ IDEA (branch 
jira/gradle).

I'm converting ant precommit for Lucene to Gradle. But there are a lot of 
things need to be done here and my limitation understanding in our Ant build 
and Gradle may make the work take a lot of time to finish.

Therefore, I really need help from the community to finish the work and we will 
be able to move to a totally new, modern, powerful build tool.

Thanks!



--
- Mark

http://about.me/markrmiller


--
Best regards,

Vladimir Kroz
www.linkedin.com/in/vkroz<http://www.linkedin.com/in/vkroz>
Phone: (707) 515-9195

Re: Call for help: moving from ant build to gradle

[Gézapeti]

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 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 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
>>> has been widely used in many projects. There are several benefits of the
>>> moving here that I would like to mention
>>> * The capability of caching result in Gradle make running task much
>>> faster. I.e: rerunning forbiddenApi check in Gradle only takes 5 seconds
>>> (comparing to more than a minute of Ant).
>>> * Adding modules is much easier now.
>>> * Adding dependencies is a pleasure now since we don't have to run ant
>>> clean-idea and ant idea all over again.
>>> * Natively supported by different IDEs.
>>>
>>> On my very boring long flight from Montreal back to Vietnam, I tried to
>>> convert the Lucene/Solr Ant to Gradle, I finally achieved something here by
>>> being able to import project and run tests natively from IntelliJ IDEA
>>> (branch jira/gradle).
>>>
>>> I'm converting ant precommit for Lucene to Gradle. But there are a lot
>>> of things need to be done here and my limitation understanding in our Ant
>>> build and Gradle may make the work take a lot of time to finish.
>>>
>>> Therefore, I really need help from the community to finish the work and
>>> we will be able to move to a totally new, modern, powerful build tool.
>>>
>>> Thanks!
>>>
>>>
>>
>> --
>> - Mark
>>
>> http://about.me/markrmiller
>>
>
>
> --
> Best regards,
>
> Vladimir Kroz
> www.linkedin.com/in/*vkroz* 
> Phone: (707) 515-9195
>

Re: Call for help: moving from ant build to gradle

[Vladimir Kroz]

+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 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
>> has been widely used in many projects. There are several benefits of the
>> moving here that I would like to mention
>> * The capability of caching result in Gradle make running task much
>> faster. I.e: rerunning forbiddenApi check in Gradle only takes 5 seconds
>> (comparing to more than a minute of Ant).
>> * Adding modules is much easier now.
>> * Adding dependencies is a pleasure now since we don't have to run ant
>> clean-idea and ant idea all over again.
>> * Natively supported by different IDEs.
>>
>> On my very boring long flight from Montreal back to Vietnam, I tried to
>> convert the Lucene/Solr Ant to Gradle, I finally achieved something here by
>> being able to import project and run tests natively from IntelliJ IDEA
>> (branch jira/gradle).
>>
>> I'm converting ant precommit for Lucene to Gradle. But there are a lot of
>> things need to be done here and my limitation understanding in our Ant
>> build and Gradle may make the work take a lot of time to finish.
>>
>> Therefore, I really need help from the community to finish the work and
>> we will be able to move to a totally new, modern, powerful build tool.
>>
>> Thanks!
>>
>>
>
> --
> - Mark
>
> http://about.me/markrmiller
>


-- 
Best regards,

Vladimir Kroz
www.linkedin.com/in/*vkroz* 
Phone: (707) 515-9195

Re: Call for help: moving from ant build to gradle

[Mark Miller]

+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
> 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
> has been widely used in many projects. There are several benefits of the
> moving here that I would like to mention
> * The capability of caching result in Gradle make running task much
> faster. I.e: rerunning forbiddenApi check in Gradle only takes 5 seconds
> (comparing to more than a minute of Ant).
> * Adding modules is much easier now.
> * Adding dependencies is a pleasure now since we don't have to run ant
> clean-idea and ant idea all over again.
> * Natively supported by different IDEs.
>
> On my very boring long flight from Montreal back to Vietnam, I tried to
> convert the Lucene/Solr Ant to Gradle, I finally achieved something here by
> being able to import project and run tests natively from IntelliJ IDEA
> (branch jira/gradle).
>
> I'm converting ant precommit for Lucene to Gradle. But there are a lot of
> things need to be done here and my limitation understanding in our Ant
> build and Gradle may make the work take a lot of time to finish.
>
> Therefore, I really need help from the community to finish the work and we
> will be able to move to a totally new, modern, powerful build tool.
>
> Thanks!
>
>

-- 
- Mark

http://about.me/markrmiller

Re: Call for help: moving from ant build to gradle

[Martin Gainty]

any reason for discriminating against a build system that supports customised 
lifecycles (e.g. maven)?

un saludo


From: Diego Ceccarelli (BLOOMBERG/ LONDON) 
Sent: Wednesday, November 21, 2018 5:30 AM
To: dev@lucene.apache.org
Subject: Re: Call for help: moving from ant build to gradle

Hi all,

I just noticed this thread I would be happy to help if I can.

I checked out the jira/gradle branch but I get conflicts if I try to rebase on 
top of the current master..

Do you have a list of subtasks for porting solr to gradle?

Thanks,
Diego




From: dev@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 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 
mailto:edward.ribe...@gmail.com>> wrote:
>
> Is this work open to contribution of non committers?
>
> Edward
>
>
> Em seg, 5 de nov de 2018 15:01, Gus Heck 
> mailto:gus.h...@gmail.com> escreveu:
>>
>> 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 
>> mailto:caomanhdat...@gmail.com>> 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 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 has been widely used in
many projects. There are several benefits of the moving here that I would like
to mention
>>> * The capability of caching result in Gradle make running task much faster.
I.e: rerunning forbiddenApi check in Gradle only takes 5 seconds (comparing to
more than a minute of Ant).
>>> * Adding modules is much easier now.
>>> * Adding dependencies is a pleasure now since we don't have to run ant
clean-idea and ant idea all over again.
>>> * Natively supported by different IDEs.
>>>
>>> On my very boring long flight from Montreal back to Vietnam, I tried to
convert the Lucene/Solr Ant to Gradle, I finally achieved something here by
being able to import project and run tests natively from IntelliJ IDEA (branch
jira/gradle).
>>>
>>> I'm converting ant precommit for Lucene to Gradle. But there are a lot of
things need to be done here and my limitation understanding in our Ant build
and Gradle may make the work take a lot of time to finish.
>>>
>>> Therefore, I really need help from the community to finish the work and we
will be able to move to a totally new, modern, powerful build tool.
>>>
>>> Thanks!
>>>
>>
>>
>> --
>> http://www.the111shift.com

-
To unsubscribe, e-mail: 
dev-unsubscr...@lucene.apache.org<mailto:dev-unsubscr...@lucene.apache.org>
For additional commands, e-mail: 
dev-h...@lucene.apache.org<mailto:dev-h...@lucene.apache.org>

Re: Call for help: moving from ant build to gradle

[Diego Ceccarelli (BLOOMBERG/ LONDON)]

Hi all, 

I just noticed this thread I would be happy to help if I can. 

I checked out the jira/gradle branch but I get conflicts if I try to rebase on 
top of the current master.. 

Do you have a list of subtasks for porting solr to gradle? 

Thanks,
Diego  


From: dev@lucene.apache.org At: 11/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 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 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,
>>>
>>> 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 has been widely used in 
many projects. There are several benefits of the moving here that I would like 
to mention
>>> * The capability of caching result in Gradle make running task much faster. 
I.e: rerunning forbiddenApi check in Gradle only takes 5 seconds (comparing to 
more than a minute of Ant).
>>> * Adding modules is much easier now.
>>> * Adding dependencies is a pleasure now since we don't have to run ant 
clean-idea and ant idea all over again.
>>> * Natively supported by different IDEs.
>>>
>>> On my very boring long flight from Montreal back to Vietnam, I tried to 
convert the Lucene/Solr Ant to Gradle, I finally achieved something here by 
being able to import project and run tests natively from IntelliJ IDEA (branch 
jira/gradle).
>>>
>>> I'm converting ant precommit for Lucene to Gradle. But there are a lot of 
things need to be done here and my limitation understanding in our Ant build 
and Gradle may make the work take a lot of time to finish.
>>>
>>> Therefore, I really need help from the community to finish the work and we 
will be able to move to a totally new, modern, powerful build tool.
>>>
>>> Thanks!
>>>
>>
>>
>> --
>> http://www.the111shift.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Call for help: moving from ant build to gradle

[Yago Riveiro]

Yago Riveiro smiled at you
Spark by Readdle

Re: Call for help: moving from ant build to gradle

[Erick Erickson]

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 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,
>>>
>>> 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 has been 
>>> widely used in many projects. There are several benefits of the moving here 
>>> that I would like to mention
>>> * The capability of caching result in Gradle make running task much faster. 
>>> I.e: rerunning forbiddenApi check in Gradle only takes 5 seconds (comparing 
>>> to more than a minute of Ant).
>>> * Adding modules is much easier now.
>>> * Adding dependencies is a pleasure now since we don't have to run ant 
>>> clean-idea and ant idea all over again.
>>> * Natively supported by different IDEs.
>>>
>>> On my very boring long flight from Montreal back to Vietnam, I tried to 
>>> convert the Lucene/Solr Ant to Gradle, I finally achieved something here by 
>>> being able to import project and run tests natively from IntelliJ IDEA 
>>> (branch jira/gradle).
>>>
>>> I'm converting ant precommit for Lucene to Gradle. But there are a lot of 
>>> things need to be done here and my limitation understanding in our Ant 
>>> build and Gradle may make the work take a lot of time to finish.
>>>
>>> Therefore, I really need help from the community to finish the work and we 
>>> will be able to move to a totally new, modern, powerful build tool.
>>>
>>> Thanks!
>>>
>>
>>
>> --
>> http://www.the111shift.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Call for help: moving from ant build to gradle

[Edward Ribeiro]

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 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,
>>
>> 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
>> has been widely used in many projects. There are several benefits of the
>> moving here that I would like to mention
>> * The capability of caching result in Gradle make running task much
>> faster. I.e: rerunning forbiddenApi check in Gradle only takes 5 seconds
>> (comparing to more than a minute of Ant).
>> * Adding modules is much easier now.
>> * Adding dependencies is a pleasure now since we don't have to run ant
>> clean-idea and ant idea all over again.
>> * Natively supported by different IDEs.
>>
>> On my very boring long flight from Montreal back to Vietnam, I tried to
>> convert the Lucene/Solr Ant to Gradle, I finally achieved something here by
>> being able to import project and run tests natively from IntelliJ IDEA
>> (branch jira/gradle).
>>
>> I'm converting ant precommit for Lucene to Gradle. But there are a lot of
>> things need to be done here and my limitation understanding in our Ant
>> build and Gradle may make the work take a lot of time to finish.
>>
>> Therefore, I really need help from the community to finish the work and
>> we will be able to move to a totally new, modern, powerful build tool.
>>
>> Thanks!
>>
>>
>
> --
> http://www.the111shift.com
>

Re: Call for help: moving from ant build to gradle

[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 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,
>
> 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
> has been widely used in many projects. There are several benefits of the
> moving here that I would like to mention
> * The capability of caching result in Gradle make running task much
> faster. I.e: rerunning forbiddenApi check in Gradle only takes 5 seconds
> (comparing to more than a minute of Ant).
> * Adding modules is much easier now.
> * Adding dependencies is a pleasure now since we don't have to run ant
> clean-idea and ant idea all over again.
> * Natively supported by different IDEs.
>
> On my very boring long flight from Montreal back to Vietnam, I tried to
> convert the Lucene/Solr Ant to Gradle, I finally achieved something here by
> being able to import project and run tests natively from IntelliJ IDEA
> (branch jira/gradle).
>
> I'm converting ant precommit for Lucene to Gradle. But there are a lot of
> things need to be done here and my limitation understanding in our Ant
> build and Gradle may make the work take a lot of time to finish.
>
> Therefore, I really need help from the community to finish the work and we
> will be able to move to a totally new, modern, powerful build tool.
>
> Thanks!
>
>

-- 
http://www.the111shift.com

Re: Call for help: moving from ant build to gradle

[Đạt Cao Mạnh]

Hi Uwe, yeah I think we should continue working on that branch, I will
do regularly make it up to date with master branch.

On Mon, Nov 5, 2018 at 3:44 PM Uwe Schindler  wrote:

> There is a branch already, this is why I mentioned "committing to branch":
>
> https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=shortlog;h=refs/heads/jira/gradle
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen=gmail=g>
> http://www.thetaphi.de
> eMail: 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 it on a branch for easier collaboration.
> > On Mon, Nov 5, 2018 at 7:24 AM Michael McCandless
> >  wrote:
> > >
> > > +1 to put latest progress onto a branch and iterate.
> > >
> > > Those benefits of Gradle over Ant sound compelling.
> > >
> > > Mike McCandless
> > >
> > > http://blog.mikemccandless.com
> > >
> > >
> > > On Mon, Nov 5, 2018 at 10:22 AM David Smiley
> >  wrote:
> > >>
> > >> Glad to see this Dat & Uwe!
> > >>
> > >> RE "Should we all commit to the branch for proceeding?"
> > >>
> > >> In this context do you mean are we "committed" to migrating to Gradle?
> > (+1 from me).  Or that future work should continue to use that branch?
> It
> > seems very logical to use a branch.
> > >>
> > >> ~ David
> > >>
> > >> On Mon, Nov 5, 2018 at 7:46 AM Uwe Schindler 
> > wrote:
> > >>>
> > >>> Hi Đạt,
> > >>>
> > >>>
> > >>>
> > >>> great work. I had some time to look into it, looks good as a start.
> I agree
> > there is a lot of work to be done, especially the additional tasks for
> > regenerating sources, extracting data from ICU, quality checks,
> > documentation (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
> > >>>
> > >>>
> > >>>
> > >>> -
> > >>>
> > >>> Uwe Schindler
> > >>>
> > >>> Achterdiek 19, D-28357 Bremen
> > >>>
> > >>> http://www.thetaphi.de
> > >>>
> > >>> eMail: u...@thetaphi.de
> > >>>
> > >>>
> > >>>
> > >>> From: Đạt Cao Mạnh 
> > >>> Sent: Sunday, November 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 module in our project. We reach the
> > limitation point of Ant and moving to Gradle seems a good option since
> it has
> > been widely used in many projects. There are several benefits of the
> moving
> > here that I would like to mention
> > >>>
> > >>> * The capability of caching result in Gradle make running task much
> > faster. I.e: rerunning forbiddenApi check in Gradle only takes 5 seconds
> > (comparing to more than a minute of Ant).
> > >>>
> > >>> * Adding modules is much easier now.
> > >>>
> > >>> * Adding dependencies is a pleasure now since we don't have to run
> ant
> > clean-idea and ant idea all over again.
> > >>>
> > >>> * Natively supported by different IDEs.
> > >>>
> > >>>
> > >>>
> > >>> On my very boring long flight from Montreal back to Vietnam, I tried
> to
> > convert the Lucene/Solr Ant to Gradle, I finally achieved something here
> by
> > being able to import project and run tests natively from IntelliJ IDEA
> (branch
> > jira/gradle).
> > >>>
> > >>>
> > >>>
> > >>> I'm converting ant precommit for Lucene to Gradle. But there are a
> lot of
> > things need to be done here and my limitation understanding in our Ant
> > build and Gradle may make the work take a lot of time to finish.
> > >>>
> > >>>
> > >>>
> > >>> Therefore, I really need help from the community to finish the work
> and
> > we will be able to move to a totally new, modern, powerful build tool.
> > >>>
> > >>>
> > >>>
> > >>> Thanks!
> > >>>
> > >>>
> > >>
> > >> --
> > >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> > http://www.solrenterprisesearchserver.com
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

RE: Call for help: moving from ant build to gradle

[Uwe Schindler]

There is a branch already, this is why I mentioned "committing to branch":
https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=shortlog;h=refs/heads/jira/gradle

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: 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 it on a branch for easier collaboration.
> On Mon, Nov 5, 2018 at 7:24 AM Michael McCandless
>  wrote:
> >
> > +1 to put latest progress onto a branch and iterate.
> >
> > Those benefits of Gradle over Ant sound compelling.
> >
> > Mike McCandless
> >
> > http://blog.mikemccandless.com
> >
> >
> > On Mon, Nov 5, 2018 at 10:22 AM David Smiley
>  wrote:
> >>
> >> Glad to see this Dat & Uwe!
> >>
> >> RE "Should we all commit to the branch for proceeding?"
> >>
> >> In this context do you mean are we "committed" to migrating to Gradle?
> (+1 from me).  Or that future work should continue to use that branch?  It
> seems very logical to use a branch.
> >>
> >> ~ David
> >>
> >> On Mon, Nov 5, 2018 at 7:46 AM Uwe Schindler 
> wrote:
> >>>
> >>> Hi Đạt,
> >>>
> >>>
> >>>
> >>> great work. I had some time to look into it, looks good as a start. I 
> >>> agree
> there is a lot of work to be done, especially the additional tasks for
> regenerating sources, extracting data from ICU, quality checks,
> documentation (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
> >>>
> >>>
> >>>
> >>> -
> >>>
> >>> Uwe Schindler
> >>>
> >>> Achterdiek 19, D-28357 Bremen
> >>>
> >>> http://www.thetaphi.de
> >>>
> >>> eMail: u...@thetaphi.de
> >>>
> >>>
> >>>
> >>> From: Đạt Cao Mạnh 
> >>> Sent: Sunday, November 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 module in our project. We reach the
> limitation point of Ant and moving to Gradle seems a good option since it has
> been widely used in many projects. There are several benefits of the moving
> here that I would like to mention
> >>>
> >>> * The capability of caching result in Gradle make running task much
> faster. I.e: rerunning forbiddenApi check in Gradle only takes 5 seconds
> (comparing to more than a minute of Ant).
> >>>
> >>> * Adding modules is much easier now.
> >>>
> >>> * Adding dependencies is a pleasure now since we don't have to run ant
> clean-idea and ant idea all over again.
> >>>
> >>> * Natively supported by different IDEs.
> >>>
> >>>
> >>>
> >>> On my very boring long flight from Montreal back to Vietnam, I tried to
> convert the Lucene/Solr Ant to Gradle, I finally achieved something here by
> being able to import project and run tests natively from IntelliJ IDEA (branch
> jira/gradle).
> >>>
> >>>
> >>>
> >>> I'm converting ant precommit for Lucene to Gradle. But there are a lot of
> things need to be done here and my limitation understanding in our Ant
> build and Gradle may make the work take a lot of time to finish.
> >>>
> >>>
> >>>
> >>> Therefore, I really need help from the community to finish the work and
> we will be able to move to a totally new, modern, powerful build tool.
> >>>
> >>>
> >>>
> >>> Thanks!
> >>>
> >>>
> >>
> >> --
> >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Call for help: moving from ant build to gradle

[Erick Erickson]

Seems more efficient to put it on a branch for easier collaboration.
On Mon, Nov 5, 2018 at 7:24 AM Michael McCandless
 wrote:
>
> +1 to put latest progress onto a branch and iterate.
>
> Those benefits of Gradle over Ant sound compelling.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Mon, Nov 5, 2018 at 10:22 AM David Smiley  wrote:
>>
>> Glad to see this Dat & Uwe!
>>
>> RE "Should we all commit to the branch for proceeding?"
>>
>> In this context do you mean are we "committed" to migrating to Gradle?  (+1 
>> from me).  Or that future work should continue to use that branch?  It seems 
>> very logical to use a branch.
>>
>> ~ David
>>
>> On Mon, Nov 5, 2018 at 7:46 AM Uwe Schindler  wrote:
>>>
>>> Hi Đạt,
>>>
>>>
>>>
>>> great work. I had some time to look into it, looks good as a start. I agree 
>>> there is a lot of work to be done, especially the additional tasks for 
>>> regenerating sources, extracting data from ICU, quality checks, 
>>> documentation (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
>>>
>>>
>>>
>>> -
>>>
>>> Uwe Schindler
>>>
>>> Achterdiek 19, D-28357 Bremen
>>>
>>> http://www.thetaphi.de
>>>
>>> eMail: u...@thetaphi.de
>>>
>>>
>>>
>>> From: Đạt Cao Mạnh 
>>> Sent: Sunday, November 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 module in our project. We reach the limitation 
>>> point of Ant and moving to Gradle seems a good option since it has been 
>>> widely used in many projects. There are several benefits of the moving here 
>>> that I would like to mention
>>>
>>> * The capability of caching result in Gradle make running task much faster. 
>>> I.e: rerunning forbiddenApi check in Gradle only takes 5 seconds (comparing 
>>> to more than a minute of Ant).
>>>
>>> * Adding modules is much easier now.
>>>
>>> * Adding dependencies is a pleasure now since we don't have to run ant 
>>> clean-idea and ant idea all over again.
>>>
>>> * Natively supported by different IDEs.
>>>
>>>
>>>
>>> On my very boring long flight from Montreal back to Vietnam, I tried to 
>>> convert the Lucene/Solr Ant to Gradle, I finally achieved something here by 
>>> being able to import project and run tests natively from IntelliJ IDEA 
>>> (branch jira/gradle).
>>>
>>>
>>>
>>> I'm converting ant precommit for Lucene to Gradle. But there are a lot of 
>>> things need to be done here and my limitation understanding in our Ant 
>>> build and Gradle may make the work take a lot of time to finish.
>>>
>>>
>>>
>>> Therefore, I really need help from the community to finish the work and we 
>>> will be able to move to a totally new, modern, powerful build tool.
>>>
>>>
>>>
>>> Thanks!
>>>
>>>
>>
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
>> http://www.solrenterprisesearchserver.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Call for help: moving from ant build to gradle

[Michael McCandless]

+1 to put latest progress onto a branch and iterate.

Those benefits of Gradle over Ant sound compelling.

Mike McCandless

http://blog.mikemccandless.com


On Mon, Nov 5, 2018 at 10:22 AM David Smiley 
wrote:

> Glad to see this Dat & Uwe!
>
> RE "Should we all commit to the branch for proceeding?"
>
> In this context do you mean are we "committed" to migrating to Gradle?
>  (+1 from me).  Or that future work should continue to use that branch?  It
> seems very logical to use a branch.
>
> ~ David
>
> On Mon, Nov 5, 2018 at 7:46 AM Uwe Schindler  wrote:
>
>> Hi Đạt,
>>
>>
>>
>> great work. I had some time to look into it, looks good as a start. I
>> agree there is a lot of work to be done, especially the additional tasks
>> for regenerating sources, extracting data from ICU, quality checks,
>> documentation (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
>>
>>
>>
>> -
>>
>> Uwe Schindler
>>
>> Achterdiek 19, D-28357 Bremen
>> <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen=gmail=g>
>>
>> http://www.thetaphi.de
>>
>> eMail: u...@thetaphi.de
>>
>>
>>
>> *From:* Đạt Cao Mạnh 
>> *Sent:* Sunday, November 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 module in our project. We reach the
>> limitation point of Ant and moving to Gradle seems a good option since it
>> has been widely used in many projects. There are several benefits of the
>> moving here that I would like to mention
>>
>> * The capability of caching result in Gradle make running task much
>> faster. I.e: rerunning forbiddenApi check in Gradle only takes 5 seconds
>> (comparing to more than a minute of Ant).
>>
>> * Adding modules is much easier now.
>>
>> * Adding dependencies is a pleasure now since we don't have to run ant
>> clean-idea and ant idea all over again.
>>
>> * Natively supported by different IDEs.
>>
>>
>>
>> On my very boring long flight from Montreal back to Vietnam, I tried to
>> convert the Lucene/Solr Ant to Gradle, I finally achieved something here by
>> being able to import project and run tests natively from IntelliJ IDEA
>> (branch jira/gradle).
>>
>>
>>
>> I'm converting ant precommit for Lucene to Gradle. But there are a lot of
>> things need to be done here and my limitation understanding in our Ant
>> build and Gradle may make the work take a lot of time to finish.
>>
>>
>>
>> Therefore, I really need help from the community to finish the work and
>> we will be able to move to a totally new, modern, powerful build tool.
>>
>>
>>
>> Thanks!
>>
>>
>>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>

Re: Call for help: moving from ant build to gradle

[David Smiley]

Glad to see this Dat & Uwe!

RE "Should we all commit to the branch for proceeding?"

In this context do you mean are we "committed" to migrating to Gradle?  (+1
from me).  Or that future work should continue to use that branch?  It
seems very logical to use a branch.

~ David

On Mon, Nov 5, 2018 at 7:46 AM Uwe Schindler  wrote:

> Hi Đạt,
>
>
>
> great work. I had some time to look into it, looks good as a start. I
> agree there is a lot of work to be done, especially the additional tasks
> for regenerating sources, extracting data from ICU, quality checks,
> documentation (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
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
> <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen=gmail=g>
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Đạt Cao Mạnh 
> *Sent:* Sunday, November 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 module in our project. We reach the
> limitation point of Ant and moving to Gradle seems a good option since it
> has been widely used in many projects. There are several benefits of the
> moving here that I would like to mention
>
> * The capability of caching result in Gradle make running task much
> faster. I.e: rerunning forbiddenApi check in Gradle only takes 5 seconds
> (comparing to more than a minute of Ant).
>
> * Adding modules is much easier now.
>
> * Adding dependencies is a pleasure now since we don't have to run ant
> clean-idea and ant idea all over again.
>
> * Natively supported by different IDEs.
>
>
>
> On my very boring long flight from Montreal back to Vietnam, I tried to
> convert the Lucene/Solr Ant to Gradle, I finally achieved something here by
> being able to import project and run tests natively from IntelliJ IDEA
> (branch jira/gradle).
>
>
>
> I'm converting ant precommit for Lucene to Gradle. But there are a lot of
> things need to be done here and my limitation understanding in our Ant
> build and Gradle may make the work take a lot of time to finish.
>
>
>
> Therefore, I really need help from the community to finish the work and we
> will be able to move to a totally new, modern, powerful build tool.
>
>
>
> Thanks!
>
>
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

RE: Call for help: moving from ant build to gradle

[Uwe Schindler]

Hi Đạt,

 

great work. I had some time to look into it, looks good as a start. I agree 
there is a lot of work to be done, especially the additional tasks for 
regenerating sources, extracting data from ICU, quality checks, documentation 
(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

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

 <http://www.thetaphi.de/> http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Đạt Cao Mạnh  
Sent: Sunday, November 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 module in our project. We reach the limitation point of 
Ant and moving to Gradle seems a good option since it has been widely used in 
many projects. There are several benefits of the moving here that I would like 
to mention

* The capability of caching result in Gradle make running task much faster. 
I.e: rerunning forbiddenApi check in Gradle only takes 5 seconds (comparing to 
more than a minute of Ant).

* Adding modules is much easier now.

* Adding dependencies is a pleasure now since we don't have to run ant 
clean-idea and ant idea all over again.

* Natively supported by different IDEs.

 

On my very boring long flight from Montreal back to Vietnam, I tried to convert 
the Lucene/Solr Ant to Gradle, I finally achieved something here by being able 
to import project and run tests natively from IntelliJ IDEA (branch 
jira/gradle).

 

I'm converting ant precommit for Lucene to Gradle. But there are a lot of 
things need to be done here and my limitation understanding in our Ant build 
and Gradle may make the work take a lot of time to finish.

 

Therefore, I really need help from the community to finish the work and we will 
be able to move to a totally new, modern, powerful build tool.

 

Thanks!

 

Call for help: moving from ant build to gradle

[Đạt Cao Mạnh]

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 has been
widely used in many projects. There are several benefits of the moving here
that I would like to mention
* The capability of caching result in Gradle make running task much faster.
I.e: rerunning forbiddenApi check in Gradle only takes 5 seconds (comparing
to more than a minute of Ant).
* Adding modules is much easier now.
* Adding dependencies is a pleasure now since we don't have to run ant
clean-idea and ant idea all over again.
* Natively supported by different IDEs.

On my very boring long flight from Montreal back to Vietnam, I tried to
convert the Lucene/Solr Ant to Gradle, I finally achieved something here by
being able to import project and run tests natively from IntelliJ IDEA
(branch jira/gradle).

I'm converting ant precommit for Lucene to Gradle. But there are a lot of
things need to be done here and my limitation understanding in our Ant
build and Gradle may make the work take a lot of time to finish.

Therefore, I really need help from the community to finish the work and we
will be able to move to a totally new, modern, powerful build tool.

Thanks!