I have a dependency that requires a new version of com.fasterxml.jackson.databind.
Here is the maven config for that dependency:
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.6.5</version>
</dependency
Mule 3.7.0 uses version 2.4.3.
I've tried setting an override in the mule-deploy.properties file:
loader.override=com.fasterxml.jackson.databind
I've also tried using apache shade to re-locate/re-name the conflicting package with the following config:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.3</version>
<configuration>
<artifactSet>
<includes>
<include>com.fasterxml.jackson.core:jackson-databind</include>
</includes>
</artifactSet>
<relocations>
<relocation>
<pattern>com.fasterxml.jackson.core</pattern>
<shadedPattern>shaded.fasterxml.jackson.core.databind</shadedPattern>
</relocation>
</relocations>
</configuration>
Is there something about either of the two above approaches that is wrong, or is there another way to include a conflicting version of a dependency in the pom that is also loaded in as a different version by the Mule System classloader?
Related
I'm a bit confused. There is some documentation that says java 9 is "experimental":
https://mapstruct.org/documentation/stable/reference/html/#_using_mapstruct_on_java_9
And I found a post where a guy was having trouble in Java 10. So we are heading to java 11 and I want to know if Mapstuct will work in that environment. Specifically, will it generate the code at compile time AND does the generated code work there (I suppose the latter does).
Yes, it works on a Java 11 / Spring Boot 2 project at work, and we use Mapstruct without issues.
Yes, it is possible, although I struggled a bit with it while migrating a DropWizard project (1.3.7) to java 11. The configuration as proposed in the documentation (through the maven-compiler-plugin) didn't work for me (no error was shown, but the mapper class was not generated) so I had to use maven-processor-plugin v3.3.3.
Here is how I managed to do that:
Add the dependencies using <org.mapstruct.version>1.3.1.Final</org.mapstruct.version>
<dependency>
<groupId>org.mapstruct</groupId>
<artifactId>mapstruct</artifactId>
<version>${org.mapstruct.version}</version>
</dependency>
<dependency>
<groupId>org.mapstruct</groupId>
<artifactId>mapstruct-processor</artifactId>
<version>${org.mapstruct.version}</version>
<scope>provided</scope>
</dependency>
Then configure the plugin in the submodule as follows
<plugin>
<groupId>org.bsc.maven</groupId>
<artifactId>maven-processor-plugin</artifactId>
<version>3.3.3</version>
<executions>
<execution>
<id>process</id>
<goals>
<goal>process</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<processors>
<!-- list of processors to use -->
<processor>org.mapstruct.ap.MappingProcessor</processor>
</processors>
<outputDirectory>${basedir}/target/generated-sources-mappers</outputDirectory>
<compilerArguments>-source 11 -target 11</compilerArguments>
</configuration>
</execution>
</executions>
</plugin>
The outputDirectory is something specific to our project, but I leave there to highlight the fact that the xml tag changed from version 2.x of te plugin, in case you are migrating from that.
The compilerArguments portion was required because the plugin run javac passing java version 1.6 as default argument, which won't work if you are using lambda expressions or other new features from the language.
When compiling, make sure to pay attention to the output of the plugin, it should only show warnings, otherwise it won't generate you classes and you will get a generic ClassNotFound exception but the cause can be something not allowing your plugin to compile well.
[INFO] --- maven-processor-plugin:3.3.3:process
...
7 warnings
Also make sure you don't have any version of mapstruct library older than 1.3.0.Final in you classpath, that will also cause issues preventing classes from generating.
I used the following configuration for JDK11
<properties>
<mapstruct.version>1.3.1.Final</mapstruct.version>
<maven.compiler.version>3.6.1</maven.compiler.version>
</properties>
<dependency>
<groupId>org.mapstruct</groupId>
<artifactId>mapstruct-processor</artifactId>
<version>${mapstruct.version}</version>
<scope>provided</scope>
</dependency>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven.compiler.version}</version>
<configuration>
<annotationProcessorPaths>
<path>
<groupId>org.mapstruct</groupId>
<artifactId>mapstruct-processor</artifactId>
<version>${mapstruct.version}</version>
</path>
</annotationProcessorPaths>
</configuration>
</plugin>
</plugins>
</build>
Then mvn clean install will generate the impl classes in target\generated-sources\annotations
I have a very simple Tycho reactor with two modules: one is a standard Maven project with this addition to make it a bundle:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<executions>
<execution>
<id>default-bundle</id>
<phase>package</phase>
<goals>
<goal>bundle</goal>
</goals>
<configuration>
<instructions>
<Export-Package>org.acme.jar</Export-Package>
</instructions>
<manifestLocation>META-INF</manifestLocation>
</configuration>
</execution>
</executions>
</plugin>
The second is a Tycho project that has a dependency to the above JAR in the MANIFEST.MF.
If I start the build, I get the following exception:
[ERROR] Cannot resolve project dependencies:
[ERROR] Software being installed: plugin 0.0.1.qualifier
[ERROR] Missing requirement: plugin 0.0.1.qualifier requires 'bundle org.acme.jar 0.0.1' but it could not be found
Which is really weird, because the bundle is in the same reactor.
But no worries, I can just add the Maven dependency, too:
<!-- parent pom.xml -->
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<version>0.26.0</version>
<configuration>
<pomDependencies>consider</pomDependencies>
</configuration>
</plugin>
<!-- plug-in pom.xml -->
<dependencies>
<dependency>
<groupId>org.acme</groupId>
<artifactId>jar</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
Still I get the same exception, which is weird because the documentation claims: Maven resolves the GAV dependencies according to the normal Maven rules.
That's just not true. Evidently org.acme.jar doesn't get resolved. Or maybe Tycho fails to see that it's a bundle.
The JAR module is an API project used for server side components, and we want to drop SWT / Tycho in the long run, so it's not an option to make org.acme.jar an Eclipse plug-in.
How do I define dependencies in the same reactor for Tycho?
I’m afraid that what you ask for is currently not possible. The Tycho Wiki documents this limitation in the dependency on pom-first artifacts HOW-TO.
That being said, if you really want your whole build (maven-bundle-plugin and Tycho parts) to run with a single mvn clean install, then using the maven-invoker-plugin at the end of the “plain Maven” build to fork a “Tycho build” should work. It’s a rather cumbersome workaround, however (example on Github).
I'm trying to relocate the packages from "com.fasterxml.jackson" into my own package (ie, "mypackage.com.fasterxml.jackson") and then consume it in another JAR which I own.
I've managed to run the maven-shade plugin to do it using this configuration:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<shadedArtifactAttached>false</shadedArtifactAttached>
<createDependencyReducedPom>true</createDependencyReducedPom>
<relocations>
<relocation>
<pattern>com.fasterxml.jackson</pattern>
<shadedPattern>mypackage.com.fasterxml.jackson</shadedPattern>
</relocation>
</relocations>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
The problem that I'm facing is when I try to consume it, from some reason Eclipse keeps adding a dependency to the original jackson ("mypackage.com.fasterxml.jackson") and not the new one.
Just to be clear, my setup is:
- Jar X have a dependency in ThirdPartyArtifcats.
- ThirdPartyArtifcats references Jackson and run the maven-shade plugin, thus it contains a modified version of Jackson (mypackage.com.fasterxml.jackson).
When I try to use Jackson's ObjectMapper in Jar X, Eclipse keeps giving a reference to the original jackson.
I'll appreciate your help!
In the end I've used JarJar and created a modified JAR. Then I've added a dependency to my code and updated it manually so it now relates to the modified package instead of the original package.
Here's a procedure describing what I've done:
How to use JarJar in order to relocate classes of a JAR from one package to another
In this example we'll be changing the package from "com.fasterxml.jackson" to "io.kuku.dependencies.com.fasterxml.jackson".
- The source JAR is called "jackson-databind-2.6.4.jar" and new modified (target) JAR is called "kuku-jackson-databind-2.6.4.jar".
- The "jarjar" JAR file is in version 1.4
Create a "rules.txt" file. The contents of the file should be (watch the period before the '#' character):
rule com.fasterxml.jackson.** io.kuku.dependencies.com.fasterxml.jackson.#1
Run the following command:
java -jar jarjar-1.4.jar process rules.txt jackson-databind-2.6.4.jar kuku-jackson-databind-2.6.4.jar
Installing the modified JARs to the local repository
In this case I'm installing 3 files located on "c:\my-jars\" folder.
mvn install:install-file -Dfile=C:\my-jars\kuku-jackson-annotations-2.6.4.jar -DgroupId=io.kuku.dependencies -DartifactId=kuku-jackson-annotations -Dversion=2.6.4 -Dpackaging=jar
mvn install:install-file -Dfile=C:\my-jars\kuku-jackson-core-2.6.4.jar -DgroupId=io.kuku.dependencies -DartifactId=kuku-jackson-core -Dversion=2.6.4 -Dpackaging=jar
mvn install:install-file -Dfile=C:\my-jars\kuku-jackson-databind-2.6.4.jar -DgroupId=io.kuku.dependencies -DartifactId=kuku-jackson-annotations -Dversion=2.6.4 -Dpackaging=jar
Using the modified JARs in the project's pom
In this example, this is the "dependencies" element in the projects pom:
<dependencies>
<!-- ================================================== -->
<!-- kuku JARs -->
<!-- ================================================== -->
<dependency>
<groupId>io.kuku.dependencies</groupId>
<artifactId>kuku-jackson-annotations</artifactId>
<version>2.6.4</version>
</dependency>
<dependency>
<groupId>io.kuku.dependencies</groupId>
<artifactId>kuku-jackson-core</artifactId>
<version>2.6.4</version>
</dependency>
<dependency>
<groupId>io.kuku.dependencies</groupId>
<artifactId>kuku-jackson-databind</artifactId>
<version>2.6.4</version>
</dependency>
I'd like my Maven build to fail if the same artifact is referenced with different versions in my dependency tree. This would seem like a fairly trivial option, but I can't work out how to do it. Any clues?
The maven-enforcer-plugin has a dependencyConvergence rule which does what you want. Here's an example from the documentation.
This will cause a build to fail:
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-jdk14</artifactId>
<version>1.6.1</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-nop</artifactId>
<version>1.6.0</version>
</dependency>
</dependencies>
With this being logged during compilation:
[ERROR]
Dependency convergence error for org.slf4j:slf4j-api:1.6.1 paths to dependency are:
+-org.myorg:my-project:1.0.0-SNAPSHOT
+-org.slf4j:slf4j-jdk14:1.6.1
+-org.slf4j:slf4j-api:1.6.1
and
+-org.myorg:my-project:1.0.0-SNAPSHOT
+-org.slf4j:slf4j-nop:1.6.0
+-org.slf4j:slf4j-api:1.6.0
The Maven Dependency Plugin will include a new dependency:analyze-duplicate in its version 2.2 and this is IMHO the closest thing you can get without specific development (it won't fail the build but will list duplicate dependencies).
This goal has been added for MDEP-206 (Add new Mojo to find duplicate dependency declared), which is fixed, but the version 2.2 has yet to be released so if you want to use this feature, you'll have to build a SNAPSHOT from the source tree:
https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-dependency-plugin/
If you really want to fail the build in case of duplicate, either write your own mojo (extend the above one) or submit a RFE of the Maven Dependency Plugin.
As a side note, Maven 3 does Throw [a] Validation Error if pom contains a dependency with two different versions out of the box. To be totally accurate, this will be reported as warning in Maven 3.0 to not break existing Maven 2.x builds (see MNG-4005) and will be increased to error in 3.1 (see MNG-4622).
You can have the build fail on dependency analysis warnings using the dependency plugin.
See
http://maven.apache.org/plugins/maven-dependency-plugin/examples/failing-the-build-on-dependency-analysis-warnings.html
Add the following plugin:
Source: http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<executions>
<execution>
<configuration>
<rules>
<dependencyConvergence/>
</rules>
</configuration>
<goals>
<goal>enforce</goal>
</goals>
</execution>
</executions>
</plugin>
I'm running a project that has a dependency on groovy 1.7-beta-1. The gmaven plugin uses groovy version 1.6 as a dependency. In my pom, I specify in the dependency management section the grooyv-all version as :
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>1.7-beta-1</version>
</dependency>
</dependencies>
</dependencyManagement>
Yet when I run maven in debug mode I see that groovy 1.6 is being used for a dependency to the gmaven plugin. I thought my dependency management section would override this so they all use 1.7-beta-1, but I'm getting errors due to the different groovy versions. any help here would be appreciated.
thanks,
Jeff
Here's a refined version of Pascal's answer. I upgraded the main plugin version to 1.2, the dependency to Groovy 1.7, and wrapped it all in a pluginManagement tag so that it will nicely leverage the inheritance model.
Keep in mind that the 1.3-SNAPSHOT of the GMaven plugin has already begun using the 1.7-rc2 Groovy provider.
<!-- I wrapped everything in a plugin management section so that this can be neatly inherited across all your poms -->
<pluginManagement>
<plugins>
<plugin>
<groupId>org.codehaus.gmaven</groupId>
<artifactId>gmaven-plugin</artifactId>
<!-- Notice I upgraded it to 1.2 -->
<!-- Details here http://repo1.maven.org/maven2/org/codehaus/gmaven/gmaven-plugin/1.2/gmaven-plugin-1.2.pom -->
<version>1.2</version>
<dependencies>
<dependency>
<groupId>org.codehaus.gmaven.runtime</groupId>
<artifactId>gmaven-runtime-1.7</artifactId>
<version>1.2</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</pluginManagement>
Overriding a dependency used by a plugin is a nice ability that was actually introduced by Maven 2.0.9.
To do so, at least with a plugin that you are using as a normal build plugin - as opposed to a report which is not the case with the the gmaven-plugin so I won't cover this case here - simply add a dependency block inside the plugin block, like this (this is a sample so versions may be inaccurate):
<plugin>
<groupId>org.codehaus.groovy.maven</groupId>
<artifactId>gmaven-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<goals>
<goal>generateStubs</goal>
<goal>compile</goal>
<goal>generateTestStubs</goal>
<goal>testCompile</goal>
</goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>1.7-beta-1</version>
</dependency>
</dependencies>
</plugin>
As long as the new version of the dependency is "API compatible" with the version the plugin was linked against, you should be ok. If not, then you'll obviously have to upgrade to a newer version of the plugin compatible with the new API (i.e. likely using it as dependency), which is what you did.
To make gmaven accurately picks the right runtime is by configuring the "providerSelection" value, e.g.
<plugin>
<groupId>org.codehaus.gmaven</groupId>
<artifactId>gmaven-plugin</artifactId>
<configuration>
<providerSelection>1.7</providerSelection>
</configuration>
FYI, for the groovy:providers mojo, these are the configurations it expects (I extracted them by debugging to org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession, MavenProject) (look for XmlPlexusConfiguration):
<configuration>
<remoteRepositories implementation="java.util.List">${project.pluginArtifactRepositories}</remoteRepositories>
<project implementation="org.apache.maven.project.MavenProject">${project}</project>
<artifactRepository implementation="org.apache.maven.artifact.repository.ArtifactRepository">${localRepository}</artifactRepository>
<pluginArtifactMap implementation="java.util.Map">${plugin.artifactMap}</pluginArtifactMap>
<providerSelection implementation="java.lang.String">${gmaven.runtime}</providerSelection>
</configuration>
You need to add a similar 1.7 dependency to the dependencies of the plugin in a similarly structured <plugin> or <pluginManagement> section. Your dependency management section you are adding is proper, but does not affect the plugin dependencies. I'll try to review this reply and post an example later when I'm back at my desk.