[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16849228#comment-16849228
]
Mark Miller commented on SOLR-13452:
------------------------------------
{quote}But I bet there's a million ways to do it
{quote}
My perspective is somewhat tainted by a what is now a long history of working
with lots of different modules in lots of different projects all inter
depending on each other. It creates some unique jar hell headaches. I've seen
and tried various ways around it and I think they did at Palantir as well (they
have some great gradle plugins).
In this type of world, where you need to harmonize dependencies across so many
inter-connected projects, I've found the best thing you can do is embrace the
build systems, use transitive dependencies with checks and tools on top, avoid
forcing versions wherever possible, use Platforms (Maven BOM's) and version
contrainsts plugin to ensure consistent versions across submodules. We can
publish our own BOM as well.
Then, versions are chosen and updates by figuring out what makes the most
sense. When that doesn't work, constraints can be added. Creating a system that
enforces single versions per project across submodules, and then allowing the
system to harmonize versions using BOM's and dependencies trees really keeps
things in the best state and gives the minimal effort required while allowing
you to enforce all the old constraints you enjoyed.
When the build handles versions and looks at BOM's and what not it can do cool
things like ensure all of our various jackson dependencies are at the highest
level that makes sense, but also that they are all the same version. We can
provide the same thing to our consumers, that however they add lucene and solr
dependencies to their build, a consistent version resolves for them.
Now when one dependency updates a sub dependency for a security vulnerability
or a performance fix, we also pick that up instead of our current super slow
update times. Dependency combos have fewer runtime surprises and versions get
updated more often when they should get updated.
We add constraints and exceptions and otherwise let the build do smart more
consistent work for us.
> 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: [email protected]
For additional commands, e-mail: [email protected]
