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.
This is an attempt to provide a decent error message in some cases. However, paths that include
the Java path separator character are just fundamentally problematic and aren't always going to
be cleanly detected.
* 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.
Non-standard git URIs are ones that do not start with 'git:' nor end
with '.git'. An example of non-standard git URI is
'ssh://server/home/user/repo'.
The mechanism for specifying a non-standard git URI is done by
prefixing the whole URI with 'git:' to signify that it should be
handled with the git resolver. For example, non-standard git URIs like
'git:ssh://server/user/repo' and 'git:https://server/user/repo' can
now be used.
Instead of cloning from a remote git repository for each branch,
revision or tag separately, the git resolver locally clones only once
the remote git repository and then creates further local clones from
this local copy of the remote repository.
First, optimization, of course, is execution speed, because cloning
local repository is much faster than remote repository. Furthermore,
because git uses hard-linking when a clone of local repository is
created, the second optimization is in space consumption.
For example, if we have one project that uses
https://github.com/harrah/xsbt.git#v0.11.1 and second project that
uses https://github.com/harrah/xsbt.git#v0.11.2, in previous git
resolver implementation it would require two separate clones of the
remote git repository at https://github.com/harrah/xsbt.git. But, the
new git resolver requires only one clone of the remote git repository
and two local clones which take no space because of hard-linking.
Jean-Rémi Desjardins
eugene yokota
Vasya Novikov
xuwei-k
Josh Suereth
Jacek Laskowski
Mark Harrah
Grzegorz Kossakowski
Eugene Vigdorchik
Michael Allman
Eugene Vigdorchik
Sanjin Sehic