[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16848981#comment-16848981
]
Mark Miller commented on SOLR-13452:
------------------------------------
{quote}I don't want to heat things up, but I've been wondering – perhaps
instead of disabling transitive dependencies we can just embrace them while
harnessing uncontrolled dependencies via final-jar dependency checksums (which
we already do)? I am well aware of the pitfalls that come with transitive
dependencies, yet I think those final JAR checksum checks effectively prevent
us from slurping new jar files upon upgrades. And dependencies of each module
become much easier to grasp and express then. Somehow I don't think explicit
flattening of all dependencies (non-transitive expression) is much more helpful
than a transitive dependency on the "root" library (possibly excluding truly
unnecessary junk), followed by sanity check preventing (or enforcing) a manual
eyeball if something changes.{quote}
I've thought about this as well. Not only we do have the license files and jar
checksums, but also dep locking. So deps won't just sneak in. I went back to
one of the primary reasons I have always had a distaste for Maven though -
people are lazy when it comes to deps. They add tons to their projects without
much care or thought. They suck up everything without much care or thought.
Next thing you know, you write a simple calculator app and the build downloads
5 gig the first time you do mvn build.
So yeah, I'm with you largely, but I do really like one thing about no
transitive deps - we default to figuring out the min we need instead of the
opposite, and that means we stay slimmer over time I think. Take the ZooKeeper
example. It brings in some random stuff we don't need or want, but when you
first add that dep are you going to be careful and choosy and try things out
with certain transitive excludes? Not likely, you just suck it all in and add
the licenses and checksums and new lock files. With transitive=false, you add
the zk dep, everything works and boom, you don't add the other unnecessary
stuff.
I'm open to whatever people prefer, there are also pain points to
transitive=false, but we don't have to decide now - we can change later on if
we would prefer.
> 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
