Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Issues with maven, clover and and aspectJ

nathan_janken_veeva August 15, 2016

I am encountering an incompatibility between the aspectj-maven-plugin and clover-maven-plugin

The symptom of the error, is that when I compile I get a message like:

[ERROR] Failed to execute goal org.codehaus.mojo:aspectj-maven-plugin:1.7:compile (default) on project ActiveMQCommon: The artifact veeva.ecm.common:solr-aspects referenced in aspectj plugin as an aspect library, is not found the project dependencies -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:aspectj-maven-plugin:1.7:compile (default) on project ActiveMQCommon: The artifact veeva.ecm.common:solr-aspects referenced in aspectj plugin as an aspect library, is not found the project dependencies
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
 at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
 at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
 at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: The artifact veeva.ecm.common:solr-aspects referenced in aspectj plugin as an aspect library, is not found the project dependencies
 at org.codehaus.mojo.aspectj.AbstractAjcCompiler.addModulesArgument(AbstractAjcCompiler.java:667)
 at org.codehaus.mojo.aspectj.AbstractAjcCompiler.assembleArguments(AbstractAjcCompiler.java:583)
 at org.codehaus.mojo.aspectj.AbstractAjcCompiler.execute(AbstractAjcCompiler.java:489)
 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
 ... 20 more

I've been able to determine the issue.

We are using the aspectLibraries part of the aspectj-maven-plugin with something like this:

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<dependencies>
... lost of stuff here ...
</dependencies>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>test-compile</goal>
</goals>
</execution>
</executions>
<configuration>
<outxml>true</outxml>
<aspectLibraries>
<aspectLibrary>
<groupId>veeva.ecm.common</groupId>
<artifactId>solr-aspects</artifactId>
</aspectLibrary>
<aspectLibrary>
</plugin>

Notice that there is an aspectLibrary declared there.  As per the aspectj-maven-plugin documentation (http://www.mojohaus.org/aspectj-maven-plugin/examples/libraryJars.html) that aspect must also be included in the normal POM dependencies.

However, when the clover-maven-plugin runs, while the dependencies are resolving, it under the hood adds an extra maven classifier (http://stackoverflow.com/questions/20909634/what-is-the-purpose-of-classifier-tag-in-maven) tag on in the dependencies section.  So the aspectLibrary and the dependency no longer match and the compile fails.

If I change the aspectLibrary to be 

     <aspectLibrary>
<groupId>veeva.ecm.common</groupId>
<artifactId>solr-aspects</artifactId>
<classifier>clover</classifier>
</aspectLibrary>

then compile succeeds.  But then the regular compile fails.

Is there a recommended approach to dealing with this?  I'm thinking about adding a new maven profile just for running clover.  But I'm wondering if there is a better approach that is less invasive.

2 answers

0 votes
Marek Parfianowicz
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
August 18, 2016

After analysis it turned out that Clover unnecessarily adds the "clover" classifier for some artifacts. In a normal build it works fine, but it fails with the aspectj-maven-plugin, which can have an artifact dependency declared the <aspectLibrary> tag.

Bug is reported here: https://jira.atlassian.com/browse/CLOV-1966.

 

In order to workaround this, set the following option for clover-maven-plugin:

&lt;cloveredArtifactExpiryInMillis&gt;-1&lt;/cloveredArtifactExpiryInMillis&gt;

This will trick Clover to see all artifacts with the "clover" classifier as outdated and Clover will not add them to a list of dependencies.

 

Clover prints a warning in such case:

[WARNING] Using [&lt;artifact&gt;], built on &lt;date&gt; even though a Clovered version exists but it's older (lastModified: &lt;date&gt; ) and could fail the build. Please consider running Clover again on that dependency's project.

but it can be ignored as long as the "clover:setup" is used and not "clover:instrument" (the latter one usually needs "clover" artifacts).

 

0 votes
Marek Parfianowicz
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
August 15, 2016

Hi Nathan,

I assume that you are using the 'clover:instrument' goal to run Clover, am I correct? 

The 'clover:instrument' goal forks a parallel build life cycle and adds the 'clover' classifier to all Maven artifacts generated. Could you please try to use the 'clover:setup' goal instead? This goal will also instrument code and at the same time will not add 'clover' classifier and will not fork a build life cycle. 

Keep in mind to not run 'clover:setup' with the 'install' or 'deploy' phases (unless you want to install instrumented JARs in ~/.m2 directory or to deploy them to your Maven repository). We usually recommend to run Clover with "test" or "verify".

Cheers
Marek

nathan_janken_veeva August 16, 2016

Hi Marek,

Unfortunately not, we are already using clover:setup.  Here is the current command I'm using:

mvn clover:setup clover:optimize test clover:snapshot

Regards,

Nathan

Marek Parfianowicz
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
August 16, 2016

Could you please create a support ticket on support.atlassian.com, run your build with debug logging (mvn -X) and attach build log produced? Could you attach pom.xml as well (the one which contains configuration of aspectj-maven-plugin and clover-maven-plugin)? I'd like to investigate it further. 

nathan_janken_veeva August 17, 2016

For sure.  Let me also see if I can put together a little sample project that reproduces the issue.

nathan_janken_veeva August 17, 2016

I have created a service issue (CLV-6357) and attached a stripped down sample project and maven debug output.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events