[
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
