publish-local
Brian Clapper
Has the "publish-local" action changed in xsbt? I'm running publish-local
against an API, but the jar file isn't ending up anywhere under $HOME/.ivy2
--
Brian Clapper, b...@clapper.org
Mark Harrah
> I seem to be asking a lot of questions lately...
>
> Has the "publish-local" action changed in xsbt? I'm running publish-local
> against an API, but the jar file isn't ending up anywhere under $HOME/.ivy2
The Ivy interface got its own subproject and was cleaned up. The behavior is
supposed to be the same for the most part. Can you provide an example project
or more details about what you are doing?
-Mark
Brian Clapper
> Brian,
>
> Thanks. There were a couple of issues that needed to be fixed. 'publish-
> local' should properly handle the jar for your project now.
>
> -Mark
[Bringing this back to the correct thread. I inadvertently sent my response
to the wrong thread.]
Mark,
I'm not seeing a change. I updated both my sbt and xsbt source bases from
github, completely rebuilt both (as described at
http://code.google.com/p/simple-build-tool/wiki/0_6_Summary), and then re-ran
publish-local in my API source base. Its jar still doesn't end up under
~/.ivy2, and the other code that uses it still fails to find it.
As I noted before, it's entirely possible I'm doing something wrong. What
additional info do you need to help figure out whether this is an sbt problem
or a boneheaded user error?
--
Brian Clapper, b...@clapper.org
Mark Harrah
One possibility is that you needed to update the version in your project if
you updated after I bumped the version. In any case, it should work in
0.6.13.
You might also want to see the section in the documentation on modifying
actions [1]. Because you can't refer to super in a lazy val, actions are
split as described there. The final message is that you want dependsOn(test,
doc) not dependsOn(testAction, docAction).
-Mark
[1] http://code.google.com/p/simple-build-
tool/wiki/CustomActions#Modifying_Actions
Brian Clapper
> One possibility is that you needed to update the version in your project if
> you updated after I bumped the version. In any case, it should work in
> 0.6.13.
That was it.
Did "update" change at all in 0.6.13? I'm having trouble getting my other
project to find the locally-published API.
> You might also want to see the section in the documentation on modifying
> actions [1]. Because you can't refer to super in a lazy val, actions are
> split as described there. The final message is that you want dependsOn(test,
> doc) not dependsOn(testAction, docAction).
Thanks. I made that change.
--
Brian Clapper, b...@clapper.org
Mark Harrah
> Mark Harrah wrote:
> > One possibility is that you needed to update the version in your project
> > if you updated after I bumped the version. In any case, it should work
> > in 0.6.13.
>
> That was it.
>
> Did "update" change at all in 0.6.13? I'm having trouble getting my other
> project to find the locally-published API.
Not directly, but these things are coupled. Is the other project available,
can you provide an example, or at least the error message? Thanks for
testing!
-Mark
Brian Clapper
The other project's 2.8 changes aren't checked into github, but I can easily
describe what's going on.
The API (the one I'm doing "publish-local" on) has this build.properties file:
project.organization=org.clapper
project.name=Grizzled Scala
sbt.version=0.6.13
project.version=0.3
def.scala.version=2.7.7
build.scala.versions=2.8.0.Beta1
project.initialize=false
When I do a "publish-local", the jar file ends up in
~/.ivy2/local/org.clapper/grizzled-scala_2.8.0.Beta1/0.3/jars/grizzled-scala.jar
That looks fine to me.
The project that refers to the library uses it both as a managed dependency
and as a plugin. (The Scala project file wants to use a couple routines in
the library, hence the plugin.) That project has this configuration file:
project.organization=clapper.org
project.name=SQLShell
sbt.version=0.6.13
project.version=0.4
def.scala.version=2.7.7
build.scala.versions=2.8.0.Beta1
project.initialize=false
In both the plugin Scala file and the build file, I first tried to refer to
the library like this:
val grizzled = "org.clapper" % "grizzled-scala" % "0.3"
With that line in place, an "xsbt update" fails:
[NOT FOUND ] org.clapper#grizzled-scala;0.3!grizzled-scala.jar (0ms)
/Users/bmc/.ivy2/local/org.clapper/grizzled-scala/0.3/jars/grizzled-scala.jar
==== local: tried
/Users/bmc/.ivy2/local/org.clapper/grizzled-scala/0.3/jars/grizzled-scala.jar
Next, I tried:
val grizzled = "org.clapper" %% "grizzled-scala" % "0.3"
That leads to a different sent of errors:
Recompiling plugin definition...
Source analysis: 1 new/modified, 0 indirectly invalidated, 0 removed.
module not found: org.clapper#grizzled-scala_2.7.7;0.3
==== local: tried
/Users/bmc/.ivy2/local/org.clapper/grizzled-scala_2.7.7/0.3/ivys/ivy.xml
-- artifact org.clapper#grizzled-scala_2.7.7;0.3!grizzled-scala_2.7.7.jar:
/Users/bmc/.ivy2/local/org.clapper/grizzled-scala_2.7.7/0.3/jars/grizzled-scala_2.7.7.jar
...
==== local: tried
/Users/bmc/.ivy2/local/org.clapper/grizzled-scala_2.7.7/0.3/ivys/ivy.xml
After doing some reading, I threw in a println of crossScalaVersionString.
It's coming out as 2.7.7. I expected 2.8.0.Beta1.
Does that help? If you'd rather play with it directly, I can check the
stuff into github.
--
Brian Clapper, b...@clapper.org
Mark Harrah
Quick fix that should get you working:
override def disableCrossPaths = true
or
override def moduleID = "grizzled-scala"
Longer discussion:
You can see that the module ID 'grizzled-scala_2.8.0.Beta1' does not match the
artifact ID 'grizzled-scala'. This is because the module name in sbt 0.6
always includes the Scala version, whereas 0.5 only did it if you overrode
crossScalaVersions to enable cross-building. You override the artifact ID
directly, not including the version (which was fine), hence the mismatch.
To correct this, I can stay closer to 0.5 behavior by having the Scala version
appended only if multiple Scala versions are in 'build.scala.versions'. I
like the added version by default, though. If it stays the way it is, you'd
have to do something like crossID("grizzled-scala").
I think artifactID needs to be deprecated in any case because it makes it too
easy to mismatch the module name and artifact name. Overriding moduleID
should be the recommendation going forward.
>cala_2.7.7.jar ...
> ==== local: tried
>
> /Users/bmc/.ivy2/local/org.clapper/grizzled-scala_2.7.7/0.3/ivys/ivy.xml
>
> After doing some reading, I threw in a println of crossScalaVersionString.
> It's coming out as 2.7.7. I expected 2.8.0.Beta1.
I'm not sure where you would see crossScalaVersionString as 2.7.7, so that is
a bit odd. Where was the println?
> Does that help? If you'd rather play with it directly, I can check the
> stuff into github.
> --
> Brian Clapper, b...@clapper.org
Yes that was the problem- overriding the artifactID mixed with the different
behavior for version strings in 0.6.
-Mark
Brian Clapper
> Quick fix that should get you working:
> override def disableCrossPaths = true
> or
> override def moduleID = "grizzled-scala"
>
> Longer discussion:
> You can see that the module ID 'grizzled-scala_2.8.0.Beta1' does not match the
> artifact ID 'grizzled-scala'. This is because the module name in sbt 0.6
> always includes the Scala version, whereas 0.5 only did it if you overrode
> crossScalaVersions to enable cross-building. You override the artifact ID
> directly, not including the version (which was fine), hence the mismatch.
>
> To correct this, I can stay closer to 0.5 behavior by having the Scala version
> appended only if multiple Scala versions are in 'build.scala.versions'. I
> like the added version by default, though. If it stays the way it is, you'd
> have to do something like crossID("grizzled-scala").
>
> I think artifactID needs to be deprecated in any case because it makes it too
> easy to mismatch the module name and artifact name. Overriding moduleID
> should be the recommendation going forward.
Yes, that did the trick. I used disableCrossPaths.
I had another problem, but it was my own error. See below.
>> After doing some reading, I threw in a println of crossScalaVersionString.
>> It's coming out as 2.7.7. I expected 2.8.0.Beta1.
>
> I'm not sure where you would see crossScalaVersionString as 2.7.7, so that is
> a bit odd. Where was the println?
I was also referring to the API in Plugins.scala, and that's where I had
the println (because that's where I was seeing the problem first). Therein
lies the real problem.
- I had updated the API to use Scala 2.8.
- I had changed the references to the API in both my project Scala file AND
in Plugins.scala.
- After fixing the download problem (on your instructions, above), I then
started getting an import error (expected byte code version 4.1, got
5.0).
After scratching my head, it finally occurred to me: xsbt runs under Scala
2.7.7, even if the compilation itself runs under 2.8.0.Beta1. Thus, I
cannot use the *new* version of my API within Plugins.scala or within my
client project's build Scala file. I have to use the previous version,
because the new version is compiled under a new, and incompatible version
of Scala, and sbt itself runs under the previous version of Scala.
Duh. My bad.
By changing Plugins.scala to import an older version of my API (one
compiled with Scala 2.7), my final problem disappeared.
A println() of crossScalaVersionString from within Plugins.scala *should*
print 2.7.7, am I right?
Thanks, Mark.
--
Brian Clapper, b...@clapper.org
Mark Harrah
This is why we came up with cross-building, appending the version to the module ID, and referencing with %%. It doesn't exactly provide a better error message that way, but at least you get the error at update time. Glad it worked out in any case.
> By changing Plugins.scala to import an older version of my API (one
> compiled with Scala 2.7), my final problem disappeared.
>
> A println() of crossScalaVersionString from within Plugins.scala *should*
> print 2.7.7, am I right?
Correct.
-Mark