-
Notifications
You must be signed in to change notification settings - Fork 14
Ready for v0.9.7-RC1 #192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Ready for v0.9.7-RC1 #192
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The Bintray plugin is not available on 1.0, but it will be (eventually) essential to publish the plugin. And, the bintray plugin .sbt file should apply to both 2.10 and 2.11 (2.12).
This should fix lightbend-labs#158, and provide support for Bintray-enabled projects without workarounds.
…ollisions The artifact names are obtained from "moduleName", which may be different from the project name. Fixes lightbend-labs#188
If we are on sbt 0.13, then a regular bintray plugin dependency will be included (but only on Scala 2.10) by the file: project/plugins-2.10.sbt. When this file is seen while we use 1.0.0-M4, libraryDependencies is not modified and no Bintray plugin is inserted. If we are on sbt 1.0.0-M4, an additional project will be creaated by the file: project/project/src/main/scala-2.11/bintrayIf211.scala However, when we are on 0.13, this file is used instead: project/project/src/main/scala-2.10/bintrayIf211.scala The definition consists in a Seq of projects (empty for 2.10), which is then added by a dependsOn clause in project/build.sbt
The dbuild plugins used to bring onto the classpath all sorts of sbt libraries; the result was that multiple versions of the sbt libraries would appear on the classpath, leading to bizarre behaviour. The plugin will now use whatever sbt places on the classpath, matching the sbt version in use. In theory, this should fix scala/community-build#384 and may help with sbt/sbt#1696
But zinc is provided on 2.11
The version number is now specified in a single location: build.sbt
In the new setting, jacks gets confused when the case classes that need to be serialized/deserialized have a companion object. This commit changes the companion objects into separate objects, and adapts the code references to them. Also included are fixes to tests and it tests.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Now compatible with sbt 1.0.0-M4. Refactored build files, supporting sbt 1.0.0-M4 (on 2.11) and 0.13 (on 2.10). Support for old 0.12.4 removed. Fixes for issues #190, #158, #188, and scala/community-build#384.