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 <[email protected]> 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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
> > <mailto:[email protected]>> 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 <[email protected]
> >> <mailto:[email protected]>> wrote:
> >>>
> >>> We can indeed make them work side by side.
> >>>
> >>> - Mark
> >>>
> >>> On Sun, May 5, 2019 at 11:36 AM Erick Erickson <[email protected]
> >>> <mailto:[email protected]>> 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 <[email protected]
> >>>> > <mailto:[email protected]>> 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
> >>>> > <[email protected] <mailto:[email protected]>> wrote:
> >>>> > Would beasting of tests be possible through gradle?
> >>>> >
> >>>> > On Sun, May 5, 2019 at 7:33 AM Mark Miller <[email protected]
> >>>> > <mailto:[email protected]>> 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 <[email protected]
> >>>> > > <mailto:[email protected]>> 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
> >>>> > >> <[email protected] <mailto:[email protected]>> 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: [email protected]
> >>>> <mailto:[email protected]>
> >>>> For additional commands, e-mail: [email protected]
> >>>> <mailto:[email protected]>
> >>>>
> >>>
> >>>
> >>> --
> >>> - 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>
