[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16966715#comment-16966715
]
Erick Erickson commented on SOLR-13452:
---------------------------------------
Why not just push it to master (and maybe 8x)? I'll volunteer. From a quick
scan I see:
- lots of changes to test files. I did a spot check and those appear to be
almost all annotations.
- the ant build still works (at least precommit, dest, and build). What do we
lose by pushing? I suppose if we abandon Gradle, there'll be some cruft, but we
can deal with that later.
- the ant build will become cruft. I'll open a JIRA if I can't find one already
to remove it when gradle is "close enough", which will _probably_ be after the
first release that happens entirely with Gradle.
- I hacked at merging to 8x and it seems to work, almost. There are a couple of
Java-11-only constructs, and what I'd guess are a few problems with my
environment. My question is whether it makes sense to try to merge to 8x or
will this be master only?
Yeah, it'll be an annoyance to switch back and forth between Gradle and Ant if
we don't backport to 8x (or even if we do I suppose and there are things that
the Ant build does that Gradle doesn't yet). Yeah, there are some bits of the
Ant build I'm used to but don't know how to do yet with Gradle. I still haven't
figured out how to do the equivalent of "cd solr; ant dist server; bin/solr
start -e techproducts" without getting a "class not found" error for instance.
I'll deal.
My motivation here is that, as it stands, I can't use the gradle build as part
of a regular workflow without switching to that branch and then worrying about
whether we've merged things appropriately. I'll be far more likely to work on
any Gradle issues if I use it regularly, and it'll be easier to use it
regularly if I don't have to mess with branches.
I'd like people's opinions re: pushing to master and 8x before proceeding
though. Frankly, as long as we can still do the ant build with these changes, I
don't see a significatn downside to pushing to master _and_ 8x, so that's my
straw-man proposal.
Thoughts?
> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -------------------------------------------------------------------------
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
> Issue Type: Improvement
> Components: Build
> Reporter: Mark Miller
> Assignee: Mark Miller
> Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a
> little further.
>
> When working with gradle in sub modules directly, I recommend
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version
> configuration and version consistency across modules:
> [https://github.com/palantir/gradle-consistent-versions]
>
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_8
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
