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.
* Attempt to set publication date to last modified time, if the stars align
* Issue warning about undefined resolution behavior otherwise
* Add scripted test which exercises the NPE issue in resolving -SNAPSHOTs.
* Commit scalariform style edit in Act.scala
* After parsing and transforming the pom, check for pub date.
* If we don't have a pub date, try to grab lastModified from the URL
* If we can't do anything, issue a warning about the problem artifact.
It turns out there was a very subtle, and evil, issue sitting the Ivy/maven configuration, and it
related to dependency mapping. A mapping of `foo->bar(*)` means that the local configuration
`foo` depends on the remote configuration `bar`, if it exists, or *ALL CONFIGURATIONS* if `bar`
does not exist. Since the default Ivy configuration mapping was using the random `master`
configuration, which AFAICT is NEVER specified, just an assumed default, this would cause leaks
between maven + ivy projects.
i.e. if a maven POM depends on a module denoted by an ivy.xml file, then you'd wind up accidentally
bleeding ALL the ivy module's configurations into the maven module's configurations.
This fix works around the issue, by assuming that if there is no `master` configuration, than the
maven default of `compile` is intended. As sbt forces generated `ivy.xml` files to abide by
maven conventions, this works in all of our test cases. The only scenario where it wouldn't work
is those who have custom ivy.xml files *and* have pom.xml files which rely on those custom ivy.xml files,
a very unlikely situation where the workaround is: "define a master configuration".
Includes a test demonstrating the issue.
Fixes#1565
* Create two chains if we have inter-project resolver
- One which ensures inter-project deps are always taken
- One which will look in all "other" repositories for
dependencies and will use the "most up-to-date" -SNAPSHOT
strategy.
* No additional tests, as this would simple break every
multi-project test if it were wrong.
I assumed 1.1+ should be treated as 1.+, but it seems like Ivy treats
it more as “any version that starts with 1.1” including 1.10.
Josh’s original implementation approximates this by making ranges for
multiple digits, 1.1~1.2, 1.10~1.20, etc.
scala-library is currently treated as just one of the library modules.
This means that it’s at the mercy of eviction if some other library
uses newer version of scala-library.
This commit displays a instruction on how to force scalaVersion if
warnScalaVersionEviction flag is true on EvictionWarningOptions.
Scala instance is added to the Ivy graph via autoLibraryDependency.
For metabuilds, scala-library is scoped under “provided” configuration,
which does not seem to evict modules on “compiled” configuration.
This commit turns overrideScalaVersion flag to true for the metabuilds,
so override rules are added for the following modules:
- scala-library
- scala-compiler
- scala-reflect
Ivy and pom uses slightly different notation for version range and
dynamic revision.
This change fixes the dynamic revisions involving “+”.
First, when a revision like “1.1+” is found, it will now be treated as
“1.+”.
Next, when it finds a revision like “1+” is found, it will be treated
as “+”.
The conversion of “+” is hardcoded to be “[0,)”.
Ivy gives an array that contains null for caller configurations.
sbinary barfs when it sees null. Curiously two of the sbt plugins that
hit this bug happens to be from Typesafe:
addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.3.2")
addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "0.7.3")
Max Worgan
Eugene Yokota
Dale Wijnand
Indrajit Raychaudhuri
Josh Suereth
Jean-Rémi Desjardins
Tejas Mandke
Brian Topping
Havoc Pennington