I agree. Although I also understand the concern of trying to merge the changes while we're in the transition period... it'd be hell. I'd say move as much stuff as possible with the current folder structure (and ignore what cannot be ported easily) then switch as soon as possible to gradle and hack the old cruft with a chainsaw...
D. On Thu, Sep 26, 2019 at 2:13 PM Erick Erickson <erickerick...@gmail.com> wrote: > > Of course I’ll completely defer to Dawid and Mark (well and anybody else > actually, you know, doing _work_), but just can’t resist chiming in ;). > > My vote would be to “do it the Gradle way”. Yes, it’s a PITA to learn new > stuff and I won’t like it. Tough. I see no reason to carry a bunch of cruft > around because “that the way we always did it”. > > If we lose functionality, that’s a different discussion, starting with “do we > need that functionality". But jumping through hoops and having to maintain > that awkwardness forever going forward just because we forced the Ant > structure on Gradle strikes me as a poor trade off. > > That said, I’m not doing the work so I really have no vote. But don’t strain > to do it the old way on my account ;) > > Erick > > P.S. Thanks Dawid for jumping in! > > > On Sep 26, 2019, at 3:57 AM, Dawid Weiss <dawid.we...@gmail.com> wrote: > > > > I pushed it in to Lucene repo (it's on Cassandra's refguide branch > > anyway, so shouldn't interfere with anything else); seems like it's in > > better shape than previous code anyway (those questions I asked about > > the nature of the gradle port still hold though). > > > > I got as far as building initial bare-bones HTML. > > > > .\gradlew -p solr\solr-ref-guide clean bareBonesHtmlValidation > > > > I don't know anything about the pipeline involved (asciidoctor, etc.) > > so it's very likely some attributes will have to be corrected later > > on. > > > > Dawid > > > > On Wed, Sep 25, 2019 at 9:14 PM Dawid Weiss <dawid.we...@gmail.com> wrote: > >> > >> I looked at the solr ref guide build and started converting it to > >> Gradle but have a question to Mark (because he coordinates the > >> effort). > >> > >> What immediately jumps into face is the decision problem -- do we want > >> to emulate what ant does at the moment or do we want to clean it up > >> (breaking file/ folder structure and causing incompatibility with ant > >> build). > >> > >> I went the "compatible" way and started porting ant tasks but it's > >> quite awkward. For example -- there are template properties that refer > >> to ivy version properties... we could emulate/ compute these but it's > >> a pain. The way the module is currently structured is also awkward - > >> it'd be more natural to have a separate java project with the "tools" > >> required to compile extra stuff and just reference it from the manual > >> build (and this would be a plain module, not a java module). This > >> would limit the need for customizing source sets, classpaths, etc. > >> > >> My few initial tasks syncing sources, setting up infrastructure to > >> filter templates and compiling the required tools are here: > >> https://github.com/apache/lucene-solr/compare/jira/SOLR-13452_gradle_7_refguide...dweiss:jira/SOLR-13452_gradle_7_refguide?expand=1 > >> > >> I'll stop and wait for feedback (especially on the ivy versions issue) > >> before I resume. > >> > >> Dawid > >> > >> On Wed, Sep 25, 2019 at 6:20 PM Dawid Weiss <dawid.we...@gmail.com> wrote: > >>> > >>> Never mind, I've got it. > >>> > >>> D. > >>> > >>> On Wed, Sep 25, 2019 at 7:59 AM Dawid Weiss <dawid.we...@gmail.com> wrote: > >>>> > >>>> Hi Cassandra, > >>>> > >>>>> I’m more than happy to share more details our current build so we can > >>>>> replicate some of the above steps, but I’m stuck without a lot more > >>>>> basic Gradle skills that I don’t have time to acquire with > >>>>> day-job/personal life commitments. I put it into a separate branch so > >>>>> we could iterate a little easier, can anyone help? > >>>> > >>>> Where is this branch you made changes on? If you can point me at the > >>>> corresponding ant code I'll try to help you out. > >>>> > >>>> Dawid > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
