0.11.0-RC0 and plugins
Mark Harrah
the minor version bump to 0.11. This means that plugins must now
build against 2.9.1 and use 2.9-compatible libraries. Also, the
default Scala version used for a project is the version sbt uses. So,
if you haven't specified the scalaVersion for your project, it will
now use 2.9.1.
Next, there have been some plugin-related changes to mitigate the
problems of publishing and using plugins for different sbt versions.
In the generated metadata for the plugin, either pom.xml or ivy.xml
depending on the value of publishMavenStyle, sbt includes the sbt and
Scala version that the plugin was built against.
Users should now declare dependencies on plugins by passing the
ModueID to the addSbtPlugin method. For example:
addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse" % "1.3-RC3")
This is roughly equivalent to doing:
libraryDependencies <+= (scalaVersion in update, sbtVersion) {
(scalaV, sbtV) =>
"com.typesafe.sbteclipse" % "sbteclipse" % "1.3-RC3"
extra("scalaVersion" -> scalaV, "sbtVersion" -> sbtV)
}
The intent is to better avoid mixing plugins for different sbt
versions and to provide a better error message when that happens.
Additionally, please explicitly set publishMavenStyle for your plugin.
I changed it to be false by default for plugins, but I now think that
was a mistake and will change it back for 0.11.0.
The last plugins-related change migrates the contents of
project/plugins/ to project/. This means that:
1. Instead of project/plugins/build.sbt, defing project/plugins.sbt
2. Instead of project/plugins/project/Build.scala, define
project/project/Build.scala
Basically, you can remove plugins/ from the path. The double
project/project/ looks funny, but the model is that it is the project
definition for the project definition. If this is problematic, there
could possibly be an alias to better indicate the purpose of the
second project/ definition.
The 0.10-style project/plugins/ is still supported. If
project/plugins/ exists, the 0.10 style is used and the 0.11 style is
not. I believe the 0.11 style is simpler going forward and would like
to deprecate the 0.10 style for removal in 0.12. The only
disadvantages that I know of are 1) it is different 2) it is 0.1 s
slower on startup for projects that don't define plugins. Feedback on
this change is welcome.
Thanks,
Mark
Frédérick Dubois
Maybe project/project is funny, but project/plugins/project is funnier.
-Fred
> You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
> To post to this group, send email to simple-b...@googlegroups.com.
> To unsubscribe from this group, send email to simple-build-t...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/simple-build-tool?hl=en.
>
>
--
-Fred
Greg Price
> The only disadvantages that I know of are 1) it is different 2) it is 0.1 s
> slower on startup for projects that don't define plugins. Feedback on
> this change is welcome.
The new names certainly look nicer to me. I'm curious, why does this
way take 0.1 s longer in the no-plugin case than the other way does?
It seems like you ought to be able to stat a lot of files (or do
plenty of other kinds of work) in less time than that.
Cheers,
Greg
Mark Harrah
Previously, project/*.scala sources were directly compiled without going through a full project. only project/plugins/ was a full project. Now, project/ is a full project. This means that before, if there was no plugins/ directory, a full project didn't have to get loaded. Now, it always does.
Specifically, I don't think any tasks needed to get run before sbt displayed the prompt. Now, sbt runs update+compile on an actual project to build the project definition. When fully warmed up, this doesn't take much time, but the first time probably requires a lot of classes to be loaded and any hotspots compiled. So, I expect you'd be paying that 0.1s anyway, but these things are especially noticeable at startup.
-Mark
> Cheers,
> Greg
>
eugene yokota
Joachim Hofer
However, now I have to again change my talk about sbt (and sbt
plugins) on Wednesday...
Cheers,
Joachim
Doug Tangren
Doug Tangren
A little late to the party but I tried to sbt-cross publish coffeescripted-sbt and ran into at least one potential issue which may be a bug on my part.I caught there there was a change with out the filtering of sources worked so I had to change by code a bit [1] mostly having to do with the filters. I noticed that when I compile this code an empty directory named conspicuously "~" gets created in my project directory. Is this a new sbt 0.11 thing or is this a possible bug in the new filtering code.Below is a tree of what my source looks like. The ~ is annoying because it gets generated not only with the compilation of plugin but also with the usage of my plugin
Doug Tangren
Also, I just very that the "~" directory does not get generated when I compile with the 0.10.* lines of sbt
Mark Harrah
On Mon, 5 Sep 2011 23:10:30 -0400
Doug Tangren <d.ta...@gmail.com> wrote:
>
> ...
>
> Also on a smaller note. I noticed :== was tagged as private now [2]. I had
> used that previously possible when looking at an example to see how source
> filtering was done in 0.10. What are the semantic deferences with that and
> :=. It looks like the main differences is :== takes a precomputed value. Is
> there a reason why this is now private? Or is it also on the track to
> becoming deprecated? If so, why is it so heavily used in Defaults.scala
:== is a size optimization. Every use of :== saves 1-2kB in class files (I haven't checked the exact size in 2.9 yet) and there are 85 uses of :== in Defaults.
It was never meant to be used in build definitions, maybe in plugins with large numbers of constant settings. In the end, it adds another method users think they need to learn and it isn't worth exposing it.
-Mark
Doug Tangren
:== is a size optimization. Every use of :== saves 1-2kB in class files (I haven't checked the exact size in 2.9 yet) and there are 85 uses of :== in Defaults.
It was never meant to be used in build definitions, maybe in plugins with large numbers of constant settings. In the end, it adds another method users think they need to learn and it isn't worth exposing it.
Artyom Olshevskiy
Mark Harrah
Artyom Olshevskiy <siasi...@gmail.com> wrote:
> Should cross building be disabled from now on for plugins?
You don't need to set crossPaths := false, if that is what you are asking. sbt should set things up properly if you set sbtPlugin := true.
-Mark