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
Related
Hi I tried to clone the repository and build the source as mentioned in the opendaylight wiki page. But the build is failing.
Link: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Netconf:Testtool#Building_testtool
The following are the steps I followed:
Check out latest netconf repository from git
Dive into netconf/netconf/tools/netconf-testtool/ folder
Build testtool using mvn clean install command
The build fails with the following error trace:
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for org.opendaylight.netconf:netconf-parent:1.5.0-SNAPSHOT: Could not find artifact org.opendaylight.mdsal:binding-parent:pom:0.13.0-SNAPSHOT and 'parent.relativePath' points at no local POM # org.opendaylight.netconf:netconf-parent:1.5.0-SNAPSHOT, /home/balakrishnan/netconf_simulator/netconf/netconf/netconf-parent/pom.xml, line 11, column 11
#
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project org.opendaylight.netconf:netconf-testtool:1.5.0-SNAPSHOT (/home/balakrishnan/netconf_simulator/netconf/netconf/tools/netconf-testtool/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM for org.opendaylight.netconf:netconf-parent:1.5.0-SNAPSHOT: Could not find artifact org.opendaylight.mdsal:binding-parent:pom:0.13.0-SNAPSHOT and 'parent.relativePath' points at no local POM # org.opendaylight.netconf:netconf-parent:1.5.0-SNAPSHOT, /home/balakrishnan/netconf_simulator/netconf/netconf/netconf-parent/pom.xml, line 11, column 11 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
The build needs artifacts which your Maven setup doesn’t know about. You need to edit your settings.xml file; if you’re running in a Unix-style environment:
cp -n ~/.m2/settings.xml{,.orig}
wget -q -O - https://raw.githubusercontent.com/opendaylight/odlparent/master/settings.xml > ~/.m2/settings.xml
This will configure Maven to download OpenDaylight artifacts from the OpenDaylight Nexus repositories; you will then be able to build netconf-testtool directly.
You need to build the entire netconf project (ie mvn install) from the top-down.
I'm trying to work through the book Reactive Web Applications, but it seems that it's already a bit out of date in that lightbend activator has been EOL'd so I can't download it (or at least can't figure out how to and probably shouldn't even if I could).
I'm faced with the problem of creating the new project, which in the book would be done via the command
activator new twitter-stream play-scala-2.4
I tried what I though was the equivalent sbt command but got the following error.
urban:playground dhosek$ sbt new playframework/play-scala-seed.g8
[info] Set current project to playground (in build
file:/Users/dhosek/playground/)
[error] Not a valid command: new (similar: set)
[error] Not a valid project ID: new
[error] Expected ':' (if selecting a configuration)
[error] Not a valid key: new (similar: name, run, runner)
[error] new
[error] ^
Any help?
It appears that the problem is that brew installs an old version of sbt.
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'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.