Hi Brett,
It's always hard to tell from the output - is the resources call in
the forked lifecycle or the main one afterwards? The latter would
not retain all the settings.
I'm not 100% certain, however it looks like the resources call is
happening as part of the forked lifecycle[1].
The maven-compiler-plugin, which runs after resources, is picking up
the modified buildDirectory setting correctly:
[DEBUG] (f) buildDirectory = C:\workspace\shares-trunk\shares-app
\target\clover
The modifications are being made to the main project, but not the
transitively resolved projects.
Is there anything the clover2 plugin should be doing to ensure that
these modifications are made on the transitively resolved projects?
Or should the user define the dependencies in some other way?
Do you think maven's dependency resolution should be treating
classified artifacts as a different artifact to the non-classified
artifact?
Cheers,
Nick
[1] Clover's Life-cycle
http://svn.atlassian.com/fisheye/browse/public/contrib/clover/maven-clover-plugin/trunk/src/main/resources/META-INF/maven/lifecycle.xml?r=24080
On 03/02/2009, at 10:04 PM, Brett Porter wrote:
There's a further resolution step. The resources:resources in
question is for the app, and has both:
[DEBUG] com.fidelity.shares:shares-app:jar:1.0-SNAPSHOT (selected
for null)
[DEBUG] com.fidelity.shares:shares-domain:jar:clover:1.0-
SNAPSHOT:compile (selected for compile)
and
[DEBUG] com.fidelity.shares:shares-mail:jar:clover:1.0-
SNAPSHOT:compile (selected for compile)
[DEBUG] com.fidelity.shares:shares-domain:jar:1.0-
SNAPSHOT:compile (selected for compile)
The modifications are being made to the main project, but not the
transitively resolved projects.
It's always hard to tell from the output - is the resources call in
the forked lifecycle or the main one afterwards? The latter would
not retain all the settings.
- Brett
On 03/02/2009, at 4:08 PM, Nick Pellow wrote:
You're right. the dependency artifacts are already transitive.
e.g. the -X output shows:
[DEBUG] [Clover] List of dependency artifacts after changes:
[DEBUG] [Clover] Artifact [com.fidelity.shares:shares-
domain:jar:clover:1.0-SNAPSHOT], scope = [compile]
....
[DEBUG] [Clover] List of artifacts after changes:
[DEBUG] [Clover] Artifact [com.fidelity.shares:shares-
domain:jar:clover:1.0-SNAPSHOT], scope = [compile]
....
The full list of artifacts 'after changes' only includes shares-
domain:jar:clover .ie - the correctly resolved and classified
artifact.
This is in both the "dependency artifacts" and the artifacts list.
ie:
getProject
().setDependencyArtifacts
(swizzleCloverDependencies
( getProject().getDependencyArtifacts() ) );
getProject
().setArtifacts
(swizzleCloverDependencies( getProject().getArtifacts() ) );
This seems to not be the case when resources:resources runs?
A -X log file showing this is attached to our forum: output.txt .
The tests fail with a:
"DuplicateMappingException: Duplicate class/entity mapping
com.fidelity.shares.domain.simple.SimpleThing"
at the end of that file. Just above this, you can see that both the
classified and non-classified versions of the shares-domain
artifact are on the classpath.
The full post is:
http://forums.atlassian.com/thread.jspa?threadID=22387&tstart=0
On 03/02/2009, at 3:33 PM, Brett Porter wrote:
The dependency artifacts should already be transitive. I'm not
quite sure how you are seeing the results you are. Have you
tracked the output of the swizzling process? Does -X show what is
then fed into the compiler plugin in the forked lifecycle?
- Brett
On 03/02/2009, at 3:26 PM, Nick Pellow wrote:
Will the filtering be applied to the artifacts resolved by the
maven-compiler-plugin, and the maven-surefire-plugin?
My understanding is that:
1) the maven-clover2-plugin creates a classified artifact with
the -clover classifier. it also looks for -clover classified
artifacts of project dependencies and sets those on the
MavenProject.
2) any other plugins called as part of the build lifecycle then
resolve both the classified and the non-classified versions of
the same artifact
3) certain plugins assert that the classpath contains only a
distinct set of classes. if more than one class is found on the
classpath they fail the build.
AFAICT, the maven-clover2-plugin is setting a distinct set of
artifacts on the project via: http://svn.atlassian.com/fisheye/browse/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentInternalMojo.java?r=27752#l325
.
I think however that when the classpath is built by the maven-
compiler-plugin, say, it is resolving all transitive
dependencies, and finding the non-classified clovered artifact.
Does this sound plausible? Should clover be swizzling
dependencies transitively ?
Cheers,
Nick
On 03/02/2009, at 12:24 PM, Brett Porter wrote:
You can't modify the resolution, but you can filter the
artifacts it gets from the project. There are a few utility
classes for that (you'll see them used in the dependency plugin,
assembly plugin for example).
- Brett
On 03/02/2009, at 12:14 PM, Nick Pellow wrote:
Thanks for the clarification, Brett.
What can the maven-clover2-plugin do to ensure that only
classified artifacts are resolved if they are available?
On 03/02/2009, at 9:17 AM, Brett Porter wrote:
Yes, that's expected - artifacts with a particular classifier
are considered different to artifacts with a different or no
classifier.
On 02/02/2009, at 5:44 PM, Nick Pellow wrote:
Hi,
The maven-clover2-plugin creates both a classified and a
normal jar artifact for each sub-module it builds.
I have a problem, where I am seeing both a classified _and_ a
non-classified artifact being put on the classpath under
certain circumstances.
e..g
[INFO] Compiling 3 source files to target\clover\test-classes
[DEBUG] com.app:app:jar:1.0-SNAPSHOT (selected for null)
[DEBUG] com.app:app-domain:jar:clover:1.0-SNAPSHOT:compile
(selected for compile)
... and ...
[DEBUG] com.app:app-mail:jar:clover:1.0-SNAPSHOT:compile
(selected for compile)
[DEBUG] com.app:app-domain:jar:1.0-SNAPSHOT:compile
(selected for compile)
This debug output shows that both com.app:app-
domain:jar:clover:1.0-SNAPSHOT and com.app:app-domain:jar:1.0-
SNAPSHOT:compile are on the compile time classpath.
Is this expected behavior? Is there something possibly
misconfigured that will cause this?
Cheers,
Nick Pellow
Atlassian Clover.
--
Brett Porter
[email protected]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Brett Porter
[email protected]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Brett Porter
[email protected]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Brett Porter
[email protected]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
