You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brian Fox <br...@infinity.nu> on 2009/08/01 04:11:59 UTC
Re: [DISCUSS] Extend Mojo API to allow for resolution of multiple
dependency scopes
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.
2009/7/31 Benjamin Bentmann <be...@udo.edu>:
> Hi,
>
> I would like to propose an extension of the mojo annotation
>
> @requiresDependencyResolution <requiredScope>
>
> This currently allows to resolve only a single scope from the set "compile", "runtime" and "test". A problem I have seen in some plugins is about using "runtime" scope. This scope is not a superset of "compile" as it excludes "system" and "provided" scoped dependendies. However, sometimes plugins really want the aggregation of "compile" and "runtime", see [0], [1] and [2] for some use cases that I could quickly recover.
>
> Hence I suggest we extend the mojo annotation to support the specification of multiple scopes, e.g.
>
> @requiresDependencyResolution compile,runtime
>
> or deprecate the existing anno and create a new annotation like
>
> @resolveDependencies compile,runtime
>
> The first approach would not require an udpate of the plugin tools but lacks any migration path for plugins to run with old and new Maven versions. Once the multiple scopes are listed in the anno, the plugin's prerequisite would need to be bumped to the newer Maven version.
>
> The second approach would need a few updates to the plugin tools like extracting the new anno and writing it into the plugin descriptor, e.g. as a new field
>
> <dependencyResolutionScopes>compile,runtime</dependencyResolutionScopes>
>
> This way would allow plugins to specify both @requiresDependencyResolution and the new annotation. New Maven versions would give the new annotation precedence. The plugin could check the Maven version and see whether it can trust the dependency sets in the MavenProject or whether it needs its 2.0.x workaround code.
>
> WDYT?
>
>
> Benjamin
>
>
> [0] http://jira.codehaus.org/browse/MEXEC-51
> [1] http://jira.codehaus.org/browse/MGWT-77
> [2] http://code.google.com/p/gwt-maven/issues/detail?id=161
>
> ---------------------------------------------------------------------
> 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: [DISCUSS] Extend Mojo API to allow for resolution of multiple dependency scopes
Posted by Jason van Zyl <jv...@sonatype.com>.
On 2-Aug-09, at 2:40 PM, Benjamin Bentmann wrote:
> Brian Fox wrote:
>
>> In the dependency and enforcer plugins where I potentially need
>> everything, I just ask for test to be resolved and then i pick the
>> elements i need.
>
> Yeah, I know, the problem I described is not impossible to solve.
> All I wondered is whether this pattern does not give evidence of a
> design weakness in the core that we could fix.
>
I believe it does. Having to make two calls to get what you need, or
using the test scope as Brian does shows there's something wrong.
Don't know if it's possible but I think in 3.x system scope should
just go away. Install the artifacts or for artifacts you need in the
JDK the strategy of creating a classloader for the tools you need
works well and we could make a helper for this.
The possibly resolving provided dependencies during test execution.
Maybe the resolution being aware of the part of the lifecycle. So
provided dependencies being available up until package and then shed.
Just thinking out loud. But I think there is a design problem for sure.
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
What matters is not ideas, but the people who have them. Good people
can fix bad ideas, but good ideas can't save bad people.
-- Paul Graham
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Extend Mojo API to allow for resolution of multiple
dependency scopes
Posted by Stephen Connolly <st...@gmail.com>.
2009/8/3 Benjamin Bentmann <be...@udo.edu>
> Brian Fox wrote:
>
> Perhaps what is needed is the addition of a
>> few more "resolution scope" tags that a plugin could ask for. I mean,
>> how many combinations aren't already covered by the existing scopes?
>> If it's small and adding one or two more might be easier to support
>> and maintain than allowing a list of them...
>>
>
> Sure, a new "resolution scope" should do as well. I think we really only
> talk about a single new scope here, namely the combination of compile and
> runtime, say "compile+runtime", "compile-plus-runtime" or <please insert
> your well tasting name for the new scope here> such that we provide plugins
> the following resolution scenarios:
>
> | compile | runtime | compile+runtime | test
> ---------+---------+---------+-----------------+--------
> system | X | | X | X
> provided | X | | X | X
> compile | X | X | X | X
> runtime | | X | X | X
> test | | | | X
>
> I'm currently not aware of use cases that would require additional
> combinations.
>
> Also, is there any potential conflict
>> between what is resolved based on scope? If so, allowing lists might
>> make that even more indeterminate.
>>
>
> I'm not sure what kind of conflict you had in mind, when I proposed a list
> of resolution scopes, I intended to logically OR them.
>
> To summarize, is something like
>
> @requiresDependencyResolution <our-new-super-cool-scope>
>
> a thing we all feel confident with? I.e. we would use the existing anno and
> plugins wanting to use the new resolution scope would simply bump their
> prerequisite on Maven.
>
>
If we are going to the trouble of adding new scopes... any chance we can add
a scope for integration testing at runtime (i.e. integration-test-time)
I am less sure on the need for a compile-integration-test scope, but I could
be pursuaded!
-Stephen
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [DISCUSS] Extend Mojo API to allow for resolution of multiple
dependency scopes
Posted by Benjamin Bentmann <be...@udo.edu>.
Brian Fox wrote:
> Perhaps what is needed is the addition of a
> few more "resolution scope" tags that a plugin could ask for. I mean,
> how many combinations aren't already covered by the existing scopes?
> If it's small and adding one or two more might be easier to support
> and maintain than allowing a list of them...
Sure, a new "resolution scope" should do as well. I think we really only
talk about a single new scope here, namely the combination of compile
and runtime, say "compile+runtime", "compile-plus-runtime" or <please
insert your well tasting name for the new scope here> such that we
provide plugins the following resolution scenarios:
| compile | runtime | compile+runtime | test
---------+---------+---------+-----------------+--------
system | X | | X | X
provided | X | | X | X
compile | X | X | X | X
runtime | | X | X | X
test | | | | X
I'm currently not aware of use cases that would require additional
combinations.
> Also, is there any potential conflict
> between what is resolved based on scope? If so, allowing lists might
> make that even more indeterminate.
I'm not sure what kind of conflict you had in mind, when I proposed a
list of resolution scopes, I intended to logically OR them.
To summarize, is something like
@requiresDependencyResolution <our-new-super-cool-scope>
a thing we all feel confident with? I.e. we would use the existing anno
and plugins wanting to use the new resolution scope would simply bump
their prerequisite on Maven.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Extend Mojo API to allow for resolution of multiple
dependency scopes
Posted by Brian Fox <br...@infinity.nu>.
I think the disconnect here is that the "resolution scope" != "specified scope"
That is to say if you ask for the runtime scope in a plugin, you get
more than things declared "runtime". We all know this intuitively but
it is confusing at times. Perhaps what is needed is the addition of a
few more "resolution scope" tags that a plugin could ask for. I mean,
how many combinations aren't already covered by the existing scopes?
If it's small and adding one or two more might be easier to support
and maintain than allowing a list of them...where many of the
artifacts in each list overlap. Also, is there any potential conflict
between what is resolved based on scope? If so, allowing lists might
make that even more indeterminate.
On Mon, Aug 3, 2009 at 5:02 AM, Benjamin
Bentmann<be...@udo.edu> wrote:
> Barrie Treloar wrote:
>
>> I cant remember if this is already raised somewhere else, but there is
>> similar problem with the scope "test".
>> test means both testCompile and testRuntime (which themselves dont
>> exist) so things like dependency:analyze reports errors because that
>> level of granularity does not exist.
>
> Reminds me of MDEP-152 and MDEP-146. Anyway, please let us keep this
> discussion focused on the original topic, otherwise I fear we won't get
> anywhere.
>
> My concern was to allow plugins to easily/efficiently enforce resolution of
> certain dependencies with the scopes that we have in place. Extending the
> scope system to distinguish between test-compile and test-runtime is another
> story.
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> 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: [DISCUSS] Extend Mojo API to allow for resolution of multiple
dependency scopes
Posted by Benjamin Bentmann <be...@udo.edu>.
Barrie Treloar wrote:
> I cant remember if this is already raised somewhere else, but there is
> similar problem with the scope "test".
> test means both testCompile and testRuntime (which themselves dont
> exist) so things like dependency:analyze reports errors because that
> level of granularity does not exist.
Reminds me of MDEP-152 and MDEP-146. Anyway, please let us keep this
discussion focused on the original topic, otherwise I fear we won't get
anywhere.
My concern was to allow plugins to easily/efficiently enforce resolution
of certain dependencies with the scopes that we have in place. Extending
the scope system to distinguish between test-compile and test-runtime is
another story.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Extend Mojo API to allow for resolution of multiple
dependency scopes
Posted by Barrie Treloar <ba...@gmail.com>.
On Mon, Aug 3, 2009 at 7:10 AM, Benjamin
Bentmann<be...@udo.edu> wrote:
> Brian Fox wrote:
>
>> In the dependency and enforcer plugins where I potentially need
>> everything, I just ask for test to be resolved and then i pick the
>> elements i need.
>
> Yeah, I know, the problem I described is not impossible to solve. All I
> wondered is whether this pattern does not give evidence of a design weakness
> in the core that we could fix.
I cant remember if this is already raised somewhere else, but there is
similar problem with the scope "test".
test means both testCompile and testRuntime (which themselves dont
exist) so things like dependency:analyze reports errors because that
level of granularity does not exist.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Extend Mojo API to allow for resolution of multiple
dependency scopes
Posted by Benjamin Bentmann <be...@udo.edu>.
Brian Fox wrote:
> In the dependency and enforcer plugins where I potentially need
> everything, I just ask for test to be resolved and then i pick the
> elements i need.
Yeah, I know, the problem I described is not impossible to solve. All I
wondered is whether this pattern does not give evidence of a design
weakness in the core that we could fix.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Extend Mojo API to allow for resolution of multiple
dependency scopes
Posted by Brian Fox <br...@infinity.nu>.
In the dependency and enforcer plugins where I potentially need
everything, I just ask for test to be resolved and then i pick the
elements i need.
On Sun, Aug 2, 2009 at 2:28 PM, Benjamin
Bentmann<be...@udo.edu> wrote:
> 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: 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: [DISCUSS] Extend Mojo API to allow for resolution of multiple
dependency scopes
Posted by Benjamin Bentmann <be...@udo.edu>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org