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.
The issue is that when you manually set a ScalaInstance, i.e. not one from Ivy, the
classpath which is returned for any given configuration ONLY uses Ivy. This means that
the legitimate Scala JAR files that need to be on the classpath are missing from the list.
For some reason, the way we instantiate tests uses an unfiltered classloader against the
ScalaInstance, *BUT* the thread-context-classloader DOES use a filtered instance by
classpath. This add the hook into the TestFramework runner creation so that
the classpath accurately reflects the jars needed.
cc @rkuhn
Fixes#1568.
This is the fallout of attempting not to leak config-file classes. Since
we DO NOT have valid incremental compiler for config-classes, we've instituted
workaround to ensure that regular incremental compilation *AND* our own
sbt loader do not hose each other. A full solution will eventually be
to find a way for .sbt files to participate in regular compilation of a
project.
For now, we fix the tracking of generated.class files throughout an sbt
"loadProjects" call, and then clean any .class files that were not
generated for a full reload. This commit just fixes
a minor tracking 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.
Those tests use the random Analysis generator that is used in the
unit tests for the subproject `incremental-compiler`.
Random Analyses are serialized and then constructed back from this
representation.
Unit tests in incremental-compiler subproject use a generator to
create random Analysis objects. This generator was unfortunately
not working properly and generated only empty Analyses (it failed
to generate any non-empty Analysis because of a bug in the `unique`
generator).
Travis CI stopped allowing long file names on its file system. We need
to explicitly set lower limit on file name length using
`-Xmax-classfile-name` Scala compiler option. We set the limit to 240
characters.
Fixes#1553
Name hashing is now turned on by default, so I’m changing the value for
inc.Relations.empty, so inc.Analysis.empty functions as expected when
it’s joined with name hashing analyses.
I assumed 1.1+ should be treated as 1.+, but it seems like Ivy treats
it more as “any version that starts with 1.1” including 1.10.
Josh’s original implementation approximates this by making ranges for
multiple digits, 1.1~1.2, 1.10~1.20, etc.
Josh Suereth
eugene yokota
Daniel Peebles
Antonio Cunei
Martin Duhem
James Ward
Grzegorz Kossakowski
Josh Kalderimis