-
Notifications
You must be signed in to change notification settings - Fork 59
regression: CrossVersion.patch not found during extraction #384
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
Comments
At a guess I think this issue and the Resolver.binraryRepo issue are one and the same. Something funky with what's on the classpath is happening. I don't know what. |
@dwijnand what issue is that? |
See #264 (comment) |
If I can I will investigate; I am hacking on dbuild right now, so I might as well do some debugging concerning this matter. |
I did some debugging, and I found that some sbt 0.13.0 jars end up on the classpath, dragged in by the dbuild plugin. During the metabuild resolution, sbt prints:
and in the end both end up on the classpath. It is a bit messy, I will have to study the situation for a bit. |
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
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
@SethTisue This should be fixed in 0.9.7-RC1, can you please try it? |
@cunei fantastic! I will try it soon |
and see if it fixes the CrossVersion.patch issue, scala#384
test run: https://scala-ci.typesafe.com/view/scala-2.11.x/job/scala-2.11.x-integrate-community-build/379/consoleFull (404 til Jenkins gets his tonsils out) |
and see if it fixes the CrossVersion.patch issue, scala#384
and see if it fixes the CrossVersion.patch issue, scala#384
and see if it fixes the CrossVersion.patch issue, scala#384
@cunei I did another run with sbt and sbt-republish removed from the build — dbuild gave a message about duplicate artifacts, probably due to the name/moduleName change. we don't need to be building sbt anyway. the new run (https://scala-ci.typesafe.com/view/scala-2.11.x/job/scala-2.11.x-integrate-community-build/383/consoleFull) succeeded except for a macro-paradise failure I don't think has to do with dbuild. so this is looking good |
as of #410 we are now using 0.9.7-RC1 |
Uh oh!
There was an error while loading. Please reload this page.
a few projects have started to use
CrossVersion.patch
which is new in sbt 0.13.13the community build is on 0.13.13, so that shouldn't be a problem. but for some reason (source):
this seems mystifying. it says
[macro-compat] Using sbt version: 0.13.13
. And we also see<<= operator is deprecated
which deprecation didn't happen til 0.13.13, so that is additional evidence that 0.13.13 is being used. so how can we possibly be gettingpatch is not a member of object sbt.CrossVersion
?The text was updated successfully, but these errors were encountered: