maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nigel Magnay <nigel.mag...@gmail.com>
Subject RepositorySystem resolving to "classes" directory in clover build..
Date Wed, 08 Feb 2012 11:22:04 GMT
I am trying to diagnose a failure when running flex-mojos copy-resources
when running a build with clover enabled. I've seen references to this also
being a problem when building with m2e.

Flex-mojos' CopyMojo finds dependencies, then copies them into the output
(for building up a WAR file). To do this, it utilises the following stanza:

 Artifact artifact =
            repositorySystem.createArtifactWithClassifier( groupId,
artifactId, version, type, classifier );
        if ( !artifact.isResolved() )
        {
            ArtifactResolutionRequest req = new ArtifactResolutionRequest();
            req.setArtifact( artifact );
            req.setLocalRepository( localRepository );
            req.setRemoteRepositories( remoteRepositories );
            ArtifactResolutionResult res = repositorySystem.resolve( req );

When running in a normal build, this results in the artifact.getFile()
returning a resolved file for copying (in this instance, a .SWF file).

However. When running with clover (mvn clean clover2:setup test
clover2:aggregate clover2:clover), when it hits this project, the build
fails.

The reason for this is that when this code is executed for one of the
artifacts defined further up the build, instead of resolving to the .SWF
file, it resolves to the ${build.dir}/classes directory.

I don't know whether this is a bug in clover, in maven, in aether or in
flex-mojos... any pointers would be useful as this prevents us from using
java code-coverage in our builds..

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message