* 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.
There is sometimes the need to use a test version of Scala that is
intended to be binary compatible with a standard release version.
At this time, due to the particular logic implemented within sbt,
a non-numeric suffix will never have the same binaryScalaVersion
of a release version ending in ".0", like for instance "2.11.0".
This commit allows developers to use as suffix any string that
begins with "-bin", for instance "2.11.0-bin-compat-test-1".
Such a suffix will have a binaryScalaVersion of "2.11", being
therefore considered binary compatible with release versions.
Eugene Yokota
Josh Suereth
Tejas Mandke
Brian Topping
Jean-Rémi Desjardins
Grzegorz Kossakowski
Antonio Cunei