I'm trying to run scoverage on a crossBuild sbt coverage +test coverageAggregate and i'm getting:
[error] Modules were resolved with conflicting cross-version suffixes in ProjectRef(uri("file:/Users/module/"), "module_name"):
[error] org.scoverage:scalac-scoverage-runtime _2.12, _2.13
from what I can tell my dependencies are with %% , except one pure java dependecy
Related
I encounter a series of file conflict with my SBT build file.I'm pick two error of them which represent properties conflict and class conflict.
The error caused by sbt assembly command, as this:
error] (util/*:assembly) deduplicate: different file contents found in the following:
[error] /Users/lorancechen/.ivy2/cache/io.netty/netty-buffer/jars/netty-buffer-4.0.42.Final.jar:META-INF/io.netty.versions.properties
[error] /Users/lorancechen/.ivy2/cache/io.netty/netty-common/jars/netty-common-4.0.42.Final.jar:META-INF/io.netty.versions.properties
[error] /Users/lorancechen/.ivy2/cache/io.netty/netty-codec-http/jars/netty-codec-http-4.0.42.Final.jar:META-INF/io.netty.versions.properties
[error] /Users/lorancechen/.ivy2/cache/io.netty/netty-codec/jars/netty-codec-4.0.42.Final.jar:META-INF/io.netty.versions.properties
[error] /Users/lorancechen/.ivy2/cache/io.netty/netty-transport/jars/netty-transport-4.0.42.Final.jar:META-INF/io.netty.versions.properties
[error] /Users/lorancechen/.ivy2/cache/io.netty/netty-handler/jars/netty-handler-4.0.42.Final.jar:META-INF/io.netty.versions.properties
[error] /Users/lorancechen/.ivy2/cache/io.netty/netty-transport-native-epoll/jars/netty-transport-native-epoll-4.0.42.Final-linux-x86_64.jar:META-INF/io.netty.versions.properties
[error] deduplicate: different file contents found in the following:
[error] /Users/lorancechen/.ivy2/cache/org.slf4j/jcl-over-slf4j/jars/jcl-over-slf4j-1.7.21.jar:org/apache/commons/logging/Log.class
[error] /Users/lorancechen/.ivy2/cache/commons-logging/commons-logging/jars/commons-logging-1.2.jar:org/apache/commons/logging/Log.class
It not caused by library version dependency conflict but because of different library has same class or file named with same package path.
I have two questions:
Is it possible fetch correct file and how to do it in sbt build file?
Java project should be follow the package namespace definition. So, why the two organization of org.slf4j/jcl-over-slf4j and commons-logging/commons-logging has the same class path org/apache/commons/logging/Log.class, rather then define as org/slf4j/commons/logging/Log.class for org.slf4j org and org/apache/commons/logging/Log.class for commons-logging org?
Besides, the name of commons-logging as a groupId is very strange.
Thanks.
I have downloaded Kafka from apache and extracted it to its own folder. Following the quickstart, I also installed sbt, but at the third line in the sbt commands (I am launching the terminal from INSIDE the kafka folder, I get:
[error] Not a valid command: assembly-package-dependency
[error] Not a valid project ID: assembly-package-dependency
[error] Expected ':' (if selecting a configuration)
[error] Not a valid key: assembly-package-dependency (similar: sbt-dependency)
[error] assembly-package-dependency
[error] ^
I have been looking for all day for an answer, but found none which would start my server. The exception when I try the kafka-server-start.sh is always
unable to find main class Kafka.kafka
I also tried "gradle" the first time, but the problem was the same. I have no chance of upgrading to Cloudera-Express to use the parcel installer: my PC is not good enough to support it.
I am quite desperate: please help me!
I found that sbt update etc didn't quite do the job, so in the end I found another answer suggesting:
In the kafka folder:
./gradlew jar
I've gotten the famous SLF4J class name collision error with sbt-assembly (below). The docs do say that SLF4J is pathological in this regard, in some way which is kept a little vague. Anyway, this happens in a project having a lot of dependencies, and it remains unclear how should one figure which classes can be just thrown away to avoid the collision without crashing at runtime.
[error] (project-name/*:assembly) deduplicate: different file contents found in the following:
[error] .ivy2/cache/commons-logging/commons-logging/jars/commons-logging-1.2.jar:org/apache/commons/logging/Log.class
[error] .ivy2/cache/org.slf4j/jcl-over-slf4j/jars/jcl-over-slf4j-1.7.12.jar:org/apache/commons/logging/Log.class
[error] deduplicate: different file contents found in the following:
[error] .ivy2/cache/commons-logging/commons-logging/jars/commons-logging-1.2.jar:org/apache/commons/logging/LogConfigurationException.class
[error] .ivy2/cache/org.slf4j/jcl-over-slf4j/jars/jcl-over-slf4j-1.7.12.jar:org/apache/commons/logging/LogConfigurationException.class
[error] deduplicate: different file contents found in the following:
[error] .ivy2/cache/commons-logging/commons-logging/jars/commons-logging-1.2.jar:org/apache/commons/logging/LogFactory.class
[error] .ivy2/cache/org.slf4j/jcl-over-slf4j/jars/jcl-over-slf4j-1.7.12.jar:org/apache/commons/logging/LogFactory.class
[error] deduplicate: different file contents found in the following:
[error] .ivy2/cache/commons-logging/commons-logging/jars/commons-logging-1.2.jar:org/apache/commons/logging/impl/NoOpLog.class
[error] .ivy2/cache/org.slf4j/jcl-over-slf4j/jars/jcl-over-slf4j-1.7.12.jar:org/apache/commons/logging/impl/NoOpLog.class
[error] deduplicate: different file contents found in the following:
[error] .ivy2/cache/commons-logging/commons-logging/jars/commons-logging-1.2.jar:org/apache/commons/logging/impl/SimpleLog$1.class
[error] .ivy2/cache/org.slf4j/jcl-over-slf4j/jars/jcl-over-slf4j-1.7.12.jar:org/apache/commons/logging/impl/SimpleLog$1.class
[error] deduplicate: different file contents found in the following:
[error] .ivy2/cache/commons-logging/commons-logging/jars/commons-logging-1.2.jar:org/apache/commons/logging/impl/SimpleLog.class
[error] .ivy2/cache/org.slf4j/jcl-over-slf4j/jars/jcl-over-slf4j-1.7.12.jar:org/apache/commons/logging/impl/SimpleLog.class
[error] deduplicate: different file contents found in the following:
[error] .ivy2/cache/ch.qos.logback/logback-classic/jars/logback-classic-1.1.3.jar:org/slf4j/impl/StaticLoggerBinder.class
[error] .ivy2/cache/org.slf4j/slf4j-nop/jars/slf4j-nop-1.6.4.jar:org/slf4j/impl/StaticLoggerBinder.class
[error] deduplicate: different file contents found in the following:
[error] .ivy2/cache/ch.qos.logback/logback-classic/jars/logback-classic-1.1.3.jar:org/slf4j/impl/StaticMDCBinder.class
[error] .ivy2/cache/org.slf4j/slf4j-nop/jars/slf4j-nop-1.6.4.jar:org/slf4j/impl/StaticMDCBinder.class
[error] deduplicate: different file contents found in the following:
[error] .ivy2/cache/ch.qos.logback/logback-classic/jars/logback-classic-1.1.3.jar:org/slf4j/impl/StaticMarkerBinder.class
[error] .ivy2/cache/org.slf4j/slf4j-nop/jars/slf4j-nop-1.6.4.jar:org/slf4j/impl/StaticMarkerBinder.class
What might be the methodology for untangling this awful mess? and I really wonder, why in fact, is this an issue in packaging (sbt assembly), and not when running the project in sbt as in sbt run?
Many thanks!
Have you read the actual link to Bridging legacy APIs from the README.md?:
Gradual migration to SLF4J from Jakarta Commons Logging (JCL)
jcl-over-slf4j.jar
To ease migration to SLF4J from JCL, SLF4J distributions include the jar file jcl-over-slf4j.jar. This jar file is intended as a drop-in replacement for JCL version 1.1.1. It implements the public API of JCL but using SLF4J underneath, hence the name "JCL over SLF4J."
Our JCL over SLF4J implementation will allow you to migrate to SLF4J gradually, especially if some of the libraries your software depends on continue to use JCL for the foreseeable future.
jcl-over-slf4j.jar "is intended as a drop-in replacement for JCL version 1.1.1." So the intended purpose it is to remove the Commons Logging proper.
What might be the methodology for untangling this awful mess?
Run show update, find out where commons-logging is coming from, and exclude it from your dependencies.
and I really wonder, why in fact, is this an issue in packaging (sbt assembly), and not when running the project in sbt as in sbt run?
It's an actual pathological classpath. In terms of logging, some part of your code could be doing something completely unexpected to what was intended. If you want to go for the Russian roulette route, there's always MergeStrategy.first.
I am trying to compile a project containing some Java 8 source files using lambdas using SBT 0.13.7.
Now, I set
-java-home /Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Home
in
/usr/local/etc/sbtopts
And apparently SBT does take this into consideration, because if I supply the wrong path it complains about no java being present.
However, when I try compiling, I get the following
[error] /Users/edafinov/GitRepos/Java8SBTTest/src/main/java/Main.java:10: error: illegal start of expression
[error] new ArrayList<Integer>().stream().filter(i -> i%2 ==0).count();
[error] ^
[error] 1 error
[error] (compile:compile) javac returned nonzero exit code
[error] Total time: 1 s, completed Dec 26, 2014 12:28:55 PM
This seems to indicate that SBT does not use javac 1.8, but rather the 1.7 one which is the default one for my system.
What am I doing wrong?
Thank you in advance
Apparently if you have a JDK in the path, SBT would try to use that one, even when you have explicitly set the -java-home option. I solved my problem by removing the default JDK from $PATH
I downloaded the scalafx-ensemble project. When I run sbt in the project's folder I'm facing the following error:
[info] Set current project to scalafxEnsemble (in build file:/C:/dev/sample/scalafx-ensemble-master/)
[ERROR] Terminal initialization failed; falling back to unsupported
java.lang.IncompatibleClassChangeError: Found class jline.Terminal, but interface was expected
at jline.TerminalFactory.create(TerminalFactory.java:101)
at jline.TerminalFactory.get(TerminalFactory.java:159)
at sbt.JLine$.sbt$JLine$$terminal(LineReader.scala:87)
at sbt.JLine$.withTerminal(LineReader.scala:91)
at sbt.JLine$.usingTerminal(LineReader.scala:97)
at sbt.JLine$.createReader(LineReader.scala:103)
at sbt.FullReader.<init>(LineReader.scala:135)
at sbt.BasicCommands$$anonfun$shell$1.apply(BasicCommands.scala:149)
...
java.lang.IncompatibleClassChangeError: Found class jline.Terminal, but interface was expected
at sbt.JLine$$anonfun$usingTerminal$1.apply(LineReader.scala:98)
at sbt.JLine$$anonfun$usingTerminal$1.apply(LineReader.scala:97)
at sbt.JLine$.withTerminal(LineReader.scala:92)
at sbt.JLine$.usingTerminal(LineReader.scala:97)
at sbt.JLine$.createReader(LineReader.scala:103)
at sbt.FullReader.<init>(LineReader.scala:135)
at sbt.BasicCommands$$anonfun$shell$1.apply(BasicCommands.scala:149)
at sbt.BasicCommands$$anonfun$shell$1.apply(BasicCommands.scala:146)
at sbt.Command$$anonfun$command$1$$anonfun$apply$1.apply(Command.scala:31)
at sbt.Command$$anonfun$command$1$$anonfun$apply$1.apply(Command.scala:31)
at sbt.Command$.process(Command.scala:95)
at sbt.MainLoop$$anonfun$1$$anonfun$apply$1.apply(MainLoop.scala:100)
...
[error] java.lang.IncompatibleClassChangeError: Found class jline.Terminal, but interface was expected
[error] Use 'last' for the full log.
If I run sbt run I'm getting the following:
at scala.tools.nsc.typechecker.Typers$Typer.doTypedApply(Typers.scala:3193)
at scala.tools.nsc.typechecker.Typers$Typer.handleOverloaded$1(Typers.scala:3190)
at scala.tools.nsc.typechecker.Typers$Typer.doTypedApply(Typers.scala:3193)
at scala.tools.nsc.typechecker.Typers$Typer.handleOverloaded$1(Typers.scala:3190)
[error] (compile:compile) java.lang.StackOverflowError
[error] Total time: 9 s, completed Jan 6, 2014 4:47:49 PM
What am I doing wrong?
This is likely problem with outdated SBT launcher. Make sure that your SBT is v.0.13 or newer.
I fixed the path to jfxrt.jar in build.sbt from
System.getenv("JAVA_HOME") + "jre/lib/jfxrt.jar"
to
System.getenv("JAVA_HOME") + "/lib/jfxrt.jar"
which is correct for my system. With the change, sbt run works fine.