GWT compilation is skipped in maven when module packaging is pom - gwt

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.

Related

How to tell Maven to update manifest's Bundle-Version?

I'm building Eclipse's plugins using Maven, and I'm looking for a way to tell Maven to update the Bundle-Version in the META-INF\MANIFEST.MF file.
The trick is, I need a clean way to do it. So that further colleagues (or even me in some months/years) may not break the final automated build.
Here is what I tried :
Using "Bundle-Version: ${project.version}" in the MANIFEST.MF
On a maven point-of-view, this is working.
BUT my Eclipse project is constantly displaying an error : The specified version does not have the correct format (major.minor.micro.qualifier)
Using the above but in another META-INF folder (named META-INF-MAVEN) that is used by maven instead of the original :
<resources>
<resource>
<directory>META-INF-MAVEN</directory>
<targetPath>META-INF</targetPath>
<filtering>true</filtering>
</resource>
</resources>
This is still "working", but the needed duplication of MANIFEST.MF file is far away from what I'm looking for. This is a large trap for future errors, like editing the original MANIFEST.MF file and forgetting the maven one, resulting in a bugged release.
Using org.apache.maven.plugins to add the Bundle-Version tag at compile-time from the pom file :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifestFile>target/classes/META-INF/MANIFEST.MF</manifestFile>
<manifestEntries>
<Bundle-Version>${project.version}</Bundle-Version>
</manifestEntries>
</archive>
</configuration>
</plugin>
This is the most promising way, BUT it only works if the original MANIFEST.MF does not have a Bundle-Version line.
The result is, again, an error within the Eclipse project.
And so, here I am, asking for any idea.
Thanks.
Following solution finds the Bundle-Version: line in META-INF/MANIFEST.MF and replaces it with the Maven project version. replacer maven plugin was used for that but there are certainly other maven plugins that can do the same work like find-and-replace-maven-plugin.
<plugin>
<groupId>com.google.code.maven-replacer-plugin</groupId>
<artifactId>replacer</artifactId>
<version>1.5.3</version>
<executions>
<execution>
<id>update-manifest-version</id>
<phase>process-resources</phase>
<goals>
<goal>replace</goal>
</goals>
<configuration>
<file>${basedir}/META-INF/MANIFEST.MF</file>
<regex>true</regex>
<replacements>
<replacement>
<token>Bundle-Version: .*</token>
<value>Bundle-Version: ${project.artifact.selectedVersion.majorVersion}.${project.artifact.selectedVersion.minorVersion}.${project.artifact.selectedVersion.incrementalVersion}.qualifier
</value>
</replacement>
</replacements>
</configuration>
</execution>
</executions>
</plugin>

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.

Is there any way to execute many maven build one after the other in Eclipse?

I work on several project which I often have to make maven-install on them.
Is there a way to execute many maven build one after the other on many projects ?
I hope i'm understandable.
Thanks for help
I was too looking for that.
But didn't get satisfied on Creating just a new main maven project and
add all other projects to build as its modules project.
This way I could trigger all the projects builds by triggering just main project build.
But still, that wasn't digestable.
Well, you can script that and use the -f switch of maven to specify which pom to build one after the other...
If you want to stick with maven, you can make a dedicated pom for invoking the sequence of your build by using the maven exec plugin. But this results a naaasty pom. Use it as last resort, because plugins should be used only once in one phase of the maven lifecycle. In certain cases it might be handy, e.g. you want to be able to run your build on different platforms and don't want to script with python, etc..):
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<configuration>
<executable>mvn</executable>
<arguments>
<argument>-DskipTests=true</argument>
<argument>-f</argument>
<argument>${basedir}/relative/path/to/other/module/pom.xml</argument>
<argument>clean</argument>
<argument>install</argument>
</arguments>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<configuration>
<executable>mvn</executable>
<arguments>
<argument>-DskipTests=true</argument>
<argument>-f</argument>
<argument>${basedir}/relative/path/to/some/other/module/pom.xml</argument>
<argument>clean</argument>
<argument>install</argument>
</arguments>
</configuration>
</plugin>
</plugins>
<build>
<pluginManagement>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<executions>
<execution>
<phase>process-resources</phase>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
</plugin>
<pluginManagement>

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

Clover+Maven+Eclipse

I am using eclipse + maven2 to build my applications.
I need to start working with clover.
My question is therefore: from your experience, what is the best way to combine these 3.
I mean, I know there is a clover plugin for eclipse, there is also a clover plugin for maven2 and of course there is maven plugin for eclipse (m2eclipse - which I am already using).
What should I use and how?
Thank you.
Under Eclipse, use the Clover Eclipse Plugin.
Under Maven, use the Maven Clover Plugin. Add a Clover Report to the site generation:
<project>
[...]
<build>
<plugins>
<plugin>
<groupId>com.atlassian.maven.plugins</groupId>
<artifactId>maven-clover2-plugin</artifactId>
<configuration>
[...]
</configuration>
<executions>
<execution>
<phase>pre-site</phase>
<goals>
<goal>instrument</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
<reporting>
<plugins>
[...]
<plugin>
<groupId>com.atlassian.maven.plugins</groupId>
<artifactId>maven-clover2-plugin</artifactId>
<configuration>
[...]
</configuration>
</plugin>
</plugins>
</reporting>
[...]
Optionally, you can check for a test coverage percentage and fail the build in case of non-compliance:
<build>
<plugins>
<plugin>
<groupId>com.atlassian.maven.plugins</groupId>
<artifactId>maven-clover2-plugin</artifactId>
<configuration>
<targetPercentage>80%</targetPercentage>
</configuration>
<executions>
<execution>
<phase>verify</phase>
<goals>
<goal>instrument</goal>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
The maven build remains the master. Run it using your preferred method (command line or m2eclipse).
I'm using the clover-report along with the automated site generation by maven. For that you just have to add the clover plugin to your POMs reporting section as describes here. That way you can also get a historical report about your code coverage.
Calling/starting the maven process is done via the m2eclipse plugin and that's it. But you could also use all 3 plugins. So for example install the clover plugin for eclipse so that you don't have to generate the whole site again and again when you only want the code coverage (with the clover plugin for eclipse you can see the coverage right inside eclipse) and use the clover maven plugin to generate a "final" code coverage for any released piece of code. The m2eclipse plugin is not really needed for neither clover-maven nor clover-eclipse but it's nice when working with eclipse and maven.