[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16849137#comment-16849137 ]
Mark Miller commented on SOLR-13452: ------------------------------------ bq. Both approaches have their pros and cons. No worries. Right, any project could go either way, so it has more to do with what the community will allow or go with and what I can manage to get bogged down with her. Technical issues aside, it's not easy to make a big change like this with so many developers on the project. One thing that could def put weight towards using transitive with excludes is if we don't get full version resolution without transitive. For example, if zookeeper says it wants commons-io 2.4 and we have transitive false, when we pick our commons-io version, does it still take that into account? [~dweiss], [~thetaphi], do you know? If we did't get proper version resolution, I'd really argue we should change how we do things sooner rather than later. > 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 > Security Level: Public(Default Security Level. Issues are Public) > Components: Build > Reporter: Mark Miller > Priority: Major > > 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_2 -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org