* sbt 0.12.3 introduced sbt/sbt@482f99 to fix#637 and #641.
* The underlying issue of #641 was an incorrect classifier, and it was
fixed in sbt/sbt@718fa9 for #683 and shipped as sbt 0.13.0.
* Testing the infrastructure to use our own instance of ivy
* Allow us to push bug-fixes/performance directly into ivy
on our own pace, as we submit patches back to ivy master
Workaround for #1156.
* Creates a new FileRepository that will stil allow local files
to be transfered if overwrite is true (non-snapshot module),
but will issue a warning about deprecated behavior.
* Ensure warning is long enough to annoy people into asking
what it's about.
We attempt to convert these constructs to maven:
* 1.+
* ]1,2]
* [2,3[
* 1+ - Albeit this one is a heuristic for accuracy.
This should help ivy users which prefer the nicer 1.2.+ syntax.
Also adds tests/improves exisitng tests.
* Create hackery to inspect registered credentials in the IvyCredentialStore.
* Create a new authenticator which inserts itself *after* the ivy authenticator.
- Will issue an error message detailing host/realm required if credentials are
not found.
- Also lists out configured Realms with a 'is misspelled' message.
- Ignores proxy-related authentication errors, for now.
* Attempt to convert dependencies that end in `+` into maven-style version range
* if a failure occurs, just use the original version (could be bad...).
This entailed modifying ResolutionCache and the CustomPomParser
to reflect changes to the ResolutionCacheManager interface and
DefaultExtendsDescriptor class between Ivy 2.3.0-rc1 and
2.3.0-rc2. Specifically,
1. ResolutionCacheManager now includes two additional methods
that needed implementations in ResolutionCache:
getResolvedModuleDescriptor(mrid: ModuleRevisionId) and
saveResolvedModuleDescriptor(md: ModuleDescriptor). I adapted
the implementations for these (which are expressed primarily in
terms of other interface methods) from Ivy 2.3.0's
DefaultResolutionCacheManager.
2. Instead of taking a ModuleRevisionIdentifier and a resolved
ModuleRevisionIdentifier as its first two arguments, the
DefaultExtendsDescriptor constructor now takes a
ModuleDescriptor. This was a trivial change.
Note that ResolutionCache.getResolvedModuleDescriptor does not
appear to be used by Ivy as sbt uses Ivy and there is thus no
test coverage for its implementation. Also note that the
DefaultResolutionCacheManager object created in
Update.configureResolutionCache now requires a reference to an
IvySettings object; DRCM expects this to be non-null.
* when mvn does a local 'install', it doesn't update the pom.xml last modified time if the pom.xml content hasn't changed
* an ivy.xml includes publicationDate, so an ivy.xml will always be touched even if the other content hasn't changed
* when Ivy checks if a snapshot is uptodate
+ it sees a SNAPSHOT, so it knows the module metadata and artifacts might change
+ it then checks the lastModified time of the metadata
+ if unchanged, it uses the cached information
+ if useOrigin is effectively false (either it is explicitly false or a resource is remote/isLocal=false),
this means that a new artifact won't be retrieved
* the Ivy IBiblioResolver
+ must be used for Maven repositories for proper behavior (no FileResolver, for example)
+ only returns URLResources, even for file: URLs
+ a FileResource is needed in combination with useOrigin to avoid copying artifacts from .m2/repository/
This commit fixes the above by setting a custom URLRepository on a constructed IBiblioResolver.
This URLRepository returns FileResources for file: URLs and standard URLResources for others.
The returned FileResource has isLocal=true and sbt sets useOrigin=true by default, so the artifacts
are used from the origin.
If it turns out a similar situation happens when mvn publishes to remote repositories, it is likely the fix for
that would be to figure out how to disable the lastModified check on the metadata and always download the metadata.
This would be slower, however.
The <type> element was generated for any explicit Artifact with a type other than "jar".
withSources() and withJavadoc() create explicit Artifacts of this kind, but shouldn't
have <type> elements. They are primarily artifacts with classifiers- the type is an
Ivy aspect. So, when writing to a pom, don't use write a type for known classifiers.
This commit adds convenience methods to PatternsBasedRepository that
produce a copy of the repository with metadata optional or with
consistency checking disabled.
Specify an Ivy resolver with ", descriptorOptional" to make Ivy
descriptor files optional for that repository or with
", skipConsistencyCheck" to disable Ivy consistency checks for
that repository.
* Consolidate project ID validation and normalization into Project methods
* Provide an earlier and more detailed error message when the directory
name can't be used for the project ID
Ivy still seems to remember the resolver that found the metadata
and records that as the resolver to use for the artifact. Previous
fixes have attempted to ignore or blank this resolver. The issue
this fix addresses comes from inter-project not being ignored/blanked.
inter-project can't provide artifacts because it is only for projects
in the current build under development and not for modules in a repository.
The symptom is that compiling a build definition fails because the
sbt jars aren't on the classpath, but it is ultimately due to the
inter-project resolver incorrectly being used to resolve artifacts.
For the global plugins project, the default ID is "global-plugins".
For a normal project, the default ID is the name of the build directory.
The ID of a build definition for one of the above appends -build.
Ivy hardcodes the resolution report name in the stylesheet that renders the
HTML from the XML report. This means that the links to other configurations
are broken when using a custom name.
sbtApiVersion and scalaApiVersion each calculates the API
version of release builds as well as milestones and RCs.
scalaBinaryVersion and sbtBinaryVersion are now aware of
scalaApiVersion and sbtApiVersion respectively.
For example, sbtBinaryVersion for "0.13.0-SNAPSHOT" now evaluates to
"0.13.0-SNAPSHOT" instead of "0.13".
Set autoAPIMappings := true to enable.
Then, set apiURL to the base URL of the API documentation for a project.
This will get stored in an extra attribute in the ivy.xml or as a property
a pom.xml.
When using managed dependencies that have set their apiURL, the -doc-external-doc
setting for scaladoc will be automatically configured. Note that this option
will only be available in Scala 2.10.1 and so enabling autoAPIMappings for
earlier versions will result in an error from scaladoc.
For unmanaged dependencies or dependencies without an automatic apiURL, add the
(File,URL) mapping to apiMappings. The File is the classpath entry and the URL
is the location of the API documentation.
The verbose-level logging is what usually contains relevant information for the user.
Persisting the debug logging slows down update noticeably and clutters the more useful
debug logging output from verbose.
1. Scala jars won't be copied to the boot directory, except for those needed to run sbt.
2. Scala SNAPSHOTs behave like normal SNAPSHOTs. In particular, running `update` will properly re-resolve the dynamic revision.
3. Scala jars are resolved using the same repositories and configuration as other dependencies.
4. Classloaders (currently, Scala classloaders) are cached by the timestamps of entries instead of Scala class loaders being cached by version.
TODO: Support external dependency configuration
Replaces the standard Ivy resolution cache:
1. Separate the cached resolved Ivy files from resolution reports,
making resolution reports easier to find (target/resolution-cache/reports/)
2. Cache location includes extra attributes so that cross builds of a plugin
do not overwrite each other.
eugene yokota
Josh Suereth
Dan Sanduleac
William Benton
Mark Harrah
James Roper
Brendan W. McAdams
Paolo G. Giarrusso
Grzegorz Kossakowski
Eric Bowman
Thomas Lockney
Michael Allman