UnresolvedWarning is moved back to IvyActions.scala where it belongs.
The mapping between ModuleID and SourcePosition is passed in as UnresolvedWarningConfiguration.
This is calculated once in Defaults using State and is cached to filesystem.
Unresolved dependency warning is moved to UnresolvedDependencyWarning class including
the fail path that was added in #1467.
To display the source position, I need to access the State, so I had to move the
error processing out of IvyActions and add UnresolvedDependencyWarning, which is
aware of State.
This implements all stories from https://github.com/sbt/sbt/wiki/User-Stories%3A-Conflict-Warning.
When scalaVersion is no longer effective an eviction warning will display.
Scala version was updated by one of library dependencies:
* org.scala-lang:scala-library:2.10.2 -> 2.10.3
When there're suspected incompatibility in directly depended Java libraries,
eviction warnings will display.
There may be incompatibilities among your library dependencies.
Here are some of the libraries that were evicted:
* commons-io:commons-io:1.4 -> 2.4
When there's suspected incompatiblity in directly depended Scala libraries,
eviction warnings will display.
There may be incompatibilities among your library dependencies.
Here are some of the libraries that were evicted:
* com.typesafe.akka:akka-actor_2.10:2.1.4 -> 2.3.4
This also adds 'evicted' task, which displays more detailed eviction warnings.
VersionNumber is a pseudo-case class that represents any form of
version number. The unapply extractor can parse String into
three sequences that makes up VersionNumber.
VersionNumberCompatibility trait uses two VersionNumber instances
to evaluate binary compatibility between them.
Two implementations SemVer and SecondSegment are provided.
Currently sbt's update task generates UpdateReport from
Ivy's resolution report.
For each configuration there's ConfigurationReport, which contains
just enough information on the resolved module/revision/artifact.
Speaking of module, in Ivy module means organization and name,
and organization, name, and version is called module revision.
In sbt, module revision is called Module.
This is relevant because to talk about evictions, we need
a terminology for organization and name combo.
In any case ConfigurationReport is expanded to have `details`
field, which contains Seq[ModuleDetailReport], which represents
organization and name combo plus all the modules
just like Ivy's resolution report XML.
Furthermore, ModuleReport is expanded to include licenses,
eviction, callers, etc.
This adds a new setting key called updateOptions, which can enable
consolidated resolution for update task.
The consolidated resolution automatically generates an artificial
module descriptor based on the SHA-1 of all external dependencies.
This consolidates the Ivy resolution of identical Ivy dependency
graph across multiple subprojects.
This is how it's enabled:
updateOptions := updateOptions.value.withConsolidatedResolution(true)
The CustomPomParser has a hard-coded list of 'blessed' Maven POM packaging types
that are actually packaged as jar files, but Ivy incorrectly maps the file extension.
This patch allows artifacts published with the 'scala-jar' packaging to be properly
resolved and used in an SBT project.
Add scala 2.11 test/build verification.
* Add 2.11 build configuratoin to travis ci
* Create command which runs `safe` unit tests
* Create command to test the scala 2.11 build
* Update scalacheck to 1.11.4
* Update specs2 to 2.3.11
* Fix various 2.11/deprecation removals
and other changes.
Fix eval test failure in scala 2.11 with XML not existing.
Ivy transactional publishing will abort if no artifacts
are published, either because the temporary directory is
not being created, or because Ivy will detect an anomalous
condition.
Therefore, skip publishing altogether if there is
nothing to publish to begin with.
* 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.
Roberto Tyley
Eugene Yokota
Evgeny Goldin
Josh Suereth
Jacek Laskowski
David Pratt
Antonio Cunei
Dan Sanduleac
William Benton
Mark Harrah
James Roper
Brendan W. McAdams
Paolo G. Giarrusso
Grzegorz Kossakowski