I am getting the following error while executing the command sbt/sbt assembly :
[error] (spark-cassandra-connector-java/*:assembly) deduplicate: different file contents found in the following:
[error] /home/user/.ivy2/cache/io.netty/netty/bundles/netty-3.8.0.Final.jar:org/jboss/netty/bootstrap/Bootstrap.class
[error] /home/user/.ivy2/cache/org.jboss.netty/netty/bundles/netty-3.2.2.Final.jar:org/jboss/netty/bootstrap/Bootstrap.class
the dependencies you are using any of two dependency are dependent dependency of netty so just exclude netty from on of them like below
exclude("org.jboss.netty", "netty")
add above line in front of dependency from which u want to exclude.
Related
Since Appcelerator(/Hyperloop) doesn't use Gradle or Maven to manage dependencies, I need to include them all manually for my project by placing them in the app/platform/android folder. I have done this, however I also need to include google dagger (https://github.com/google/dagger) which requires including dagger-compiler-2.x.jar , which I believe is an annotation processor that generates some type of code during compile-time.
Simply placing this in the app/platform/android folder like any other jar results in this error when the dexer is running during the build:
[ERROR] : Failed to run dexer:
[ERROR] :
[ERROR] : PARSE ERROR:
[ERROR] : MethodHandle not supported
[ERROR] : ...while preparsing cst 016c at offset 00001ceb
[ERROR] : ...while parsing com/google/googlejavaformat/java/JavaInput.class
[ERROR] : 1 error; aborting
I think it has something to do with the part of the dagger instructions which state "you will need to include dagger-compiler-2.x.jar in your build at compile time." Is there somewhere else that I need to place this jar file to get it to be used properly? Or is the use of compile-time annotation processors not something that Appcelerator/Hyperloop supports at this time? Any thoughts or insight would be greatly appreciated.
A good amount has changed since this question was asked. This being said, I believe that currently Hyperloop for Android doesn't handle annotations. And this is how dependency injection systems work, so I believe it's still not currently possible to use that or similar JARs.
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 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.