Simple remove-one method to workaround for circular dependency did not
work. This fix traverses the entire graph to detect all loops and then
breaks them up.
This commit introduces a mechanism that allows sbt to find the most
specific version of the compiler interface sources that exists using
Ivy.
For instance, when asked for a compiler interface for Scala 2.11.8-M2,
sbt will look for sources for:
- 2.11.8-M2 ;
- 2.11.8 ;
- 2.11 ;
- the default sources.
This commit also modifies the build definition by removing the
precompiled projects and configuring the compiler-interface project so
that it publishes its source artifacts in a Maven-friendly format.
This fixes the minigraph stitching logic by first sorting the graph
based on the level of inter-dependencies, and gradually resolving
conflict from the root-side that are not called by other libraries.
For each eviction, transitive evictions are propagated right away to
avoid double eviction observed in #2046
For the transitive eviction checking I needed to bring back the caller
information, which is notorious for its size. I am stuffing all
ModuleIDs into one ModuleID for the graph, and recovering them only
during the merging process.
Cached resolution saves dynamic mini graphs (including subproject
graphs) timestamped to the logical clock (State).
This enables graph caching across the subprojects.
On the other hand, it creates garbage that becomes stale almost
immediately. Prior to #2030 fix, this garbage would reach 1GB+.
This fix timestamps these graphs using calendar date, and cleans them
up after a day.
- On some of the builds graph.json is reaching 250MB+
- JSON parsing alone takes hours
- 97% of the content are caller info
- This change summarizes all callers into one (zero caller would have
correctness issues)
The pom generation code tries its best to map Ivy's configurations
to Maven scopes; however, sources and javadoc artifacts cannot be
properly mapped and they currently are emitted as dependencies in
the default scope (compile). That may lead to the source/doc jars
being erroneously processed like regular jars by automated tools.
Arguably, the source/docs jars should not be included in the pom
file as dependencies at all. This commit filters out the
dependencies that only appear in the sources and/or javadoc Ivy
configurations, thereby preventing them from appearing in the
final pom file.
* Remove launch/* code/tests, as these are in the sbt/launcher project.
* Create a new project which will resolve launcher module from sonatype-snapshots,
and repackage it for the currently building version of sbt.
* Remove ComponentManagerTest which was relying DIRECTLY on launcher classes.
We'll need to reconfigure this shortly to enable the tests again.
Remaining TODOs -
* Update resolvers so people can find the launcher.
* Add ComponentManagerTest back.
* Re-publish the sbt-launch.jar in the location it used to be published.
Re-fixes cached resolution's internal dependency issue by recursively
calling customResolve instead of including the transitive dependencies
from internal dependencies into your own graph.
Transformation of configuration still happens, but at the level of
resolved graph (UpdateReport), which is much less granular, and
hopefully less error-prone.
* Propogate the extra dependnecy attribute out of pom files into Aether
* Use the extra depednency attributes to ensure transitive plugins can be resolved.
* Add TODOs for further cleanup work.
* Here we wire Aether into the Ivy dependency chain
* Add hooks into Aether to use Ivy's http library (so credentials are configured the same)
* Create the actual Resolver which extracts metadata information from Aether
* Deprecate old Ivy-Maven integrations
* Create hooks in existing Resolver facilities to expose a flag to enable the new behavior.
* Create notes documenting the feature.
* Create a new resolver type `MavenCache` which denotes how to read/write local maven cache metadata
correctly. We use this type for publishM2 and mavenLocal.
* Update failing -SNAPSHOT related tests to use new Aether resolver
* Create specification for expected behavior from the new resolvers.
Known to fix#1322, #321, #647, #1616
#1634 is about a library getting wiped out of deps graph when it’s
included twice in ascending order of version.
I’d say that’s a logically inconsistent state, and we should just issue
warning instead of trying to fix it.
Adds project-level dependency exclusions:
excludeDependencies += "org.apache.logging.log4j"
excludeDependencies += "com.example" %% "foo"
In the first example, all artifacts from the organization
`"org.apache.logging.log4j"` are excluded from the managed dependency.
In the second example, artifacts with the organization `"com.example"`
and the name `"foo"` cross versioned to the current `scalaVersion` are
excluded.
- Fixes cached resolution being too verbose
- Adds new UpdateLogging named "Default"
- When global logLevel or logLevel in update is Debug, Default will
bump up to Full UpdateLogging.
- minigraph sha now contains extra attributes from artifacts
- artifacts are merged from different mini graphs (in some cases, this
should result to better resolution than stock ivy)
When stitching the minigraphs together only exclude the artifacts that
were evicted in *all* graphs, instead of some graphs.
Consider the following scenario:
- Y1 evicts slf4j-api 1.6.6 and picks 1.7.5
- Y2 evicts slf4j-api 1.7.5 and picks 1.6.6
At the root level, we need to use our own judgement and pick 1.7.5.
When Ivy translates pom to ivy.xml, it adds force=“true”.
So when both non-Maven dependencies and Maven dependencies are mixed, Maven dependencies always wins, which is the case for scala-library dependency added by the user.
This change brings over dependency overrides to artificial graph.
However, it seems forced might win, so I need to take overrides logic
in account during conflict resolution.
The issue comes into play where we cannot accurately get a publication date from Maven artifacts, leading to the current
mechanism having undefined behavior and causing other bugs to pop up in resolution.
When conflicts are found for a given module, a forced one
is selected before conflict manager kicks in.
The problem is that DependencyDescriptor seems to mark transitive
forced dependency as forced as well,
so the actual forced dependency are sometimes not prioritized.
To work around this, I’ve introduced a mixin called
SbtDefaultDependencyDescriptor, which carries around ModuleID to detect
direct dependencies.
Pierre DAL-PRA
Eugene Yokota
Josh Suereth
Martin Duhem
Dale Wijnand
Antonio Cunei
Andrew Johnson
Andreas Flierl
Max Worgan
Indrajit Raychaudhuri
Jean-Rémi Desjardins