I'm using Maven 3.0.4 and Axis2 1.5.1 plugin. I've a problem with the generation of a stub class using AXIS2 plugin on Maven.
Depending on the JDK currently configured on the build environment, AXIS2 plugin generates a different stub class source code. I've tried the generation using JDK 1.6 and then JDK 1.7.
Is there any way to "force" the JDK (i.e. 1.6) used by the AXIS2 plugin inside Maven (without changing environment)? (I would like to have a code generation independent from the environment)
Any help will be much appreciated.
I assume you select your JDK like described here :
http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html
Then, I would generate the stub using a different profile, allowing you to override some configuration, but keeping the benefits of your overall conf.
Unfortunately, all my attempts are unsuccessful.
I have to resign myself to what I was shown in another post (http://maven.40175.n5.nabble.com/Maven-amp-Axis2-plugin-different-stub-code-generation-tc5730726.html ): if I really require this type of functionality, I may have to do this work yourself. Otherwise ask Axis2 devs if someone
will volunteer to do it.
Related
Recently I encountered strange problem with Spring, Kotlin and Spock. I have very simple project (spring-boot, spring-web). I have one Controller with few Beans injected to this Controller. Everything works just fine. Problem is in test. I am not able to mock any of those Beans. kotlin-spring/kotlin-allopen does not add open signature to beans defined in Configuration class. On the other hand if I change this declaration to #Component everything works fine.
Here is my build.gradle.kts plugin listing
plugins {
id("idea")
id("groovy")
id("maven-publish")
id("org.springframework.cloud.contract") version "2.2.5.RELEASE"
id("org.springframework.boot") version "2.4.1"
id("io.spring.dependency-management") version "1.0.10.RELEASE"
kotlin("jvm") version "1.4.21"
kotlin("plugin.spring") version "1.4.21"
kotlin("plugin.allopen") version "1.4.21"
}
This is error message:
Caused by: org.spockframework.mock.CannotCreateMockException: Cannot create mock for class *** because Java mocks cannot mock final classes. If the code under test is written in Groovy, use a Groovy mock.
I know that it says that I can use GroovyMock but I wanted to design my base class in test and I wanted to use #TestConfiguration class. So to mock those classes I wanted to use DetachedMockFactory.
Is there a way to configure Spock to be able to mock final classes from Kotlin? Or is there a way to tell kotlin-spring/kotlin-allopen to open classes defined as beans in Configuration class?
Edit:
My example project is here:
https://github.com/czyzniek/bank/tree/with-spock
I cannot help you fix the spock-mockable problem, maybe you want to ask the author for help. Recently I fixed a Maven issue in that project already, but now it seems like there is a ByteBuddy issue, trying to redefine an already loaded class which is impossible in the JVM. I am sure the maintainer can help you with that.
Meanwhile, like I suggested in a previous comment, switching to Sarek solves the problem, though. I created a corresponding pull request for you.
For now it uses the full Sarek agent, which is the default. If you add sarek-unfinal as a dependency instead of sarek and also make sure that you set the system property dev.sarek.agent.type=unfinal in your Gradle configuration for Spock tests, you can use the smaller unfinal agent without the rest of the Sarek functionality instead. As a Gradle noob I do not know how to configure that, though.
Update: There is no more need for the additional system property mentioned above. The latest Sarek snapshot auto-detects the unfinal agent (or any other of the 4 types of Sarek agents) when it is on the class path. I know you have decided to use spock-mockable, but I want to keep this answer up to date for reference. See this diff for what the pull request would look like now, especially this simple commit.
Please let me know if you have any issues using the snapshot version for now. If this is a commercial project and you need to build a release in which snapshot versions are forbidden at some point, I can publish an 1.0 or maybe a 0.8 or whatever on Maven Central. For now I just added the Maven Central snapshot repository (Sonatype OSS) to your build.
Thanks for help everybody! #kriegaex your solution works like a charm, thanks for that!
Regarding spock-mockable, I talked with author of this library and he figured out why spock-mockable could not work with my setup (GH issue). It was because of spock-spring extension. The root cause is that spock-spring extension was loaded before spock-mockable. When Spring/Spock wanted to create mocks from #TestConfiguration class it couldn't, because kotlin-spring plugin does not open classes declared as beans in a #Configuration class and spock-mockable was not loaded at this time. joke changed the way his extension is loaded, so right now both solutions spock-mockable and sarek work.
I believe that concludes my problem ;)
We are building a OSGi bundle using maven-bundle-plugin. The default configuration works good but the problem arises when deploying the bundle in a container. Running jdeps on the jar shows the code is compatible with compact1 profile and I would like to force maven-bundle-plugin to use compact1 instead of the derived JavaSE 1.8. How can we achieve this?
We don't want to use _noee just to be on the safe side because of an earlier advise.
FELIX-6199 is a related issue.
I wrote a Maven application that I want to use in my Jmeter BeanShell script.
The Maven application is using Google Guice 4.2.2 for dependecy injection and it is calling an API at the end (Code needs to perform some other operations before calling the API and that's why I am not using the JMeter Plugin). I am creating the uber JAR (Fat JAR) with maven-shade-plugin. When I run the Jar from the command line the application run successfully!
However, When I load the JAR in my Jmeter test plan and call my application main method in the Jmeter BeanShell I am getting the following error:
java.lang.NoSuchMethodError: com.google.common.base.Preconditions.checkArgument(ZLjava/lang/String;Ljava/lang/Object;)V
at com.google.inject.Key.ensureRetainedAtRuntime(Key.java:341) ~[load-testing.jar:?]
.
.
.
Now lots of other threads mentioned that this can be because of older Google Guava version (20.x older) but from the dependency tree I see the Guava version is 25.1-android and I can run my JAR successfully from the command line!!
Also, I list the classes in the Uber JAR by running jar -tf command and I can see that the com.google.common.base.Preconditions class is there.
I would appreciate it if someone can shed some light on this matter and help me to resolve this?
It seems that your fat-jar contains multiple versions of Guava (which may be caused by the shade-plugin).
Make sure to lock it to single version by using Mavens dependency management in each maven module. (https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management)
The Beanshell itself might be a problem, since JMeter 3.1 it's recommended to use JSR223 Test Elements and Groovy language for scripting, the reasons are in:
Groovy is more "modern" language which supports all modern Java features while with Beanshell you're stuck at Java 1.5 language level (no lambdas, no generics, no multi-catch etc.)
Groovy performance is much better comparing to Beanshell cause Grooovy engine implements Compilable interface and is capable of caching compiled scripts providing performance very close to native Java code
Groovy provides a lot of enhancements on top of standard Java SDK
Check out Apache Groovy - Why and How You Should Use It article for more details.
I have finally cofirmed my comment. The problem was my JAR Guava version was conflicting with Jmeter Guava version (which is 17.0) and Jmeter for some reason is picking up its own Guava version, after downgrading Guice version to 3.0 which does not depend on guava, I successfully ran my JAR through Jmeter.
There is still a mystery on why Jmeter is overriding my JAR Guava version with its own. I will create a ticket with Jmeter in order to find more about this mystery but this change solved my problem
I'm trying to build a Java 5 system using Java 6. I have configured and with 1.5, but I also need to set to point at a Java 5 rt.jar to ensure there are no faulty linkages like using Java 6 APIs. Has anyone ever configured maven to somehow pull rt.jar from a repository and reference it this way?
You can verify your usage of external libraries - and implicitly of the Java core APIs - by using the Animal Sniffer Maven Plugin
The Animal Sniffer Plugin is used to build signatures of APIs and to check your classes against previously generated signatures.
The plugin website shows how to generate signatures for the Java runtime and how to check against generated signatures.
You can send the source and target options down to javac by configuring the default maven java compiler plugin. Take a look at this page for an example.
How can I use jars that buildr loads by default into the local maven repo, rather than creating new (and repetitive) artifact tasks/dependencies?
For example, if were creating a scala or groovy application buildr would automatically download the scala or groovy jars respectively. Is it possible to include or merge these (default) jars into an application rather than creating a new artifact?
I think that is not possible or doable in a one step, easy way. I recommend you talk with us on the dev list of Buildr and we can probably create an enhancement for that.
For each library you would like to depend on, you usual can grep the code to find where we define the default jar we depend on.
For the example you mention, here are the default method to retrieve the default jars:
For Groovy: Buildr::Groovy::Groovyc.dependencies
For Scala: Buildr::Scala::Scalac.dependencies
I hope that helps.