This resolution resolves the Clover defect MCLOVER-77

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.