2009/8/3 Benjamin Bentmann
> 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 easi
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
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
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 no
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 wo
On Mon, Aug 3, 2009 at 7:10 AM, 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 s
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
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 wrote:
> Brian Fox wrote:
>
>> I think those bugs may be due to the plugin using the runtime scope
>
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 e
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 :
> Hi,
>
> I would like to propose an extension of the mojo annotation
>
> �...@requiresdependencyresolution
Hi,
I would like to propose an extension of the mojo annotation
@requiresDependencyResolution
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 superse
11 matches
Mail list logo