[jira] (MEAR-76) This resolution resolves the Clover defect MCLOVER-77

2014-12-27 Thread Karl-Heinz Marbaise (JIRA)

 [ 
https://jira.codehaus.org/browse/MEAR-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl-Heinz Marbaise closed MEAR-76.
---

Resolution: Cannot Reproduce
  Assignee: Karl-Heinz Marbaise  (was: Stéphane Nicoll)

Based on the age of the issue i will close the issue. If you have any 
objections or new information etc. don't hesitate to reopen the issue.

> This resolution resolves the Clover defect MCLOVER-77
> -
>
> Key: MEAR-76
> URL: https://jira.codehaus.org/browse/MEAR-76
> Project: Maven Ear Plugin
>  Issue Type: Improvement
>Affects Versions: 2.3.1
> Environment: windows/jdk1.5/cloer plugin 2.3.1 and above
>Reporter: Martin Franklin
>Assignee: Karl-Heinz Marbaise
> Attachments: cloverclassifier.diff
>
>
> The clover plugin 'swizzles' the dependencies of an artifact when the 
> clover:instrument goal is executed. This adds the classifier 'clover' to 
> those dependencies of the ear which can be resolved as clovered artifacts. 
> However due to some assumptions made in constructing the ear the problem 
> detailed in http://jira.codehaus.org/browse/MCLOVER-77 can be created.
> The cause turns out to be multiple problems - first after clover 'swizzles' 
> the dependencies the list gets new versions added during ear processing. I 
> suspect this is due to the classifier being different so the dependencies of 
> the dependencies are not found and so they get added again. Thus the same 
> dependency is listed in the project.getArtifacts() Set. Once with the clover 
> classifier and once with null. The second problem is the application.xml 
> generation which adds a second set of dependencies. This can be resolved by 
> specifying the classifier for the specific module listed in the Modules 
> section. However this is awkward to use if you wish to use the same pom for 
> both clovered and unclovered ear generation. This patch supports this.
> This patch will always select an artifact with a classifier rather than one 
> with null set. The matching is only done at the groupid/artifactid level, but 
> I believe that should be sufficient.
> Duplicate EarModules are also removed so that only the most specific 
> gorupid/artifactid/classifier is used for both inclusion in the ear and 
> inclusion in the application.xml
> One last point about the patch - I could not get test 42 to run before I 
> started work on the patch, so this test is commented out in the patch. All 
> the other tests worked fine.
> As creating a test would require creating a linkage with the clover plugin, 
> and the fact that the clover plugin itself needs a patch MCLOVER-82, in order 
> to fully display these effects easily, I haven't created a test case for it. 
> I have tested this with my own projects which show that MCLOVER-77 is now 
> resolved with this patch.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MEAR-76) This resolution resolves the Clover defect MCLOVER-77

2012-01-08 Thread Torsten Liermann (JIRA)

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

Torsten Liermann commented on MEAR-76:
--

i have a similar when building with cobertura. "Cobertura" is the classifier. I 
must play with module excludes and extra step for removing duplicate entries 
from application.xml.


> This resolution resolves the Clover defect MCLOVER-77
> -
>
> Key: MEAR-76
> URL: https://jira.codehaus.org/browse/MEAR-76
> Project: Maven 2.x Ear Plugin
>  Issue Type: Improvement
>Affects Versions: 2.3.1
> Environment: windows/jdk1.5/cloer plugin 2.3.1 and above
>Reporter: Martin Franklin
>Assignee: Stephane Nicoll
> Attachments: cloverclassifier.diff
>
>
> The clover plugin 'swizzles' the dependencies of an artifact when the 
> clover:instrument goal is executed. This adds the classifier 'clover' to 
> those dependencies of the ear which can be resolved as clovered artifacts. 
> However due to some assumptions made in constructing the ear the problem 
> detailed in http://jira.codehaus.org/browse/MCLOVER-77 can be created.
> The cause turns out to be multiple problems - first after clover 'swizzles' 
> the dependencies the list gets new versions added during ear processing. I 
> suspect this is due to the classifier being different so the dependencies of 
> the dependencies are not found and so they get added again. Thus the same 
> dependency is listed in the project.getArtifacts() Set. Once with the clover 
> classifier and once with null. The second problem is the application.xml 
> generation which adds a second set of dependencies. This can be resolved by 
> specifying the classifier for the specific module listed in the Modules 
> section. However this is awkward to use if you wish to use the same pom for 
> both clovered and unclovered ear generation. This patch supports this.
> This patch will always select an artifact with a classifier rather than one 
> with null set. The matching is only done at the groupid/artifactid level, but 
> I believe that should be sufficient.
> Duplicate EarModules are also removed so that only the most specific 
> gorupid/artifactid/classifier is used for both inclusion in the ear and 
> inclusion in the application.xml
> One last point about the patch - I could not get test 42 to run before I 
> started work on the patch, so this test is commented out in the patch. All 
> the other tests worked fine.
> As creating a test would require creating a linkage with the clover plugin, 
> and the fact that the clover plugin itself needs a patch MCLOVER-82, in order 
> to fully display these effects easily, I haven't created a test case for it. 
> I have tested this with my own projects which show that MCLOVER-77 is now 
> resolved with this patch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira