* Attempt to convert dependencies that end in `+` into maven-style version range
* if a failure occurs, just use the original version (could be bad...).
The previous example of how to fork group of tests in different
JVMs was incomplete and not fully working.
a) The "testGrouping in Test" is needed, otherwise the grouping is
not known to which phase to apply
b) Added a more complete Project definition to explain what the curly
brackets section refers to and where the settings need to be included
The new complete example works out of the box :-)
In 2.11, the implicit version is named `$conforms` so as to avoid
accidental shadowing by user code, which renders methods using
views and subtype bounds inexplicable unusable.
But, SBT intentionally needs to hide it to make the implicits
in this file line up.
This commit opts-in the the required identifiers from Predef,
rather than opting out of conforms. This makes the same code
source compatible with 2.10 and 2.11.
* 'plugins' displays the list of plugins available for each build along with the project IDs each is enabled on
* 'plugin <name>' displays information about a specific plugin in the context of the current project
- if the plugin is activated on the current project and if so, information about the keys/configurations it provides
- how the plugin could be activated if possible
* tries to detect when it is run on an aggregating project and adjusts accordingly
- indicates if an aggregated project has the plugin activated
- indicates to change to the specific project to get the right context
This is a rough implementation and needs lots of polishing and deduplicating.
The help for the commands needs to be added/expanded.
* Can provide suggestions for how to define a plugin given a context (a loaded Project in practice).
* When a user requests an undefined key at the command line, can indicate whether any (deactivated) plugins provide the key.
TODO:
* Hook up to the key parser
* Implement 'help <plugin>'
* Determine how to best provide the context (the current project is often an aggregating root, which is not typically a useful context)
The c7f435026f introduced a new parameter
to the constructor of `CompileSetup` but it turns out that this class
is being used in zinc. Introduce an overloaded variant of that constructor
that preserves backwards compatibility.
The CompileSetup class is being used to detect changes to arguments of
incremental compiler that affect result of compilation and trigger
recompilation. Examples of such arguments include, the target (output)
directory, Scala compiler options, Scala compiler version, etc.
By adding `nameHashing` to CompileSetup we have a chance to handle change
to that flag smoothly by throwing away old Analysis object and starting
with an empty one. That's implemented in AggressiveComile by extending
the logic that was responsible for detection of changes to CompileSetup
values. Thanks to this change we fix#1081.
Analysis formats has been updated to support persisting of newly added
value in CompileSetup. We used to not store the value of `nameHashing`
flag in persisted Analysis file and infer it from contents of relations
but that leads to issue #1071 when empty relations are involved. Given
the fact that CompileSetup stores `nameHashing` value now, we can just
use it when reading relations and fix#1071. This requires reading/writing
compile setup before reading relations. I decided to make that change even
if there's a comment saying that reading/writing relations first was done
intentionally.
This commit makes the code source compatible across Scala 2.10.3
and https://github.com/scala/scala/pull/3452, which is proposed
for inclusion in Scala 2.11.0-RC1.
We only strictly need the incremental compiler to build on Scala
2.11, as that is integrated into the IDE. But we gain valuable
insight into compiler regressions by building *all* of SBT with
2.11.
We only got there recently (the 0.13 branch of SBT now fully cross
compiles with 2.10.3 and 2.11.0-SNAPSHOT), and this aims to keep
things that way.
Once 2.10 support is dropped, SBT macros will be able to exploit
the new reflection APIs in 2.11 to avoid the need for casting
to compiler internals, which aren't governed by binary compatibility.
This has been prototyped by @xeno-by: https://github.com/sbt/sbt/pull/1121
The ff0fd6eec6 introduced some exclusions
that were necessary for getting sbt to resolve dependencies properly
against Scala 2.11.0-M7.
Scala 2.11.0-M8 fixed its dependency structure so we can get rid of those
exclusions now.
Since the fix for SI-2066, Scala 2.11 calls logicallyEnclosingMember on the
`x` in the expansion of the task macro:
InitializeInstance.app[[T0[x]](T0[java.io.File], T0[java.io.File]), Seq[java.io.File]]
This exposed the fact that SBT has created `T0` with `NoSymbol` as
the owner. This led to the a SOE.
I will also change the compiler to be more tolerant of this, but we
can observe good discipline in the macro and pick a sensible owner.
We now have `global.Range`, so our wildcard import of `global._`
shadows `scala.Range`.
This commit fully qualifies that type so as to be compatible with
Scala 2.10 and 2.11.
- remove AutoPlugin.provides
* name comes from module name
* AutoPlugin is Nature-like via Basic
- Project.addNatures only accepts varags of Nature values
* enforces that a user cannot explicitly enable an AutoPlugin
* drops need for && and - combinators
- Project.excludeNatures accepts varags of AutoPlugin values
* enforces that only AutoPlugins can be excluded
* drops need for && and - combinators
Josh Suereth
Luca Milanesio
Antoine Gourlay
Jason Zaugg
Charles Feduke
Mark Harrah
Eugene Platonov
Grzegorz Kossakowski
Roch Delsalle
Dan Sanduleac
Suzanne Hamilton
Dan Sanduleac