Brian Fox wrote:
I think those bugs may be due to the plugin using the runtime scope
not the runtime classpath? The runtime classpath should include the
compile scope artifacts.
Let my try to describe the problem in more detail. Assume the following
POM snippet for the project that wants to employ the plugin:
<dependencies>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-plugin-api</artifactId>
<version>2.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-model</artifactId>
<version>2.0</version>
<scope>runtime</scope>
</dependency>
</dependencies>
Further assume our mojo looks basically like
/** @parameter default-value="${project.compileClasspathElements}" */
private List<String> compileClassPath;
/** @parameter default-value="${project.runtimeClasspathElements}" */
private List<String> runtimeClassPath;
public void execute()
{
getLog().info( "Compile: " + compileClassPath );
getLog().info( "Runtime: " + runtimeClassPath );
}
Now, annotating the mojo with "@requiresDependencyResolution runtime"
and running it on the above POM will make it output
Compile: [<basedir>\target\classes]
Runtime: [<basedir>\target\classes, ...\maven-model-2.0.jar,
...\plexus-utils-1.0.4.jar]
Note that the project dependency with provided scope,
maven-plugin-api-2.0-jar, appears neither on the compile class path nor
on the runtime class path. The reason being that
"@requiresDependencyResolution runtime" resolves only dependencies with
scope "runtime" or "compile" (cf. ScopeArtifactFilter) and that excludes
"provided" and "system" scope.
So, how is a plugin supposed to get a classpath consisting of
dependencies with any of the scopes "compile", "provided", "system" and
"runtime", i.e. all but "test" scope?
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
