mirror of https://github.com/sbt/sbt.git
Fix typos in notes
This commit is contained in:
Travis Brown
parent
bd4e57dc66
commit
5720894c5a
|
|
@ -97,7 +97,7 @@
|
|||
- Allows keys defined inside `build.sbt` to be used from sbt shell. [#1059][1059]/[#1456][1456]
|
||||
- Updates internal Ivy instance to cache the results of dependency exclusion rules. [#1476][1476] by [@eed3si9n][@eed3si9n]
|
||||
- Adds `Resolver.jcenterRepo` and `Resolver.bintrayRepo(owner, repo)` to add Bintray easier. [#1405][1405] by [@evgeny-goldin][@evgeny-goldin]
|
||||
- AutoPlugins with no requirements enabled by allRequirements can now be disable dby the user. [#1516][1516] by [@jsuereth][@jsuereth]
|
||||
- AutoPlugins with no requirements enabled by allRequirements can now be disabled by the user. [#1516][1516] by [@jsuereth][@jsuereth]
|
||||
|
||||
### Bug fixes
|
||||
|
||||
|
|
@ -105,9 +105,9 @@
|
|||
- Fixes auto plugins declared without package object. [#1423][1423] by [@lpiepiora][@lpiepiora]
|
||||
- Fixes `plugin` command. [#1416][1416]/[#1426][1426] by [@lpiepiora][@lpiepiora]
|
||||
- Adds `scala-jar` to the list of jar artifacts recognized by CustomPomParser. [#1400][1400] by [@dpratt][@dpratt]
|
||||
- Fixes cross versioning to recognize version number with mutiple -tags. [#1433][1433] by [@henrikengstrom][@henrikengstrom]
|
||||
- Fixes cross versioning to recognize version number with multiple -tags. [#1433][1433] by [@henrikengstrom][@henrikengstrom]
|
||||
- Works around "Not a simple type" breaking `-Xfatal-warnings`. [#1477][1477] by [@puffnfresh][@puffnfresh]
|
||||
- Fixes sLog usage in tandem with the `set` comamnd [#1486][1486] [@jsuereth][@jsuereth]
|
||||
- Fixes sLog usage in tandem with the `set` command [#1486][1486] [@jsuereth][@jsuereth]
|
||||
- Test suites with whitespace will have prettier filenames [#1487][1487] [@jsuereth][@jsuereth]
|
||||
- sbt no longer crashes when run in root directory [#1488][1488] by [@jsuereth][@jsuereth]
|
||||
- set no longer removes any `++` scala version setting. [#856][856]/[#1489][1489] by [@jsuereth][@jsuereth]
|
||||
|
|
@ -157,10 +157,10 @@ This is an approximation, but it should help you figure out where the problemati
|
|||
|
||||
sbt 0.13.6 displays eviction warnings when it resolves your project's managed dependencies via `update` task.
|
||||
Currently the eviction warnings are categorized into three layers: `scalaVersion` eviction, direct evictions, and transitive evictions.
|
||||
By default eviction warning on `update` task will display only `scalaVersion` evictin and direct evictions.
|
||||
By default eviction warning on `update` task will display only `scalaVersion` eviction and direct evictions.
|
||||
|
||||
`scalaVersion` eviction warns you when `scalaVersion` is no longer effecitive. This happens when one of your dependency depends on a newer release of scala-library than your `scalaVersion`.
|
||||
Direct evctions are evictions related to your direct dependencies. Warnings are displayed only when API incompatibility is suspected. For Java libraries, Semantic Versioning is used for guessing, and for Scala libraries Second Segment versioning (second segment bump makes API incompatible) is used.
|
||||
`scalaVersion` eviction warns you when `scalaVersion` is no longer effective. This happens when one of your dependencies depends on a newer release of scala-library than your `scalaVersion`.
|
||||
Direct evictions are evictions related to your direct dependencies. Warnings are displayed only when API incompatibility is suspected. For Java libraries, Semantic Versioning is used for guessing, and for Scala libraries Second Segment versioning (second segment bump makes API incompatible) is used.
|
||||
|
||||
To display all eviction warnings with caller information, run `evicted` task.
|
||||
|
||||
|
|
@ -175,7 +175,7 @@ To display all eviction warnings with caller information, run `evicted` task.
|
|||
|
||||
sbt 0.13.6 adds a new setting key called `updateOptions` for customizing the details of managed dependency resolution with `update` task. One of its flags is called `lastestSnapshots`, which controls the behavior of the chained resolver. Up until 0.13.6, sbt was picking the first `-SNAPSHOT` revision it found along the chain. When `latestSnapshots` is enabled (default: `true`), it will look into all resolvers on the chain, and compare them using the publish date.
|
||||
|
||||
The tradeoff is probably a longer resolution time if you have many remote repositories on the build or you live away from the severs. So here's how to disable it:
|
||||
The tradeoff is probably a longer resolution time if you have many remote repositories on the build or you live away from the servers. So here's how to disable it:
|
||||
|
||||
updateOptions := updateOptions.value.withLatestSnapshots(false)
|
||||
|
||||
|
|
@ -187,4 +187,4 @@ The tradeoff is probably a longer resolution time if you have many remote reposi
|
|||
|
||||
updateOptions := updateOptions.value.withConsolidatedResolution(true)
|
||||
|
||||
This feature is specifically targeted to address [Ivy resolution is beging slow for multi-module projects #413][413]. Consolidated resolution aims to fix this issue by artificially constructing an Ivy dependency graph for the unique managed dependencies. If two subprojects introduce identical external dependencies, both subprojects should consolidate to the same graph, and therefore resolve immediately for the second `update`. [#1454][1454] by [@eed3si9n][@eed3si9n]
|
||||
This feature is specifically targeted to address [Ivy resolution is unreasonably slow for multi-module projects #413][413]. Consolidated resolution aims to fix this issue by artificially constructing an Ivy dependency graph for the unique managed dependencies. If two subprojects introduce identical external dependencies, both subprojects should consolidate to the same graph, and therefore resolve immediately for the second `update`. [#1454][1454] by [@eed3si9n][@eed3si9n]
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@
|
|||
### Fixes with compatibility implications
|
||||
|
||||
- Maven artifact dependencies will limit their transitive dependencies to `Compile` rather than *every configuration* if no `master` configuration is found. [#1586][1586] by [@jsuereth][@jsuereth]
|
||||
- The new natural whitspace handling parser is unable to cope with certain classes of Scala syntax. In particular, top-level pattern matches, or multi-value defintions are no longer supported.
|
||||
- The new natural whitespace handling parser is unable to cope with certain classes of Scala syntax. In particular, top-level pattern matches, or multi-value definitions are no longer supported.
|
||||
|
||||
Here are examples:
|
||||
|
||||
|
|
@ -111,7 +111,7 @@ sbt 0.13.7 adds a new **experimental** update option called *cached resolution*,
|
|||
|
||||
updateOptions := updateOptions.value.withCachedResolution(true)
|
||||
|
||||
Unlike consolidated resolution, which only consolidated subprojects with identical dependency graph, cached resolution create an artificial graph for each direct dependency (minigraph) for all subprojects, resolves them independently, saves them into json file, and stiches the minigraphs together.
|
||||
Unlike consolidated resolution, which only consolidated subprojects with identical dependency graph, cached resolution create an artificial graph for each direct dependency (minigraph) for all subprojects, resolves them independently, saves them into json file, and stitches the minigraphs together.
|
||||
|
||||
Once the minigraphs are resolved and saved as files, dependency resolution turns into a matter of loading json file from the second run onwards, which should complete in a matter of seconds even for large projects. Also, because the files are saved under a global `~/.sbt/0.13/dependency` (or what's specified by `sbt.dependency.base` flag), the resolution result is shared across all builds.
|
||||
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ sbt 0.13.7 implemented natural whitespace handling by switching `build.sbt` pars
|
|||
val a = <x/><y/>
|
||||
val b = 0
|
||||
|
||||
At the time, we thought adding parentheses around XML nodes could work around this behavior. However, the workaround has caused [more issues][1738], and since then we have realized that this is a compiler issue [SI-9027][SI-9027], so we have decided to roll back our workaround. In the meantime, if you have consecutive XML elements in your build.sbt, encose them in `<xml:group>` tag, or parentheses.
|
||||
At the time, we thought adding parentheses around XML nodes could work around this behavior. However, the workaround has caused [more issues][1738], and since then we have realized that this is a compiler issue [SI-9027][SI-9027], so we have decided to roll back our workaround. In the meantime, if you have consecutive XML elements in your build.sbt, enclose them in `<xml:group>` tag, or parentheses.
|
||||
|
||||
val a = <xml:group><x/><y/></xml:group>
|
||||
val b = 0
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@
|
|||
|
||||
### Maven resolver plugin
|
||||
|
||||
sbt 0.13.8 adds an extention point in the dependency resolution to customize Maven resolvers.
|
||||
sbt 0.13.8 adds an extension point in the dependency resolution to customize Maven resolvers.
|
||||
This allows us to write sbt-maven-resolver auto plugin, which internally uses Eclipse Aether
|
||||
to resolve Maven dependencies instead of Apache Ivy.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue