Cannot handle ${packaging.type} variable #3618
Comments
eed3si9n
added
Bug
area/library_management
val workaround = {
sys.props += "packaging.type" -> "jar"
()
}
Edit: See an improved workaround #3618 (comment) |
|
Thank you very much, that's solved my problem. |
|
This workaround works strangely for me: first time does not, second time works. This is very ugly - especially for a Docker installation I'm preparing. I apply the workaround proposed here. My dependency line: I begin with non-existent ~/.ivy2/cache/javax.ws.rs/javax.ws.rs-api directory. First time I run it, I still get the error: So it fails, but it creates some files in the corresponding directory: And, the next run of sbt assembly, it goes through, downloading the files into jars dir inside the above directory: The same happens with sbt package (just in case it has to do with assembly plugin). |
Numerous build systems which rely on ivy for artifact resolution
currently fail to pull artifacts which use the `{packaging.type}`
feature available for use in maven pom files.
Recent builds of Coursier do not suffer from this bug.
This change updates the version of coursier from 1.0.0 -> 1.0.3 to pull
in the fix for this issue.
For reference, some tickets related to the ivy issue:
* sbt/sbt#3618
* gradle/gradle#3065
* https://github.com/jax-rs/api/pull/576
Numerous build systems which rely on ivy for artifact resolution
currently fail to pull artifacts which use the `{packaging.type}`
feature available for use in maven pom files.
Recent builds of Coursier do not suffer from this bug.
This change updates the version of coursier from 1.0.0 -> 1.1.0-M4 to pull
in the fix for this issue. As part of that change, references to
scalaz were removed from the core but left in some of the testing code.
For reference, some tickets related to the ivy issue:
* sbt/sbt#3618
* gradle/gradle#3065
* https://github.com/jax-rs/api/pull/576
|
This still happens in sbt 1.1.0 - any version available where this is fixed? |
|
@eed3si9n this bug is not fixed (see comment from @xmariachi ) |
|
Adding an explicit dependency on javax.ws.rs-api like this worked for me: libraryDependencies += "javax.ws.rs" % "javax.ws.rs-api" % "2.1" artifacts( Artifact("javax.ws.rs-api", "jar", "jar")) I tried the workaround mentioned earlier that sets sys.props and also found that it worked sometimes but not always. |
|
Thanks @dougjanzen |
|
Getting this when adding Workaround from above works for me - but definitely sucks. |
|
I have the same error with sbt 1.2.3 when depending on kafka-streams |
|
I wonder if there's some evaluation ordering issue. Could you try libraryDependencies += {
sys.props += "packaging.type" -> "jar"
"org.apache.kafka" %% "kafka-streams-scala" % "2.0.0" withSources()
} |
|
The other workaround might be to make an ad-hoc AutoPlugin. project/PackagingTypePlugin.scalaimport sbt._
object PackagingTypePlugin extends AutoPlugin {
override val buildSettings = {
sys.props += "packaging.type" -> "jar"
Nil
}
}The above works for me. |
/code/build.sbt:3: error: illegal start of simple expression |
|
@l0n3r4n83r You need to create it at |
@eed3si9n This work for me, too. Thanks! |
|
ok. I am closing this issue then. |
|
@lavrov what sort of workaround do you have for your CI? |
|
@halfninja Thanks! Unfortunately it doesn't help. Coursier insists on downloading the jakarta.ws.rs pom (and only the pom), even though it is not needed. This is the workaround we use in our CI (bash) script: Don't forget to update the link so that it points to your local maven proxy. |
@edmondo1984 |
I tried all the above. Putting this (or something like it) into my build.sbt file is the only work-around that fixed the problem BOTH my local build (OSX) and on CircleCI (Linux). |
|
As a workaround exclude the busted dependency: ... and add a working alternative: |
This worked for me, thanks! |
|
It sounds like upstream Ivy might have fixed this in a proper way in Ivy 2.5.0-rc1. sbt's Ivy fork appears woefully far behind that, and it's not likely to be a trivial backport 😞 |
|
sbt 1.3.x switches from ivy to coursier for dependency management, so expect this to be resolved in 1.3.x series |
Thanks for this. Good workaround. |
|
This is fixed in sbt-1.3.0 unless you've opted out of coursier |
|
Confirmed using sbt 1.3.0: |
But Coursier has random failure problem when used in a corporate intranet with authenticated artifactory server, so we have to stick to Ivy. So I vote on #3618 (comment) to be best simple work around. |
|
@howardrotterdam open source software works best when you report bugs/issues to the software in question. Did you file an issue on coursier for the same? |
|
I use sbt 1.3.8, it has the same problem. |
|
Faced the same issue with sbt 1.3.13, removing sbt-coursier plugin solved this. |
and others
steps
Add following line to build.sbt
problem
When building the project, sbt throwing the following error message and quit:
expectation
${packaging.type}should be correctly handled, the correct value is "jar".notes
using sbt 1.0.2
The text was updated successfully, but these errors were encountered: