Thanks - adding <repositoryPollutionProtection>true</repositoryPollutionProtection> right now, although I'm not sure it'll change anything for us, since we switched back from <goal>instrument</goal> to <goal>instrument-test</goal>

Update: the CLOV-1632 will not check for all possible cases in which a custom classifier could be used - it will check only if the main artifact has a custom classifier defined (which can happen if, for example, some plugin forks a build cycle and renames an artifact); it will not check if some plugin adds an additional artifact with a classifier (e.g. build-helper-maven-plugin attach-artifact, maven-antrun-plugin attachArtifact).

It means that this CLOV-1632 may not cover your specific case in full extent - it will fail a build with 'install/deploy' is called, but not if maven-jar-plugin:test-jar is called.

Cool - good news and thanks for the update ! I'll be watching the other issue

Update: I'm working on a CLOV-1632 issue, which will protect against installation / deployment of instrumented code. This issue will also check whether any artifact uses a custom classifier. This could be useful for you.

Indeed, installation happens for every forked build. And in my opinion this is a correct behaviour. In my opinion installAtEnd means "install at the end of every build life cycle executed" and not "install at the end of the main build life cycle only".

On a side note, do you have any clue why this doesn't work with installAtEnd (i.e the install happens during clover's forked process rather than at the end).

I will analyze it and let you know.

Indeed. This would require fixes/hacks in other plugins. Probably not only in the maven-jar-plugin only. Not every plugin has proper configuration options.

For instance, jar:jar has the 'classifier' property:

• JarMojo.java (line 52)

while the jar:test-jar has this hard-coded:

• TestJarMojo.java (line 56)

Ha, I naively thought this could be fixed in com.atlassian.maven.plugin.clover.CloverInstrumentInternalMojo#redirectArtifact, but now I get what you were saying earlier.. other classifiers created by other plugins are not taken care of by this method (it even looks like we could blame it on those other plugins since they override Clover's classifier)

On a side note, do you have any clue why this doesn't work with installAtEnd (i.e the install happens during clover's forked process rather than at the end)

I'd like to lower priority of this bug from Critical to Major. Do you agree?

Is that not something your plugin should be able to interfere with, though?

I'd have to investigate it. Theoretically if I could hack into maven-jar-plugin and replace 'tests' qualifier by the 'clover-tests' during the forked build, it could solve the issue. However, my previous experiences with hacking other plugins shows that they are quite isolated by class loaders.

(I'd give it a shot, but it's not OSS, is it ?)

Maven-clover2-plugin is open sourced, based on the Apache 2.0 license. You can find source code here:

• https://bitbucket.org/atlassian/maven-clover2-plugin

Hey Marek,

Thank you so much for the detailed response.

I'm not sure what do you mean by "again"

That was my own confusion: turns that we had been using instrument-test in the past, and for some reason switched back when upgrading to newer Clover versions (presumably by copy-pasting samples from doc, and not realizing we were changing that, or not realizing that made a difference)
For now, we'll get back to using the instrument-test goal; I don't think we ever needed instrument jars to be installed/deployed anyway.

I'm afraid that this is not a bug in Clover, but a general problem with Maven architecture, which does not support multiple classifiers for an artifact.

I can understand your point, but at the same time, that still means the instrument goal is not usable safely. Good call on updating the docs, thanks.
Is that not something your plugin should be able to interfere with, though ? (I'd give it a shot, but it's not OSS, is it ?)

Please let me know if there's anything else I could do for you.

Updated:

• https://bitbucket.org/atlassian/maven-clover2-plugin/commits/94a1ed49e41a50cb4c2ba8e6f9397318618ead55
• https://confluence.atlassian.com/display/CLOVER/Basic+usage

http://forums.atlassian.com/thread.jspa?messageID=257322053 – perhaps you have a copy of what that thread was saying ?

I don't have a copy of this message, I'm afraid. BTW. Some parts of this forum can be read using the Web Archive service: http://web.archive.org/web/*/forums.atlassian.com (but I couldn't find this particular message)

That said, I notice that my own issue says I should use instrument-test instead of instrument, which I suspect would fix my issue (again!?)

Yes. You can use the 'instrument-test' goal - it will fork a parallel build life cycle and run it till the 'test' phase. Thus, it won't install any artifacts.

Alternatively, you could use 'clover2:setup' with a separate location for .m2 local cache (i.e. which would keep instrumented artifacts only).

I'm not sure what do you mean by "again" - Clover's behavior did not change. I guess that you've switched from 'instrument-test' to 'instrument' at some point in time. Nevertheless, I will update maven-clover2-plugin site documentation as well as Clover site on confluence.atlassian.com to add warnings about these classifiers.

Hi Gregory,

I have reproduced the problem using the 'maven-jar-plugin' and the 'test-jar' goal. Sample output:

[INFO] --- maven-jar-plugin:2.6:jar (default-jar) @ moneybags ---
[INFO] Building jar: f:\Work\development\clov-1668-install\target\clover\moneybags-1.0-SNAPSHOT-clover.jar
[INFO]
[INFO] --- maven-jar-plugin:2.6:test-jar (default) @ moneybags ---
[INFO] Building jar: f:\Work\development\clov-1668-install\target\clover\moneybags-1.0-SNAPSHOT-clover-tests.jar
[INFO]
[INFO] --- maven-install-plugin:2.5.2:install (default-install) @ moneybags ---
[INFO] Installing f:\Work\development\clov-1668-install\target\clover\moneybags-1.0-SNAPSHOT-clover.jar to C:\Users\Mare
k\.m2\repository\com\cenqua\samples\money\moneybags\1.0-SNAPSHOT\moneybags-1.0-SNAPSHOT-clover.jar
[INFO] Installing f:\Work\development\clov-1668-install\pom.xml to C:\Users\Marek\.m2\repository\com\cenqua\samples\mone
y\moneybags\1.0-SNAPSHOT\moneybags-1.0-SNAPSHOT.pom
[INFO] Installing f:\Work\development\clov-1668-install\target\clover\moneybags-1.0-SNAPSHOT-clover-tests.jar to C:\User
s\Marek\.m2\repository\com\cenqua\samples\money\moneybags\1.0-SNAPSHOT\moneybags-1.0-SNAPSHOT-tests.jar <<<<<
[INFO]

As you can see, the "test-jar" goal created a moneybags-1.0-SNAPSHOT-clover-tests.jar file, however debugger shows that this artifact has been attached with a different classifier in Maven reactor:

• file name on disk was created by concatenating "-tests" suffix to base file name, thus we have a correct "...-clover-tests.jar",
• however, artifact name in maven reactor has "tests" only, which is not OK

As a consequence, in the next step, the maven-install-plugin copies "...-clover-tests.jar" to "~/.m2/...-tests.jar".

I'm afraid that this is not a bug in Clover, but a general problem with Maven architecture, which does not support multiple classifiers for an artifact. See the following issues:

• http://jira.codehaus.org/browse/MNG-2650
• http://jira.codehaus.org/browse/MNG-2596
• http://jira.codehaus.org/browse/MNG-2649

They have been closed as 'incomplete', so I do not expect that they will be implemented in foreseeable future.

Hi Gregory, thank you very much for reporting this problem. I'm analyzing it.

I was going to ask if you guys had an archive of the old Atlassian forum, because we had a similar issue in the past. In fact it's reported at: https://jira.magnolia-cms.com/browse/BUILD-23 – which links to http://forums.atlassian.com/thread.jspa?messageID=257322053 – perhaps you have a copy of what that thread was saying ?

That said, I notice that my own issue says I should use instrument-test instead of instrument, which I suspect would fix my issue (again!?). I'll need to go through the history of our parent pom to figure out if/why we changed it back. It would still possibly be useful to have the ability to install and even deploy the instrument jars, if it was done properly.