lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <erik.hatc...@gmail.com>
Subject Re: Call for help: moving from ant build to gradle
Date Mon, 06 May 2019 15:02:57 GMT
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 <markrmiller@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 <mailto:dawid.weiss@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 <mailto:markrmiller@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 <mailto:david.w.smiley@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 <mailto:markrmiller@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
<mailto: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 <markrmiller@gmail.com
<mailto:markrmiller@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
<mailto:ichattopadhyaya@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
<mailto:markrmiller@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
<mailto: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
<mailto:caomanhdat317@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 <mailto:dev-unsubscribe@lucene.apache.org>
> >>>> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@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>


Mime
View raw message