Build Spring Boot fat JAR using JIB - jib

I have a multi-modules project from which I build spring boot apps using Jib. I understood that fat JAR into container prevents building image efficiently (see) but one particular module needs to be packaged into a fat JAR file. As I would like to keep the same building tool for the whole multi-modules project, is it possible to package fat jar using Jib?
I already tried the repackage goal
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>2.3.5.RELEASE</version>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
that is packaging the app such as
app
├── classpath
│   └── import-metadata-service-0.0.1-SNAPSHOT.original.jar
└── libs
├── HdrHistogram-2.1.12.jar
├── LatencyUtils-2.0.3.jar
├── apache-jena-libs-3.13.0.pom
...

Yes, it is possible to put a fat jar on to the container image using Jib. Please use "containerizingMode" configuration option of Jib:
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>build</goal>
</goals>
</execution>
</executions>
<configuration>
<containerizingMode>packaged<containerizingMode>
</configuration>
</plugin>
Please refer https://github.com/GoogleContainerTools/jib/tree/master/jib-maven-plugin#extended-usage for a full set of Jib configuration option.

In case someone is stumbling over this: I have a similar usecase where I want to take advantage of jib (Dockerfile-less + can be used without docker daemon), but I currently cannot turn away from fat jars for other reasons.
Based on Chanseok comments (under the question), I came up with following, which will:
drop any layers added by jib
add the fatjar (by default in target/${build.finalName}.jar) into its own layer
overwrite entrypoint to execute "java -jar ..." instead of regular entrypoint pointing to your Main
Jib is called explicitly and not bound to lifecycle (at least in my sample), so it would have to be called explicitly with following mvn package jib:dockerBuild (or ... jib:build for a docker-daemon-less build)
using dive, you see that only one layer was added and that it is fairly large (== fat jar)
Sources: https://gitter.im/google/jib?at=5fad68c5d37a1a13d6a12174 + https://github.com/GoogleContainerTools/jib/tree/master/jib-maven-plugin#extradirectories-object
That sample works at least with spring boot 2.4.X
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<version>3.0.0</version>
<dependencies>
<dependency>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-layer-filter-extension-maven</artifactId>
<version>0.2.0</version>
</dependency>
</dependencies>
<configuration>
<container>
<entrypoint>java,-jar,/app/${project.build.finalName}.jar</entrypoint>
</container>
<extraDirectories>
<paths>
<path>
<from>target/</from>
<includes>*.jar</includes>
<into>/app</into>
</path>
</paths>
</extraDirectories>
<pluginExtensions>
<pluginExtension>
<implementation>com.google.cloud.tools.jib.maven.extension.layerfilter.JibLayerFilterExtension</implementation>
<configuration implementation="com.google.cloud.tools.jib.maven.extension.layerfilter.Configuration">
<filters>
<filter>
<!-- exclude all jib layers, which is basically anything in /app -->
<glob>/app/**</glob>
</filter>
<filter>
<!-- this is our fat jar, this should be kept by adding it into its own layer -->
<glob>/app/${project.build.finalName}.jar</glob>
<toLayer>jib-custom-fatJar</toLayer>
</filter>
</filters>
</configuration>
</pluginExtension>
</pluginExtensions>
</configuration>
</plugin>
</plugins>
</build>

Related

Dynamic maven artifactId

Is it possible for a POM to declare (or at least publish) an artifactId containing system properties? I mean the artifactId of the actual project, not dependencies.
I am using maven to build a scala project and thus, to allow publishing the project for different scala versions, in the pom.xml I'd like to declare:
<artifactId>myproject_${scalaBinaryVersion}</artifactId>
however maven 3.3. complains
[WARNING] 'artifactId' contains an expression but should be a constant
Since I'd like this project to be interoperable with sbt, what would be the best way to publish an artifact suffixed with the scala binary version?
The Maven way of doing so would be to use classifiers. From official documentation an example matches exactly your case (for different Java versions, but you can replace Java with Scala):
The classifier allows to distinguish artifacts that were built from the same POM but differ in their content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number.
As a motivation for this element, consider for example a project that offers an artifact targeting JRE 1.5 but at the same time also an artifact that still supports JRE 1.4. The first artifact could be equipped with the classifier jdk15 and the second one with jdk14 such that clients can choose which one to use.
You can configure your POM as following:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.5</version>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<classifier>${scalaBinaryVersion}</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Note: we are adding an additional execution of the Maven Jar Plugin, so the project would create two jars, the normal one + an additional one with the specified (dynamic) classifier.
Then Maven will automatically publish the classified jar together with the normal jar (since it will be automatically attached to the build). You can then import it as a further Maven dependency in another project specifying its classifier as part of the Maven GAV (GAVC in this case):
<dependency>
<groupId>your.group.id</groupId>
<artifactId>your.constant.artifact.id</artifactId>
<version>your.version</version>
<classifier>your.dynamic.classifier</classifier>
</dependency>
If you want to only build the classified one and no standard (unused) jar, you can skip the creation of the normal jar as following:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.5</version>
<executions>
<execution>
<id>default-jar</id>
<phase>none</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
<execution>
<id>scala-version-jar</id>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<classifier>${scalaBinaryVersion}</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Note: we are simply overriding the default execution of the Jar Plugin and binding it to a non existing phase. Hence Maven will only generate the classified Jar. The Install Plugin will then only install the classified one.
Update: how to have dynamic artifactId installed with dynamic dependencies
If different transitive dependencies are required for different dynamic versions, then indeed classifiers are not suitable.
Dynamic artifactIds with dynamic dependencies (and hence dynamic transitive dependencies) can however be achieved. Here below is the approach I used (and successfully tested):
As preference, I isolated the dynamic behavior in a profile, but you can obviously move it back to the default build (or have the profile active by default).
First of all, let's define in our pom the dependencies requiring a dynamic version, hence via properties as following:
<properties>
<scalaBinaryVersion>scalaversion</scalaBinaryVersion>
<dependency.version>4.11</dependency.version>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>${dependency.version}</version>
</dependency>
</dependencies>
Note: for the sake of an example, I'm using Junit as dependency in this case and not in test scope, because I want it as compile dependency (again, just for this example).
Then let's define a profile for our dynamic behavior:
<profiles>
<profile>
<id>build-scala-version</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.5</version>
<configuration>
<finalName>${project.artifactId}_${scalaBinaryVersion}-${project.version}</finalName>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.7</version>
<executions>
<execution>
<id>copy-pom</id>
<phase>generate-resources</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/${scalaBinaryVersion}</outputDirectory>
<resources>
<resource>
<directory>${basedir}</directory>
<includes>
<include>pom.xml</include>
</includes>
<filtering>true</filtering>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>com.google.code.maven-replacer-plugin</groupId>
<artifactId>replacer</artifactId>
<version>1.5.1</version>
<executions>
<execution>
<id>replace-artifactid</id>
<phase>prepare-package</phase>
<goals>
<goal>replace</goal>
</goals>
<configuration>
<file>target/${scalaBinaryVersion}/pom.xml</file>
<token><artifactId>${project.artifactId}</artifactId></token>
<!-- Replace to -->
<value><artifactId>${project.artifactId}_${scalaBinaryVersion}</artifactId></value>
<outputDir>target\${scalaBinaryVersion}\replacer</outputDir>
<outputFile>pom.xml</outputFile>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>default-install</id>
<configuration>
<skip>true</skip>
</configuration>
</execution>
<execution>
<id>install-scala-version</id>
<phase>install</phase>
<goals>
<goal>install-file</goal>
</goals>
<configuration>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}_${scalaBinaryVersion}</artifactId>
<version>${project.version}</version>
<packaging>${project.packaging}</packaging>
<file>${project.build.directory}/${project.artifactId}_${scalaBinaryVersion}-${project.version}.jar</file>
<pomFile>${project.build.directory}/${scalaBinaryVersion}/replacer/pom.xml</pomFile>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
Note, the profile is customizing and providing the following:
Changing the final Jar name with a dynamic name, depending on the runtime (aka dynamic) value, to ${project.artifactId}_{scalaBinaryVersion}-${project.version}
Filtering the existing pom file via the Maven Resources Plugin and copying it to the directory target\${scalaBinaryVersion}. The copied pom will have the dependencies with the dynamic version because the Resources Plugin will replace them. However, it will not have the dynamic artifactId (yet).
Finalizing the dynamic pom file. The Replacer plugin will replace the artifactId XML element with the dynamic value (working on the target folder, hence everything on temporarely files)
Skipping the generation of the default installation
Performing a custom install-file installation with the dynamic pom file (the filtered, copied and replaced one, providing dynamic dependencies (and as such dynamic transitive dependencies) and a dynamic artifactId
Hence, performing the following maven invocation:
mvn clean install -Pbuild-scala-version -DscalaBinaryVersion=hello -Ddependency.version=4.4
Maven will effectively install a new artifact in the local cache for the dynamic artifactId, the dynamic dependency version and the dynamic pom.
Note: if the concerned dependency version(s) and the dynamic scala version is the same, then you can save up a parameter and make the invocation shorter and more consistent.
if you are using maven for that I will saggest using multi pom with maven helper plugin so the artifactId is constant in each module.
We follow the properties (via profiles) based approach as suggested here: scala-maven-plugin FAQ
<artifactId>something_${scala.compat.version}</artifactId>
<properties>
<scala.compat.version>2.12</scala.compat.version>
</properties>
maven will still issue a warning (with good reason), but with the help of the flatten-maven-plugin we build/install poms that has the variables replaced.

GWT compilation is skipped in maven when module packaging is pom

I am trying to reuse a assembled gwt compilation in another war. For this i am try to change the current maven module's packaging from war to pom. I then plan to use maven-assembly-plugin to zip up gwt's module js output and use that later on in another war module.
I tried changing the packaging tag from <packaging>war</packaging> to <packaging>pom</packaging> in pom.xml from Validation sample . gwt-maven-plugin never enters into compilation. Instead, it skips compilation!!!!!
What is happening?
Is this expected?
Is there any workaround?
To join multiple gwt compiled modules into a single .war file, it is very easy with the maven-dependency-plugin
Package all your gwt examples as habitual (.war), and install them mvn install or mvn deploy if you have a private maven repo.
Create an empty maven module of type war, with no code but with the maven folder structure, you can put any additional stuff you need here like a global src/main/webapp/index.html.
Configure the new module to use the maven-dependency-plugin like shown below, and run mvn package:
<dependency>
<groupId>my.group</groupId>
<artifactId>example1</artifactId>
<version>...</version>
<type>war</type>
</dependency>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack-gwt-examples</id>
<phase>prepare-package</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<includeGroupIds>my.group</includeGroupIds>
<includes>**/example1/**</includes>
<outputDirectory>${project.build.directory}/${project.artifactId}-${project.version}</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
Finally and related with the gwt-maven-plugin, like with any other maven pluging, it would be enough to select an appropriate phase of the pom-packaging life cycle (package, install or deploy):
...
<packaging>pom</packaging>
...
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
...
<configuration>
...
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
Unfortunately, gwt-maven-plugin specifically disallows compilation when packaging is pom, take a look to line #269 of CompileMojo.java
You can create the reusable modules (that you mention as samples in the comments) as separate GWT projects with no EntryPoint. Package them as jar and add the following as resources:
the client side source code
other resource items that will be necessary for the final compilation (images, xml files, etc.)
Something like this:
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
...
</plugin>
</plugins>
<resources>
<resource>
<directory>src/main/java</directory>
<includes>
<include>**/services/**</include>
<include>**/client/**</include>
<include>**/public/**</include>
<include>**/*.gwt.xml</include>
</includes>
</resource>
</resources>
</build>
That's it, you can reuse it in any other GWT project. When you will do so, you just have to add the dependency (to the reusable module) in the pom.xml and import in the *.gwt.xml.
As for Maven's behaviour, it seems correct. pom packaging is going through package, install and deploy phases and
By default, the compile goal is configured to be executed during the ''prepare-package'' phase to run as late as possible.
You could change the phase in the plugin's execution, but I think it's risky because you can't know when exactly during the package phase will your code get compiled.

Maven generate-sources folder not being picked up by Eclipse

I am in the process of migrating my build from Ant to Maven. The Ant build used to compile a "code generator", execute this "code generator" which produced a set of Java and C code. It then took the generated Java code and compiled it along with some additional code produce a single jar.
I have replicated this this in Maven quite easily and it works well when I run from the command line but Eclipse is complaining and is giving me an error relating to the pom file
Failure to find {group.id}:{artifact.id}:pom:1.0.0-SNAPSHOT in
http://{our internal site repository}/nexus/content/groups/public was
cached in the local repository, resolution will not be reattempted
until the update interval of snapshots has elapsed or updates are
forced
where the group.id and artifact.id are the group and artifact id of my code generator plugin
and any code that references the generated code also fails to compile.
My maven build consists of
a generator project that contains just the Java code for the code generator.
a generator-plugin project that contains just the code to wrap the generator as a Maven plugin. This is dependent upon the generator project.
an xyz project that uses the plugin to generate the code. The code ends up in the target/generated-sources/xxx folder of this project. I have configured the build-helper-maven-plugin as per Maven compile with multiple src directories to include this extra source directory.
If I manually add the generated source folder to the Eclipse build path all of the errors relating to the code not being there go away on that project but not on any downstream projects and the "Failure to find..." error listed above remains.
What puzzles me a little is that it is referring to the ...:pom:1.0.0-SNAPSHOT when in fact my generator-plugin is defined as a maven-plugin.
Is this a sensible approach?
Why am I getting a "Failure to find..." error?
Why isn't Eclipse picking up my generated-sources folders?
I should also say I have the m2e plugin and the m2e connector for build-help-maven-plugin installed in my Eclipse IDE.
It looks like a problem during the download of the lib from the repository. I already had the same error message once.
Did you take a look at your local repository?
Go to the .m2 folder and look for /nexus/content/groups/public. If the folder is there, open it and see if the lib was download correctly. If not, try to delete the folder and try to run mvn install to force the download of the lib.
At Eclipse, run Right button > Maven > Update Project too.
Are you using an local repository like Artifactory, aren't you? Also look for the lib in the repo1-cache (or similar) folder. See if the jar is there.
Are you behind any firewall or proxy?
Using eclipse Indigo3.7, this was what I found that worked good using spring 3.1.1 which does have the 3.0.6 version as well in it. Once I got the plugins setup and put into the correct area of the pom and included the argline and endorseddirs to have the java sources put out into the target/generated-sources/cxf folder then maven generated the sources ok.
....
<properties>...
<dependencyManagement>
<dependencies>.....
</dependencyManagement>
<dependencies>
<dependency>....
</dependencies>
<!-- *************************** Build process ************************************* -->
<build>
<finalName>projName</finalName>
<plugins>
<!-- Force Java 6 -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.4</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
<!-- Deployent on AS from console
<plugin>
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>${version.jboss.as.maven.plugin}</version>
</plugin>
-->
<!-- wildbill added tomcat plugin -->
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.0</version>
</plugin>
<!-- Surefire plugin before 2.9 version is buggy. No need to declare here,
it's being referenced below w/ the version
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12</version>
</plugin>
-->
<!-- developer added these -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerArguments>
<endorseddirs>target/generated-sources/cxf</endorseddirs>
</compilerArguments>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12</version>
<configuration>
<forkMode>once</forkMode>
<argLine>-Djava.endorsed.dirs=target/generated-sources/cxf</argLine>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerArguments>
<endorseddirs>target/generated-sources/cxf</endorseddirs>
</compilerArguments>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<forkMode>once</forkMode>
<argLine>-Djava.endorsed.dirs=target/generated-sources/cxf</argLine>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<configuration>
<artifactItems>
<artifactItem>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.2</version>
</artifactItem>
<artifactItem>
<groupId>javax.xml.ws</groupId>
<artifactId>jaxws-api</artifactId>
<version>2.2</version>
</artifactItem>
</artifactItems>
<outputDirectory>target/generated-sources/cxf</outputDirectory>
</configuration>
</plugin>
</plugins>
</build>
<!-- *********************** Profiles ************************************ -->
<profiles>
<profile>
<!-- When built in OpenShift the 'openshift' profile will be
used when invoking mvn. -->
<!-- Use this profile for any OpenShift specific customization
your app will need. -->
<!-- By default that is to put the resulting archive into the
'deployments' folder. -->
<!-- http://maven.apache.org/guides/mini/guide-building-for-different-environments.html -->
<id>projName</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>process-sources</id>
<phase>generate-sources</phase>
<configuration>
<fork>once</fork>
<additionalJvmArgs>-Djava.endorsed.dirs=target/generated-sources/cxf</additionalJvmArgs>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.2</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-xjc</artifactId>
<version>2.2</version>
</dependency>
</dependencies>
</plugin>
<!-- Actual war created in default target dir -->
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.2</version>
</plugin>
</plugins>
</build>
</profile>
</profiles>
If your wsdl folder is in ${basedir}/src/main/resources it'll find it automatically
Hope this helps!

Maven GWT Plugin copies multiple versions of the same snapshot jars

I have this issue where I build my project (mvn clean install), some of the transitive dependencies are snapshot versions and are downloaded and copied into the target webapp directory e.g XXXUtil-1.0-20110922.172721-52.jar. Then when I run mvn gwt:run, it finds uses XXXUtil-1.0-SNAPSHOT.jar and copies it to the target webapp directory. I can't figure out why this is happening. In doesn't matter whether I run as exploded or inplace.
<plugins>
<!-- GWT Maven Plugin -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>2.3.0-1</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>i18n</goal>
<goal>generateAsync</goal>
</goals>
</execution>
</executions>
<configuration>
<runTarget>Shell.html</runTarget>
<hostedWebapp>${webappDirectory}</hostedWebapp>
<i18nMessagesBundle>com.myapp.client.Messages</i18nMessagesBundle>
</configuration>
<dependencies>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-user</artifactId>
<version>${gwt.version}</version>
</dependency>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-dev</artifactId>
<version>${gwt.version}</version>
</dependency>
</dependencies>
</plugin>
<!-- Copy static web files before executing gwt:run -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<executions>
<execution>
<phase>compile</phase>
<goals>
<goal>exploded</goal>
</goals>
</execution>
</executions>
<configuration>
<!-- <outputFileNameMapping>#{artifactId}#-#{version}#.#{extension}#</outputFileNameMapping> -->
<webappDirectory>${webappDirectory}</webappDirectory>
</configuration>
</plugin>
</plugins>
None of the suggestions described here help:
http://www.tikalk.com/alm/forums/maven-war-plugin-picking-multiple-version-same-snapshot-jars.
If i build local snapshots of XXXUtil-1.0-SNAPSHOT.jar it works buts not when downloading snapshots from a nexus repository. Another way to look at it is like this Project A generates a WAR, and depends on B.jar, which depends on C.jar. When i build my war using mvn install, it generates the correct jars in WEB-INF/lib so we have C-1.0-20110922.172721-52.jar. Which is correct and it works if i deploy my war. If i run in hosted mode using eclipse, its fine. But when i run mvn:gwt-run, C-1.0-SNAPSHOT.jar is copied into WEB-INF/lib so i have 2 jars C-1.0-SNAPSHOT.jar and C-1.0-20110922.172721-52.jar.
The only thing I can suggest you is to try to debug maven-gwt-plugin.
Checkout it from git repository
https://github.com/gwt-maven-plugin/gwt-maven-plugin.git
I had exactly the same problem. After debugging, I removed the use of maven-war-plugin and added maven-resources-plugin (compile phase, copy-resources goal). I tried gwt:run and install after that, worked without any problems. This way, we avoid the dependencies getting copied twice.

M2E and having maven generated source folders as eclipse source folders

I have a maven project in eclipse and have maven goals that run annotation processors to generate code. The output folder for this code is target/generated-sources/apt.
In order for Eclipse to see this generated code I need to add target/generated-sources/apt as a source folder to the Eclipse project.
However, this causes there to be an error of type "Maven Configuration Problem" saying
Project configuration is not up-to-date with pom.xml. Run project
configuration update
I think I understand why this is the case as Eclipse has a different set of source folders to Maven's set. But I need this different set, as I need Eclipse to be able to see the generated source folders...
When doing a pure Maven built, these source folders will be included in the build, by Maven.
BTW, I have upgraded to the official Eclipse release of the Maven Eclipse plugin, m2e 1.0 - what used to be m2eclipse. I'd like to see if I can find a work around/solution to this with the m2e plugin before I have to go back to the old m2eclipse version.
You need to attach the source directory with the build-helper-plugin.
Like so:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${project.build.directory}/generated-sources/java/</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
You will also need to:
Install the "Apt M2E Connector" from the Eclipse Marketplace.
To do so click the error in the Overview tab of your pom.xml and select "Discover".
Ensure there are no plugin execution filters for the build-helper-maven-plugin (see https://www.eclipse.org/m2e/documentation/m2e-execution-not-covered.html)
Right-click the Error message:
Project configuration is not up-to-date with pom.xml Run project
configuration update
in the Problems View and select Quick Fix and click Finish to select the default Update project configuration. This fixes it.
After switching to new versions of m2e/maven/apt,... i had builderrors because of the duplicated files, caused by the added buildpath by the buildhelper, so i needed to remove the "apt-generated"-Folders from the buildhelper.
To fix the Problem in Eclipse, not adding the "apt-generated"-folder via Update Maven Configuration in M2E, i've written a M2E Plugin to fix this problem. It adds the outputDirectories configured in the maven-apt-plugin to the buildpath of the Project.
https://apt-m2e.googlecode.com
In m2e 1.0 the handling of Maven plugins has changed. You might be lacking a specific m2e extension for your code generating plugin. Here is all the documentation I managed to find.
This bug report may also be relevant.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=350081
request on CXF JIRA (see 1) to add lifecycle mappings in the cxf-codegen-plugin itself. This would require m2e 1.1 but I believe it is better approach than having connectors built outside of cxf project, assuming that lifecycle mapping API would change less frequently than cxf-codegen-plugin and cxf.
You can also use the buildhelper m2e connector available in the discovery catalog. I'm using Eclipse 3.7
Eclipse Java EE IDE for Web Developers.
Version: Juno Service Release 1
mvn archetype:generate \
-DarchetypeGroupId=org.codehaus.mojo \
-DarchetypeArtifactId=gwt-maven-plugin \
-DarchetypeVersion=2.5.0
mvn clean install
work perfectly.
But in eclipse I have the same error on Asinc class.
Just press F5 on project. Fix this problem.
This was what I found that worked good using spring 3.1.1 which does have the 3.0.6 version as well in it. Once I got the plugins setup and put into the correct area of the pom and included the argline and endorseddirs to have the java sources put out into the target/generated-sources/cxf folder then maven generated the sources ok.
....
<properties>...
<dependencyManagement>
<dependencies>.....
</dependencyManagement>
<dependencies>
<dependency>....
</dependencies>
<!-- *************************** Build process ************************************* -->
<build>
<finalName>eSurety</finalName>
<plugins>
<!-- Force Java 6 -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.4</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
<!-- Deployent on AS from console
<plugin>
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>${version.jboss.as.maven.plugin}</version>
</plugin>
-->
<!-- wildbill added tomcat plugin -->
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.0</version>
</plugin>
<!-- Surefire plugin before 2.9 version is buggy. No need to declare here,
it's being referenced below w/ the version
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12</version>
</plugin>
-->
<!-- developer added these -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerArguments>
<endorseddirs>target/generated-sources/cxf</endorseddirs>
</compilerArguments>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12</version>
<configuration>
<forkMode>once</forkMode>
<argLine>-Djava.endorsed.dirs=target/generated-sources/cxf</argLine>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerArguments>
<endorseddirs>target/generated-sources/cxf</endorseddirs>
</compilerArguments>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<forkMode>once</forkMode>
<argLine>-Djava.endorsed.dirs=target/generated-sources/cxf</argLine>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<configuration>
<artifactItems>
<artifactItem>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.2</version>
</artifactItem>
<artifactItem>
<groupId>javax.xml.ws</groupId>
<artifactId>jaxws-api</artifactId>
<version>2.2</version>
</artifactItem>
</artifactItems>
<outputDirectory>target/generated-sources/cxf</outputDirectory>
</configuration>
</plugin>
</plugins>
</build>
<!-- *********************** Profiles ************************************ -->
<profiles>
<profile>
<!-- When built in OpenShift the 'openshift' profile will be
used when invoking mvn. -->
<!-- Use this profile for any OpenShift specific customization
your app will need. -->
<!-- By default that is to put the resulting archive into the
'deployments' folder. -->
<!-- http://maven.apache.org/guides/mini/guide-building-for-different-environments.html -->
<id>projName</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>process-sources</id>
<phase>generate-sources</phase>
<configuration>
<fork>once</fork>
<additionalJvmArgs>-Djava.endorsed.dirs=target/generated-sources/cxf</additionalJvmArgs>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.2</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-xjc</artifactId>
<version>2.2</version>
</dependency>
</dependencies>
</plugin>
<!-- Actual war created in default target dir -->
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.2</version>
</plugin>
</plugins>
</build>
</profile>
</profiles>
If your wsdl folder is in ${basedir}/src/main/resources it'll find it automatically
Hope this helps!
~wildbill
In case for some reason you can't use the build helper plugin the easiest way (albeit not as convenient and somewhat tedious) I have found to deal with this is:
Separate the generated source code into its own project or sub module.
You will want to keep this project predominately closed or not imported into Eclipse when you are working on the parent project.
In the parent project that needs the generated code make sure to now depend on the generated source code project via Maven pom dependency.
When you need to update the generated code go to the generated code project and run mvn install. Now refresh the parent project by right clicking and selecting Maven->Update Project...
This generally works well for projects that use a semi static source for code generation such as SOAP WSDLs (Apache CXF) or code generated from a database (jOOQ). For APT and other AspectJ-like-code it doesn't work as well because you are editing the source frequently.
For new visitors to this question -
build helper maven plugins and m2e connectors go hand in hand. Older versions
(before 2.0) of build helpers have moved into an eclipse archive link
build helper versions archived
Pick the correct link from the list and add it as an eclipse update site. It should ask you for a bunch (seriously.. a huge bunch ) of eclipse updates . Please accept and you are good to go.
the configuration to the build helper plugin did work for us.
but be aware, that the destination folder always has to be equal to the configuration of the plugin u're using for the annotation processing itself.
for example the maven-processor-plugin uses the target folder ${project.build.directory}/generated-sources/apt as default. if you wish another destination for your generated source files you can set it by the tag as shown below.
<plugin>
<groupId>org.bsc.maven</groupId>
<artifactId>maven-processor-plugin</artifactId>
<version>2.1.1</version>
<executions>
<execution>
<id>process</id>
<goals>
<goal>process</goal>
</goals>
<phase>process-sources</phase>
<configuration>
<defaultOutputDirectory>apt_generated</defaultOutputDirectory>
<processors>
<processor>com.any.processor.invoker</processor>
</processors>
</configuration>
</execution>
</executions>
</plugin>
Here is the solution
Open Marker View (Window > Show View
Right-click on the Error message
Select Quick Fix
Click Finish