You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Stephan Krull (JIRA)" <ji...@codehaus.org> on 2011/12/09 19:32:40 UTC

[jira] Commented: (MJAR-147) Classifier for test-jar is not dynamic

    [ https://jira.codehaus.org/browse/MJAR-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285361#comment-285361 ] 

Stephan Krull commented on MJAR-147:
------------------------------------

+of course:+ the patch includes setting the classifier to {{project.mainArtifact.classifier + "tests"}} if an classifier for the main artifact exists or to {{"tests"}} if there is no former classifier.

> Classifier for test-jar is not dynamic
> --------------------------------------
>
>                 Key: MJAR-147
>                 URL: https://jira.codehaus.org/browse/MJAR-147
>             Project: Maven 2.x JAR Plugin
>          Issue Type: Improvement
>    Affects Versions: 2.3.1, 2.3.2
>         Environment: maven 2.2.1, project with junit-tests, sonar analysis, maven command line: "clean package sonar:sonar install"
>            Reporter: Stephan Krull
>            Priority: Minor
>         Attachments: patchClassifier
>
>
> While the JarMojo takes into account a parameter for the classifier of the artifact in the TestJarMojo there is only a hard-coded string "tests" for the classifier.
> As this makes sense most of the time I found one possible bug for this behaviour:
> - We use Sonar to analyze our projects in the standard build process, thus running the aforementioned maven command line (see Environment). 
> - The projects build all the way to the packaging phase, this way we secure that the project is clean and all tests suceed.
> - After this the Sonar analysis starts, we configured Clover for code coverage analysis. Clover copies all source and test source files to a temporary folder and forks an additional maven command ("install"). This way Clover produces artifacts of the project with an additional classifier called "clover".
> - In the temporary folder we then have {{PROJECT_FINAL_NAME-clover.jar}} and {{PROJECT_FINAL_NAME-clover-test.jar}}. When it comes to the install phase of that forked maven run the main artifact ({{PROJECT_FINAL_NAME-clover.jar}}) is perfectly transfered to the local repository but the other artifact ({{PROJECT_FINAL_NAME-clover-test.jar}}) get copied as {{PROJECT_FINAL_NAME-test.jar}}. If the build continues there won't be a problem because the install phase of the parent maven run overwrites the test-jar again. But if the build failes we could have the following problem:
> - In the local repository now exists a test-jar of our project with additional entries from Clover because it really is a Clover-Test-JAR. Now if we take a child project that has a dependency to this test-jar the build of this child project will fail because Clover classes are needed.
> I do not know if others could have the same problem. 
> As I already use a patched version of the maven-jar-plugin (see MJAR-20) it has not been such a problem to do another patch. I attach that patch (base 2.4-SNAPSHOT) for your interest.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira