You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Mark Miller <ma...@gmail.com> on 2019/05/04 22:56:48 UTC
Re: Call for help: moving from ant build to gradle
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 <ca...@gmail.com> 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
Posted by Shawn Heisey <ap...@elyograg.org>.
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Call for help: moving from ant build to gradle
Posted by Mark Miller <ma...@gmail.com>.
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
Posted by Mark Miller <ma...@gmail.com>.
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 <gu...@gmail.com> 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 <ma...@gmail.com> 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
Posted by Gus Heck <gu...@gmail.com>.
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 <ma...@gmail.com> 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
Posted by Mark Miller <ma...@gmail.com>.
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
Posted by Erik Hatcher <er...@gmail.com>.
As the ol' "Ant guy" curmudgeon, with no active clout, ..... I'm all for this modernization effort +1 Kudos 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 <ma...@gmail.com> 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 <dawid.weiss@gmail.com <ma...@gmail.com>> 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 <markrmiller@gmail.com <ma...@gmail.com>> 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 <david.w.smiley@gmail.com <ma...@gmail.com>> 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 <http://www.linkedin.com/in/davidwsmiley>
> >>
> >>
> >> On Sun, May 5, 2019 at 6:23 PM Mark Miller <markrmiller@gmail.com <ma...@gmail.com>> wrote:
> >>>
> >>> We can indeed make them work side by side.
> >>>
> >>> - Mark
> >>>
> >>> On Sun, May 5, 2019 at 11:36 AM Erick Erickson <erickerickson@gmail.com <ma...@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 <markrmiller@gmail.com <ma...@gmail.com>> 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 <ichattopadhyaya@gmail.com <ma...@gmail.com>> wrote:
> >>>> > Would beasting of tests be possible through gradle?
> >>>> >
> >>>> > On Sun, May 5, 2019 at 7:33 AM Mark Miller <markrmiller@gmail.com <ma...@gmail.com>> 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 <markrmiller@gmail.com <ma...@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 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 <caomanhdat317@gmail.com <ma...@gmail.com>> wrote:
> >>>> > >>>
> >>>> > >>> Cool Diego,
> >>>> > >>>
> >>>> > >>> I will take a look on this. Thanks a lot!
> >>>> > >>
> >>>> > >>
> >>>> > >>
> >>>> > >> --
> >>>> > >> - Mark
> >>>> > >>
> >>>> > >> http://about.me/markrmiller <http://about.me/markrmiller>
> >>>> > >
> >>>> > > --
> >>>> > > - Mark
> >>>> > >
> >>>> > > http://about.me/markrmiller <http://about.me/markrmiller>
> >>>> >
> >>>> >
> >>>> > --
> >>>> > - Mark
> >>>> >
> >>>> > http://about.me/markrmiller <http://about.me/markrmiller>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> >>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> >>>>
> >>>
> >>>
> >>> --
> >>> - Mark
> >>>
> >>> http://about.me/markrmiller <http://about.me/markrmiller>
> >
> >
> >
> > --
> > - Mark
> >
> > http://about.me/markrmiller <http://about.me/markrmiller>
>
>
> --
> - Mark
>
> http://about.me/markrmiller <http://about.me/markrmiller>
Re: Call for help: moving from ant build to gradle
Posted by Erick Erickson <er...@gmail.com>.
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 <ma...@gmail.com> 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 <da...@gmail.com> 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 <ma...@gmail.com> 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 <da...@gmail.com> 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 <ma...@gmail.com> wrote:
> >>>
> >>> We can indeed make them work side by side.
> >>>
> >>> - Mark
> >>>
> >>> On Sun, May 5, 2019 at 11:36 AM Erick Erickson <er...@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 <ma...@gmail.com> 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 <ic...@gmail.com> wrote:
> >>>> > Would beasting of tests be possible through gradle?
> >>>> >
> >>>> > On Sun, May 5, 2019 at 7:33 AM Mark Miller <ma...@gmail.com> 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 <ma...@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 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 <ca...@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-unsubscribe@lucene.apache.org
> >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>
> >>>
> >>>
> >>> --
> >>> - Mark
> >>>
> >>> http://about.me/markrmiller
> >
> >
> >
> > --
> > - Mark
> >
> > http://about.me/markrmiller
>
>
> --
> - Mark
>
> http://about.me/markrmiller
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Call for help: moving from ant build to gradle
Posted by Mark Miller <ma...@gmail.com>.
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 <da...@gmail.com> 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 <ma...@gmail.com> 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 <da...@gmail.com>
> 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 <ma...@gmail.com>
> wrote:
> >>>
> >>> We can indeed make them work side by side.
> >>>
> >>> - Mark
> >>>
> >>> On Sun, May 5, 2019 at 11:36 AM Erick Erickson <
> erickerickson@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 <ma...@gmail.com>
> 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 <
> ichattopadhyaya@gmail.com> wrote:
> >>>> > Would beasting of tests be possible through gradle?
> >>>> >
> >>>> > On Sun, May 5, 2019 at 7:33 AM Mark Miller <ma...@gmail.com>
> 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 <ma...@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 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 <
> caomanhdat317@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-unsubscribe@lucene.apache.org
> >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>
> >>>
> >>>
> >>> --
> >>> - 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
Posted by Dawid Weiss <da...@gmail.com>.
> 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 <ma...@gmail.com> 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 <da...@gmail.com> 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 <ma...@gmail.com> wrote:
>>>
>>> We can indeed make them work side by side.
>>>
>>> - Mark
>>>
>>> On Sun, May 5, 2019 at 11:36 AM Erick Erickson <er...@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 <ma...@gmail.com> 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 <ic...@gmail.com> wrote:
>>>> > Would beasting of tests be possible through gradle?
>>>> >
>>>> > On Sun, May 5, 2019 at 7:33 AM Mark Miller <ma...@gmail.com> 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 <ma...@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 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 <ca...@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-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>
>>>
>>> --
>>> - Mark
>>>
>>> http://about.me/markrmiller
>
>
>
> --
> - Mark
>
> http://about.me/markrmiller
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Call for help: moving from ant build to gradle
Posted by Mark Miller <ma...@gmail.com>.
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 <da...@gmail.com>
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 <ma...@gmail.com> wrote:
>
>> We can indeed make them work side by side.
>>
>> - Mark
>>
>> On Sun, May 5, 2019 at 11:36 AM Erick Erickson <er...@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 <ma...@gmail.com>
>>> 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 <
>>> ichattopadhyaya@gmail.com> wrote:
>>> > Would beasting of tests be possible through gradle?
>>> >
>>> > On Sun, May 5, 2019 at 7:33 AM Mark Miller <ma...@gmail.com>
>>> 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 <ma...@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 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 <
>>> caomanhdat317@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-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>>
>> --
>> - Mark
>>
>> http://about.me/markrmiller
>>
>
--
- Mark
http://about.me/markrmiller
Re: Call for help: moving from ant build to gradle
Posted by David Smiley <da...@gmail.com>.
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 <ma...@gmail.com> wrote:
> We can indeed make them work side by side.
>
> - Mark
>
> On Sun, May 5, 2019 at 11:36 AM Erick Erickson <er...@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 <ma...@gmail.com> 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 <
>> ichattopadhyaya@gmail.com> wrote:
>> > Would beasting of tests be possible through gradle?
>> >
>> > On Sun, May 5, 2019 at 7:33 AM Mark Miller <ma...@gmail.com>
>> 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 <ma...@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 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 <ca...@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
> --
> - Mark
>
> http://about.me/markrmiller
>
Re: Call for help: moving from ant build to gradle
Posted by Mark Miller <ma...@gmail.com>.
We can indeed make them work side by side.
- Mark
On Sun, May 5, 2019 at 11:36 AM Erick Erickson <er...@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 <ma...@gmail.com> 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 <
> ichattopadhyaya@gmail.com> wrote:
> > Would beasting of tests be possible through gradle?
> >
> > On Sun, May 5, 2019 at 7:33 AM Mark Miller <ma...@gmail.com>
> 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 <ma...@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 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 <ca...@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
- Mark
http://about.me/markrmiller
Re: Call for help: moving from ant build to gradle
Posted by Mark Miller <ma...@gmail.com>.
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 <da...@gmail.com> 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 <va...@vthacker.in> 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&page=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 <da...@gmail.com>
> 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 <va...@vthacker.in> 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 <
> erickerickson@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 <ma...@gmail.com>
> 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 <
> ichattopadhyaya@gmail.com> wrote:
> >> >> > Would beasting of tests be possible through gradle?
> >> >> >
> >> >> > On Sun, May 5, 2019 at 7:33 AM Mark Miller <ma...@gmail.com>
> 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 <
> markrmiller@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 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 <
> caomanhdat317@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-unsubscribe@lucene.apache.org
> >> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
- Mark
http://about.me/markrmiller
Re: Call for help: moving from ant build to gradle
Posted by Dawid Weiss <da...@gmail.com>.
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 <va...@vthacker.in> 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&page=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 <da...@gmail.com> 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 <va...@vthacker.in> 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 <er...@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 <ma...@gmail.com> 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 <ic...@gmail.com> wrote:
>> >> > Would beasting of tests be possible through gradle?
>> >> >
>> >> > On Sun, May 5, 2019 at 7:33 AM Mark Miller <ma...@gmail.com> 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 <ma...@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 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 <ca...@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-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Call for help: moving from ant build to gradle
Posted by Varun Thacker <va...@vthacker.in>.
I think you're right on the tests part.
Task that are run by the QA Bot (
https://issues.apache.org/jira/browse/SOLR-13049?focusedCommentId=16832997&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16832997
) could benefit from caching though right?
On Sun, May 5, 2019 at 11:39 AM Dawid Weiss <da...@gmail.com> 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 <va...@vthacker.in> 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 <er...@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 <ma...@gmail.com>
> 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 <
> ichattopadhyaya@gmail.com> wrote:
> >> > Would beasting of tests be possible through gradle?
> >> >
> >> > On Sun, May 5, 2019 at 7:33 AM Mark Miller <ma...@gmail.com>
> 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 <ma...@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 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 <
> caomanhdat317@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-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Call for help: moving from ant build to gradle
Posted by Dawid Weiss <da...@gmail.com>.
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 <va...@vthacker.in> 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 <er...@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 <ma...@gmail.com> 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 <ic...@gmail.com> wrote:
>> > Would beasting of tests be possible through gradle?
>> >
>> > On Sun, May 5, 2019 at 7:33 AM Mark Miller <ma...@gmail.com> 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 <ma...@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 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 <ca...@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Call for help: moving from ant build to gradle
Posted by Varun Thacker <va...@vthacker.in>.
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 <er...@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 <ma...@gmail.com> 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 <
> ichattopadhyaya@gmail.com> wrote:
> > Would beasting of tests be possible through gradle?
> >
> > On Sun, May 5, 2019 at 7:33 AM Mark Miller <ma...@gmail.com>
> 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 <ma...@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 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 <ca...@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Call for help: moving from ant build to gradle
Posted by Erick Erickson <er...@gmail.com>.
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 <ma...@gmail.com> 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 <ic...@gmail.com> wrote:
> Would beasting of tests be possible through gradle?
>
> On Sun, May 5, 2019 at 7:33 AM Mark Miller <ma...@gmail.com> 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 <ma...@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 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 <ca...@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Call for help: moving from ant build to gradle
Posted by Mark Miller <ma...@gmail.com>.
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 <
ichattopadhyaya@gmail.com> wrote:
> Would beasting of tests be possible through gradle?
>
> On Sun, May 5, 2019 at 7:33 AM Mark Miller <ma...@gmail.com> 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 <ma...@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 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 <ca...@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
Re: Call for help: moving from ant build to gradle
Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
Would beasting of tests be possible through gradle?
On Sun, May 5, 2019 at 7:33 AM Mark Miller <ma...@gmail.com> 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 <ma...@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 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 <ca...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Call for help: moving from ant build to gradle
Posted by Mark Miller <ma...@gmail.com>.
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 <ma...@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 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 <ca...@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