New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Skip jacoco instrumentation for mvn modules with package type ear #169

Merged
merged 7 commits into from Dec 17, 2013

Conversation

Projects
None yet
4 participants
@mfriedenhagen
Member

mfriedenhagen commented Dec 13, 2013

In a multi module maven project ear modules are never compiled (similar to pom packaged modules) and the /target/classes directory is never created.

Jacoco correctly skipps modules with pom packaging but it tries to instrument ear modules, which leads to the following error

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jacoco:jacoco-maven-plugin:0.6.3.201306030806:report (post-test) on project mct-vermittler-vertriebsmanagement-ear: Execution post-test of goal org.jacoco:jacoco-maven-plugin:0.6.3.201306030806:report failed: basedir /var/data/jenkins/workspace/mvp.mct.vermittler-vertriebsmanagement.git.nightly/mct-vermittler-vertriebsmanagement-ear/target/classes does not exist
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at ...

Caused by: java.lang.IllegalStateException: basedir /var/data/jenkins/workspace/my-project-dir/my-module-ear/target/classes does not exist
at org.codehaus.plexus.util.DirectoryScanner.scan(DirectoryScanner.java:550)
at org.codehaus.plexus.util.FileUtils.getFileAndDirectoryNames(FileUtils.java:1717)
at org.codehaus.plexus.util.FileUtils.getFileNames(FileUtils.java:1645)

@mfriedenhagen

This comment has been minimized.

Show comment
Hide comment
@mfriedenhagen

mfriedenhagen Dec 13, 2013

Member

Hello there, I now included a sample project, however could not reproduce the error. @jlupi: do you execute any tests in your EAR? The default lifecycle for EARs (http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference) does not execute surefire:test at all :-)

Member

mfriedenhagen commented Dec 13, 2013

Hello there, I now included a sample project, however could not reproduce the error. @jlupi: do you execute any tests in your EAR? The default lifecycle for EARs (http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference) does not execute surefire:test at all :-)

@Godin

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin Dec 13, 2013

Member

@mfriedenhagen I believe that we don't need such integration test since it runs fine with usual configuration as for jar-packaging. So it just increases time of build.

Member

Godin commented on a80b7ad Dec 13, 2013

@mfriedenhagen I believe that we don't need such integration test since it runs fine with usual configuration as for jar-packaging. So it just increases time of build.

This comment has been minimized.

Show comment
Hide comment
@mfriedenhagen

mfriedenhagen Dec 13, 2013

Member
Member

mfriedenhagen replied Dec 13, 2013

@jlupi

This comment has been minimized.

Show comment
Hide comment
@jlupi

jlupi Dec 13, 2013

@mfriedenhagen no, of course I do not run any tests inside the ear module, and there are no java classes inside :) . It is just a sub-module of a maven multi module project. From what I observed jacoco instruments every submodule until you explicitly set the skip property.

The maven lifecycle is my point. Mvn does not execute the compile goal for ear packaged modules because there is nothing to compile. That's why it should be skipped by default ;-)

jlupi commented Dec 13, 2013

@mfriedenhagen no, of course I do not run any tests inside the ear module, and there are no java classes inside :) . It is just a sub-module of a maven multi module project. From what I observed jacoco instruments every submodule until you explicitly set the skip property.

The maven lifecycle is my point. Mvn does not execute the compile goal for ear packaged modules because there is nothing to compile. That's why it should be skipped by default ;-)

@mfriedenhagen

This comment has been minimized.

Show comment
Hide comment
@mfriedenhagen

mfriedenhagen Dec 13, 2013

Member

@jlupi: this is not always of course :-).

  • You might have had defined a deployment of your ear in phase pre-integration-test and run the failsafe:integration-test from within the ear module.
  • Here I use XPATH syntax to reference POM structures, e.g. //project/build/plugins would be <project><build><plugins>
  • I suspect In the parent pom of your Probably you did not use //project/build/pluginManagement/plugins but the //project/build/plugins section to configure surefire and so forced testing even on a packaging which would not do this normally. Same is true for POMs btw 😁.
  • As an immediate remedy/workaround for your current problem, setting the //project/properties/jacoco.skip to true in your EAR module should be enough.

Other solutions:

  1. Version and configure jacoco-maven-plugin, maven-surefire-plugin and maven-failsafe-plugin in //project/build/pluginManagement/plugins of your parent pom (also useful for e.g. maven-javadoc-plugin). Now in those modules of your multi module project where you have source code, you just state (without version or configuration) beneath //project/build/plugins/ which plugins to really execute. Drawback: you have to repeat the last step for every JAR and WAR.
  2. Version and configure jacoco-maven-plugin, maven-surefire-plugin and maven-failsafe-plugin in //project/profiles/profile/build/plugins of your parent pom and switch on this specific profile by checking for src/main/java for activation. Worked great in our corporate master pom, which all java projects have as uppermost parent (about 1000 projects). As an example see https://github.com/1and1/foss-parent/blob/master/pom.xml#L1085 where this is used to only run checkstyle, pmd and findbugs when src/main/javaexists. Drawback: some people consider profiles to be evil.
  3. Probably the cleanest solution: redefine the jar lifecycle by supplying your parent pom an extension jar, see https://github.com/mfriedenhagen/foss-jar-maven-plugin/blob/master/src/main/resources/META-INF/plexus/components.xml for an example how to configure your lifecycle. Create a JAR holding only the components.xml file and use the JAR via //project/build/extensions/extension. Now your parent pom stays clean and all your packaging run the goals you like 😁

While #170 does skip the execution for POMs and EARs, you may easily define other packagings without classes easily. So the best solution would be to check for the existence of target/classes, this would make the fix more independent.

Member

mfriedenhagen commented Dec 13, 2013

@jlupi: this is not always of course :-).

  • You might have had defined a deployment of your ear in phase pre-integration-test and run the failsafe:integration-test from within the ear module.
  • Here I use XPATH syntax to reference POM structures, e.g. //project/build/plugins would be <project><build><plugins>
  • I suspect In the parent pom of your Probably you did not use //project/build/pluginManagement/plugins but the //project/build/plugins section to configure surefire and so forced testing even on a packaging which would not do this normally. Same is true for POMs btw 😁.
  • As an immediate remedy/workaround for your current problem, setting the //project/properties/jacoco.skip to true in your EAR module should be enough.

Other solutions:

  1. Version and configure jacoco-maven-plugin, maven-surefire-plugin and maven-failsafe-plugin in //project/build/pluginManagement/plugins of your parent pom (also useful for e.g. maven-javadoc-plugin). Now in those modules of your multi module project where you have source code, you just state (without version or configuration) beneath //project/build/plugins/ which plugins to really execute. Drawback: you have to repeat the last step for every JAR and WAR.
  2. Version and configure jacoco-maven-plugin, maven-surefire-plugin and maven-failsafe-plugin in //project/profiles/profile/build/plugins of your parent pom and switch on this specific profile by checking for src/main/java for activation. Worked great in our corporate master pom, which all java projects have as uppermost parent (about 1000 projects). As an example see https://github.com/1and1/foss-parent/blob/master/pom.xml#L1085 where this is used to only run checkstyle, pmd and findbugs when src/main/javaexists. Drawback: some people consider profiles to be evil.
  3. Probably the cleanest solution: redefine the jar lifecycle by supplying your parent pom an extension jar, see https://github.com/mfriedenhagen/foss-jar-maven-plugin/blob/master/src/main/resources/META-INF/plexus/components.xml for an example how to configure your lifecycle. Create a JAR holding only the components.xml file and use the JAR via //project/build/extensions/extension. Now your parent pom stays clean and all your packaging run the goals you like 😁

While #170 does skip the execution for POMs and EARs, you may easily define other packagings without classes easily. So the best solution would be to check for the existence of target/classes, this would make the fix more independent.

@mfriedenhagen

This comment has been minimized.

Show comment
Hide comment
@mfriedenhagen

mfriedenhagen Dec 13, 2013

Member

@jlupi: I am only able to reproduce your issue by adding a jar project without any classes.

Member

mfriedenhagen commented Dec 13, 2013

@jlupi: I am only able to reproduce your issue by adding a jar project without any classes.

@jlupi

This comment has been minimized.

Show comment
Hide comment
@jlupi

jlupi Dec 16, 2013

@mfriedenhagen I do use //project/build/pluginManagement/plugins in the parent pom. Anyway, checking for the existence of target/classes will work for me. For now I'll just skip the module. Thanks.

jlupi commented Dec 16, 2013

@mfriedenhagen I do use //project/build/pluginManagement/plugins in the parent pom. Anyway, checking for the existence of target/classes will work for me. For now I'll just skip the module. Thanks.

@mfriedenhagen

This comment has been minimized.

Show comment
Hide comment
@mfriedenhagen

mfriedenhagen Dec 16, 2013

Member

@jlupi: I still do not see, why the report goal runs at all in your EAR. In 0.6.4 there is already a check for the existence of the datafile (

), which should prevent the report mojo from running. Somehow in your EAR-project the datafile (normally target/jacoco.exec) seems to be created.

Member

mfriedenhagen commented Dec 16, 2013

@jlupi: I still do not see, why the report goal runs at all in your EAR. In 0.6.4 there is already a check for the existence of the datafile (

), which should prevent the report mojo from running. Somehow in your EAR-project the datafile (normally target/jacoco.exec) seems to be created.

@Godin

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin Dec 16, 2013

Member

@mfriedenhagen I think that reasonable to ask @jlupi for reproducer (small example project) instead of wasting time on guesses ;)

Member

Godin commented Dec 16, 2013

@mfriedenhagen I think that reasonable to ask @jlupi for reproducer (small example project) instead of wasting time on guesses ;)

@mfriedenhagen

This comment has been minimized.

Show comment
Hide comment
@mfriedenhagen

mfriedenhagen Dec 16, 2013

Member

@Godin, @marchof: I would like to merge this PR so I can work on #171 and #119.

Member

mfriedenhagen commented Dec 16, 2013

@Godin, @marchof: I would like to merge this PR so I can work on #171 and #119.

@marchof

This comment has been minimized.

Show comment
Hide comment
@marchof

marchof Dec 17, 2013

Member

@mfriedenhagen Looks good to me.

Member

marchof commented Dec 17, 2013

@mfriedenhagen Looks good to me.

mfriedenhagen added a commit that referenced this pull request Dec 17, 2013

Merge pull request #169 from jacoco/issue-169
Skip jacoco instrumentation for mvn modules with package type ear.

@mfriedenhagen mfriedenhagen merged commit ff3074e into master Dec 17, 2013

@mfriedenhagen mfriedenhagen deleted the issue-169 branch Dec 17, 2013

@jacoco jacoco locked and limited conversation to collaborators Jan 11, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.