I have not changed my setup as far as I can see. As of today, trying to run sbt native packager with jlink gives this error:
[info] Running: jdeps --multi-release 11 -R ...
[error] Exception in thread "main" java.lang.module.FindException: Module java.activation not found, required by java.xml.bind
[error] at java.base/java.lang.module.Resolver.findFail(Resolver.java:877)
[error] at java.base/java.lang.module.Resolver.resolve(Resolver.java:191)
[error] at java.base/java.lang.module.Resolver.resolve(Resolver.java:140)
[error] at java.base/java.lang.module.Configuration.resolve(Configuration.java:422)
[error] at java.base/java.lang.module.Configuration.resolve(Configuration.java:256)
[error] at jdk.jdeps/com.sun.tools.jdeps.JdepsConfiguration$Builder.build(JdepsConfiguration.java:564)
[error] at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.buildConfig(JdepsTask.java:603)
[error] at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:557)
[error] at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:533)
[error] at jdk.jdeps/com.sun.tools.jdeps.Main.run(Main.java:64)
[error] at jdk.jdeps/com.sun.tools.jdeps.Main$JDepsToolProvider.run(Main.java:73)
[error] at java.base/java.util.spi.ToolProvider.run(ToolProvider.java:137)
[error] at ru.eldis.toollauncher.ToolLauncher.runTool(ToolLauncher.java:68)
[error] at ru.eldis.toollauncher.ToolLauncher.lambda$main$1(ToolLauncher.java:33)
[error] at ru.eldis.toollauncher.ToolLauncher.main(ToolLauncher.java:48)
How do I fix this? I tried adding javax.activation to libraryDependencies, that doesn't seem to have any effect or anything to do with this problem.
Edit: The root problem of seems to be my dependency on Pi4j 1.4, which depends on javax.xml.bind:jaxb-api which in turn depends on javax.activation:javax.activation-api. Now I don't understand much of this Java module stuff, but javax.activation-api does exist on Maven, so why does jdeps complain? If I exclude javax.xml.bind, it works, but now I'm worried I'm actually missing stuff on the class path.
javax.activation has been removed since java 11.
To fix it you can:
Download the javax.activation jar and run the command by adding this jar on module path:
jdeps --multi-release 11 -R --module-path path\to\javax.activation.jar ...
Running this command with java 8 jdeps
Related
I'm trying to build kafka-connect-hdfs by following this FAQ.
While trying to compile schema-registry, I get the following error:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-
compiler-plugin:3.6.1:compile (default-compile) on project kafka-
schema-registry-client: Compilation failure
[ERROR] /Users/workspace-name/kafka-connect/schema- registry/client/src/main/java/io/confluent/kafka/schemaregistry/client/s ecurity/basicauth/SaslBasicAuthCredentialProvider.java:[40,42] cannot find symbol
[ERROR] symbol: method
loadClientContext(java.util.Map<java.lang.String,java.lang.Object>)
[ERROR] location: class org.apache.kafka.common.security.JaasContext
Are any modifications required? Appreciate any suggestions. Thanks
Attempting to build the latest https://github.com/spring-cloud/spring-cloud-contract repository.
forked repo from github
cloned fork to my local machine
mvn clean install -U
The error:
[ERROR] The build could not read 2 projects -> [Help 1] [ERROR] [ERROR] The project org.springframework.cloud:spring-cloud-contract-verifier:2.0.0.BUILD-SNAPSHOT (/Users/damienburke/workspace/oss/spring-cloud-contract/spring-cloud-contract-verifier/pom.xml) has 1 error [ERROR] 'dependencies.dependency.version' for javax.inject:javax.inject:jar is missing. # org.springframework.cloud:spring-cloud-contract-verifier:[unknown-version], /Users/damienburke/workspace/oss/spring-cloud-contract/spring-cloud-contract-verifier/pom.xml, line 43, column 15 [ERROR] [ERROR] The project org.springframework.cloud:spring-cloud-contract-maven-plugin:2.0.0.BUILD-SNAPSHOT (/Users/damienburke/workspace/oss/spring-cloud-contract/spring-cloud-contract-tools/spring-cloud-contract-maven-plugin/pom.xml) has 1 error [ERROR] 'dependencies.dependency.version' for javax.inject:javax.inject:jar is missing. # line 337, column 15 [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
I'm able to fix by adding this entry to spring-cloud-contract-parent pom.xml
<dependency>
<groupId>javax.inject</groupId>
<artifactId>javax.inject</artifactId>
<version>${javax.inject.version}</version>
</dependency>
Seems like a bug?
I can file an issue (https://github.com/spring-cloud/spring-cloud-contract/issues/new) and submit a PR if so...
We've fixed this issue recently. Pull the Changes and try again
I have a Scala project called scala-playground and I generated the configuration for Ensime with sbt ensimeConfig and sbt ensimeConfigProject.
When running M-x ensime from a buffer of the project, I can see in the Emacs statusbar that Ensime is connected: it displays Scala[scala-playground].
When running the project with C-c C-b r, a new sbt instance is started in the home directory, a directory in $HOME/project is created and instead of the project directory and fails:
[info] Loading project definition from /home/user/project
[info] Set current project to user (in build file:/home/user/)
[info] sbt server started at 127.0.0.1:4766
sbt:user>
sbt:user> run
[error] java.lang.RuntimeException: No main class detected.
[error] at scala.sys.package$.error(package.scala:27)
[error] at sbt.Defaults$.$anonfun$runTask$4(Defaults.scala:1199)
[error] at scala.Option.getOrElse(Option.scala:121)
[error] at sbt.Defaults$.$anonfun$runTask$3(Defaults.scala:1199)
[error] at sbt.Defaults$.$anonfun$runTask$3$adapted(Defaults.scala:1198)
[error] at scala.Function1.$anonfun$compose$1(Function1.scala:44)
[error] at sbt.internal.util.$tilde$greater.$anonfun$$u2219$1(TypeFunctions.scala:42)
[error] at sbt.std.Transform$$anon$4.work(System.scala:64)
[error] at sbt.Execute.$anonfun$submit$2(Execute.scala:257)
[error] at sbt.internal.util.ErrorHandling$.wideConvert(ErrorHandling.scala:17)
[error] at sbt.Execute.work(Execute.scala:266)
[error] at sbt.Execute.$anonfun$submit$1(Execute.scala:257)
[error] at sbt.ConcurrentRestrictions$$anon$4.$anonfun$submitValid$1(ConcurrentRestrictions.scala:167)
[error] at sbt.CompletionService$$anon$2.call(CompletionService.scala:32)
[error] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[error] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[error] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[error] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[error] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[error] at java.lang.Thread.run(Thread.java:748)
[error] (compile:run) No main class detected.
[error] Total time: 0 s, completed Aug 28, 2017 9:10:03 PM
What is going on?
Short story
Remove ~/project folder and then start emacs.
Long story
If you ever run sbt in your $HOME directory it created basic project structure there, mainly project and target directory. And then if you open any *.scala file emacs (sbt-mode) will go up your path to find root project directory. And it finds one in your $HOME. You can see it in doc's:
Starting from the current default-directory, find a parent
directory that is an sbt root. An sbt root directory is
identified by the following rules:
- a directory containing a 'project/build.properties' in it.
- a directory that contains a file matching one of the patterns
'*.sbt' or 'project/*.scala' file in it.
One problem with current implementation is fact that this process will be done only once per buffer. If sbt:buffer-project-root variable is set once it will be not updated.
You can force a new value either by restarting emacs, or by evaluating (setq-local sbt:buffer-project-root nil) per each opened buffer, and then starting sbt form emacs in the usual way.
If you remove ~/project and run ensime-sbt from any buffer with sbt:buffer-project-root with wrong value, it will start sbt in home, which creates ~/project again. So again, the easiest way is to kill emacs, remove the directory, and then start emacs again.
I'm having an error in one of my specs2 tests. The project is implemented with Play!Framework (Scala).
This is my test:
class AmazonEmailSenderSpec extends Specification with Mockito {
"AmazonEmailSenderSpec#sendEmail" should {
"Send Email with correct data" in {
val client = mock[AmazonSimpleEmailServiceAsyncClient]
val emailSender = new AmazonEmailSender(client)
emailSender.sendEmail(Email(subject, content, from, to, cc))
val captor = ArgumentCaptor.forClass(classOf[SendEmailRequest])
there was one(client).sendEmail(captor.capture)
val sendEmailRequest: SendEmailRequest = captor.getValue
}
}
}
This test works fine if I run it on intellij, but somehow, it fails when I run it on the console using the play activator:
activator test
I get:
[info] AmazonEmailSenderSpec#sendEmail should
[error] ! Send Email with correct data
[error] org.mockito.internal.matchers.LocalizedMatcher cannot be cast to org.mockito.ArgumentMatcher (ArgumentsComparator.java:25)
[error] org.mockito.internal.invocation.ArgumentsComparator.argumentsMatch(ArgumentsComparator.java:25)
[error] org.mockito.internal.invocation.ArgumentsComparator.argumentsMatch(ArgumentsComparator.java:17)
[error] org.mockito.internal.invocation.InvocationMatcher.matches(InvocationMatcher.java:56)
[error] org.mockito.internal.invocation.InvocationsFinder$RemoveNotMatching.isOut(InvocationsFinder.java:145)
[error] org.mockito.internal.invocation.InvocationsFinder$RemoveNotMatching.isOut(InvocationsFinder.java:137)
[error] org.mockito.internal.util.collections.ListUtil.filter(ListUtil.java:16)
[error] org.mockito.internal.invocation.InvocationsFinder.findInvocations(InvocationsFinder.java:20)
[error] org.mockito.internal.verification.checkers.MissingInvocationChecker.check(MissingInvocationChecker.java:32)
[error] org.mockito.internal.verification.Times.verify(Times.java:36)
[error] org.mockito.internal.verification.MockAwareVerificationMode.verify(MockAwareVerificationMode.java:21)
[error] org.mockito.internal.handler.MockHandlerImpl.handle(MockHandlerImpl.java:76)
[error] org.mockito.internal.handler.NullResultGuardian.handle(NullResultGuardian.java:29)
[error] org.mockito.internal.handler.InvocationNotifierHandler.handle(InvocationNotifierHandler.java:37)
[error] org.mockito.internal.creation.bytebuddy.MockMethodInterceptor.doIntercept(MockMethodInterceptor.java:36)
[error] org.mockito.internal.creation.bytebuddy.MockMethodInterceptor.access$000(MockMethodInterceptor.java:17)
[error] org.mockito.internal.creation.bytebuddy.MockMethodInterceptor$DispatcherDefaultingToRealMethod.interceptSuperCallable(MockMethodInterceptor.java:96)
[error] com.amazonaws.services.simpleemail.AmazonSimpleEmailServiceAsyncClient$MockitoMock$1778874818.sendEmail(Unknown Source)
[error] integration.email.AmazonEmailSenderSpec$$anonfun$1$$anonfun$apply$11$$anonfun$apply$12.apply(AmazonEmailSenderSpec.scala:27)
[error] integration.email.AmazonEmailSenderSpec$$anonfun$1$$anonfun$apply$11$$anonfun$apply$12.apply(AmazonEmailSenderSpec.scala:27)
[error] integration.email.AmazonEmailSenderSpec$$anonfun$1$$anonfun$apply$11.apply(AmazonEmailSenderSpec.scala:27)
[error] integration.email.AmazonEmailSenderSpec$$anonfun$1$$anonfun$apply$11.apply(AmazonEmailSenderSpec.scala:19)
I can't understand why a LocalizedMatcher is being used by activator when an ArgumentMatcher should be used instead.
The signature to the method I'm trying to match is:
public SendEmailResult sendEmail(SendEmailRequest sendEmailRequest)
Couldn't really find any hints on google. Any ideas? Am I missing something really silly?
This is an old question, but I just happened to run into the same issue in 2017:
A solution that worked for me (JUnit/Specs2, in a mixed Java/Scala) project:
I forced mockito to use the latest version 2.7.11. But I also had a dependency on org.specs2:specs2-mock_2.12:3.8.6 which is still based on mockito 1.9.5. See maven central.
Somewhere here lies the problem. I removed the dependency on specs2-mock and Specs2's mockito syntax sugar and replaced it with plain mockito code. Voila! The error mentioned above was gone.
My simple Play 2.4 project does not compile when I rename the conf/routes file to something else, e.g. conf/hello.routes. The reason I'm doing this is to enable composition of APIs while allowing them to be developed in separate git repositories and sbt projects.
The idea of multiproject support is based on this project and blog post - but that's using Play 2.3.
The error I get is:
$ sbt test
...
[info] Hello should
[error] ! give {hello: true}
[error] Unable to provision, see the following errors:
[error]
[error] 1) Error in custom provider, java.lang.ClassCastException: interface play.api.routing.Router is not assignable from class hello.routes
[error] while locating play.api.test.FakeRouterProvider
[error] while locating play.api.routing.Router
[error]
[error] 1 error (InjectorImpl.java:1025)
[error] com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1025)
[error] com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1051)
[error] play.api.inject.guice.GuiceInjector.instanceOf(GuiceInjectorBuilder.scala:321)
[error] play.api.inject.guice.GuiceInjector.instanceOf(GuiceInjectorBuilder.scala:316)
...
Got this resolved (code in the git repo now works).
The problems were likely connected to both of these:
the Controller implementation wants to be within a package controllers.hello instead of just hello
in the application.conf file one should omit the controllers namespace, i.e.
play.http.router = app.Routes
I learned this simply by comparing this code with samples that work.