* Puppies may rest easy from the removal of Option.get calls.
* better names for config values
* Added a helper method to avoid any possible code duplication, besides repeated def, val, match and for keywords.
Looking for ways to remove this duplciation ASAP.
* Moved from pattern match to ._1, my most hated member.
Problems:
1. Without a message, users don't find 'last'
2. Showing a message for every error clutters output.
This tries to address these issues by:
1. Only showing the message when other feedback has not been provided and
'last' would not usually be helpful. This will require ongoing tweaking.
For now, all commands except 'compile' display the message. 'update' could
omit the message as well, but perhaps knowing about 'last' might be
useful there.
2. Including the exact command to show the output:
last test:compile
and not just
last <task>
3. Highlighting the command in blue for visibility as an experiment.
Review by @ijuma and @retronym, please.
Changed the order of parameters in getScala method.
Changed the key name to scalaOrganization (scala-organization).
Augmented description of the key.
Minor fixes.
Adding scalaOrg key that specifies organization (artifactId) of scala used in the project. The change does not affect version checks for dependecies and LauncherConfiguration.
Modified scalaProvider cache in Launcher to use (scalaOrg, version) as a key.
Downloaded jars are stored in the folder scala-.../lig-<scalaOrg> if scalaOrg is not default.
scala-org is an advanced setting so it can not be used in build.sbt.
Currently, only immediate parents classes are picked up for java classes.
This could be problematic, for example, in detecting Fingerprint for test frameworks.
So far, Scala types are not affected –– all the ancestors are available for them.
Warn when publish resolver and dependency resolvers have same name but different access mechanism.
Multiple resolvers having same name as well as same access mechanism (i.e., equality matching) isn't
usually a problem. A common scenario for this would be Maven based resolvers with exact (http based)
same access mechanism. Also see #367, #363
Simply, add `DefaultOptions.addResolvers` in project config
or `DefaultOptions.addPluginResolvers` in plugin config to have known
resolvers added by default (snapshot mode sensitive)
- deprecate scala-tools resolvers
- rename `typesafeResolver` to `typesafeReleases` for consistency
- add reference for other wel known resolvers, viz., oss.sonatype.org and scalasbt.artifactoryonline.com
- rearrange locations for helper methods
So far we had ability to configure compile task specific settings on
`Compile` Configuration scope only. We can now add `compile` task scope
as well.
Usecase: one can now specify:
```
// applies for all tasks on Compile axis
scalacOptions in Compile += "-deprecation"
// applies for compile tasks on Compile axis
scalacOptions in (Compile, compile) += "-Xcheckinit" // effectively, "-deprecation -Xcheckinit"
```
The old convention of keeping credentials in ~/.ivy2 isn't recommended anymore,
they can instead go in (customizable) global base location.
The global base defaults to `~/.sbt`, hence credentials go in `~/.sbt/.credentials`
(c.f. `Keys.globalBaseDirectory` and system property `sbt.global.base`)
Sonatype OSS repo (where many libraries are expected to migrate) requires
populating SCM info in additional to what is already provisioned for
populating in SBT.
We now support populating the basic SCM info as thus:
```
// Usual <scm><url/><connection/></scm>
scmInfo := Some(ScmInfo(url("https://github.com/foo/project"), "scmhttps://github.com/foo/project.git"))
// Also add <developerConnection/>
scmInfo := Some(ScmInfo(url("https://github.com/foo/project"), "scmhttps://github.com/foo/project.git", Some("dev_connection")))
```
For anything more esoteric than the basic info, there is always `pomPostProcess` :)
Old implementation of the local resolver did not copy directory if it
was writable. This optimization can lead to some potential problems if
the directory is writable, but its subdirectories aren't.
New implementation of the local resolver does not have this
optimization and it always copies the directory into staging area.
All subversion URIs have to be prefixed with 'svn:' to separate them
from URIs for other resolvers. For example, 'svn:https://server/repo'
can now be used.
All mercurial URIs have to be prefixed with 'hg:' to separate them
from URIs for other resolvers. For example,
'hg:https://server/user/repo' can now be used.
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.