You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Nick Pellow <np...@atlassian.com> on 2009/02/02 07:44:17 UTC
classified artifact resolution
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.
Re: classified artifact resolution
Posted by Nick Pellow <np...@atlassian.com>.
On 05/02/2009, at 7:28 PM, Brett Porter wrote:
>>
>> Is there anything the clover2 plugin should be doing to ensure that
>> these modifications are made on the transitively resolved projects?
>
> I'd have to dig a bit - it has been a while. I thought that the
> project in a forked lifecycle was discarded (the forking mojo was
> responsible for putting changes back into the main project as
> needed, which is what you seem to need here).
>
AFAICT, this problem is happening during the forked lifecycle.
Otherwise, the output directories would not be target/clover etc?
Also, some clovered artifacts are correctly resolved.
How can the forking mojo access the main project? I am not sure the
maven-clover2-plugin does that anywhere.
> Is it possible your call to add the clover artifact itself is
> dumping the revised artifacts?
>
I don't think so. When the clover artifact itself is added, the same
dependencies added during swizzling should also be included.
ie:
Set set = new
LinkedHashSet( getProject().getDependencyArtifacts() );
set.add( cloverArtifact );
getProject().setDependencyArtifacts( set );
from: 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#l416
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
>>>>>>>>> brett@apache.org
>>>>>>>>> http://blogs.exist.com/bporter/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Brett Porter
>>>>>>> brett@apache.org
>>>>>>> http://blogs.exist.com/bporter/
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> --
>>>>> Brett Porter
>>>>> brett@apache.org
>>>>> http://blogs.exist.com/bporter/
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: classified artifact resolution
Posted by Brett Porter <br...@apache.org>.
On 04/02/2009, at 11:51 AM, Nick Pellow wrote:
> 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?
I'd have to dig a bit - it has been a while. I thought that the
project in a forked lifecycle was discarded (the forking mojo was
responsible for putting changes back into the main project as needed,
which is what you seem to need here).
Is it possible your call to add the clover artifact itself is dumping
the revised artifacts?
>
> Or should the user define the dependencies in some other way?
No, they probably don't want to duplicate everything in a profile.
>
>
> Do you think maven's dependency resolution should be treating
> classified artifacts as a different artifact to the non-classified
> artifact?
Yes, that's by design as I said earlier.
- Brett
>
>
> 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
>>>>>>>> brett@apache.org
>>>>>>>> http://blogs.exist.com/bporter/
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Brett Porter
>>>>>> brett@apache.org
>>>>>> http://blogs.exist.com/bporter/
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> --
>>>> Brett Porter
>>>> brett@apache.org
>>>> http://blogs.exist.com/bporter/
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: classified artifact resolution
Posted by Nick Pellow <np...@atlassian.com>.
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
>>>>>>> brett@apache.org
>>>>>>> http://blogs.exist.com/bporter/
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> --
>>>>> Brett Porter
>>>>> brett@apache.org
>>>>> http://blogs.exist.com/bporter/
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: classified artifact resolution
Posted by Brett Porter <br...@apache.org>.
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
>>>>>> brett@apache.org
>>>>>> http://blogs.exist.com/bporter/
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> --
>>>> Brett Porter
>>>> brett@apache.org
>>>> http://blogs.exist.com/bporter/
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: classified artifact resolution
Posted by Nick Pellow <np...@atlassian.com>.
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
>>>>> brett@apache.org
>>>>> http://blogs.exist.com/bporter/
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: classified artifact resolution
Posted by Brett Porter <br...@apache.org>.
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
>>>> brett@apache.org
>>>> http://blogs.exist.com/bporter/
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: classified artifact resolution
Posted by Nick Pellow <np...@atlassian.com>.
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
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: classified artifact resolution
Posted by Brett Porter <br...@apache.org>.
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
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: classified artifact resolution
Posted by Nick Pellow <np...@atlassian.com>.
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
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: classified artifact resolution
Posted by Brett Porter <br...@apache.org>.
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
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org