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.
Josh Suereth
Eugene Yokota
Antonio Cunei
Dan Sanduleac
William Benton
Mark Harrah
James Roper