You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Karl Heinz Marbaise (JIRA)" <ji...@apache.org> on 2015/12/19 23:14:46 UTC

[jira] [Comment Edited] (MJAR-147) Classifier for test-jar is not dynamic

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

Karl Heinz Marbaise edited comment on MJAR-147 at 12/19/15 10:14 PM:
---------------------------------------------------------------------

Now you can define the classifier for test-jar goals as well.


was (Author: khmarbaise):
Now you can define the classfier for test-jar goals as well.

> Classifier for test-jar is not dynamic
> --------------------------------------
>
>                 Key: MJAR-147
>                 URL: https://issues.apache.org/jira/browse/MJAR-147
>             Project: Maven 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
>            Assignee: Karl Heinz Marbaise
>            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 was sent by Atlassian JIRA
(v6.3.4#6332)