You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Benson Margulies <bi...@gmail.com> on 2015/12/12 22:04:47 UTC
I wish we had a way to declare a dependency that wouldn't participate
in the classpath
Sometimes, we want to declare a dependency without changing a classpath.
Project A builds an OSGi bundle and a Karaf feature (classifier
'feature', type 'xml').
Project B wants to consume the feature. it wants to declare the
feature descriptor as a dependency, to (a) ensure reactor order, and
(b) make the dependency information available to plugins.
But it does _not_ want A's OSGi bundle and it's dependencies in the classpath.
The only way out is to exclude them, one-by-one. And when someone adds
a dependency to A, you have to maintain the exclusion list.
Another example is the tomcat plugin: it needs wars as dependencies,
and similarly it needs to avoid having their dependencies in the
classpath.
To me, this calls out for another scope.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: I wish we had a way to declare a dependency that wouldn't
participate in the classpath
Posted by Andreas Gudian <an...@gmail.com>.
2015-12-13 19:04 GMT+01:00 Benson Margulies <bi...@gmail.com>:
> On Sun, Dec 13, 2015 at 9:40 AM, Benson Margulies <bi...@gmail.com>
> wrote:
> > On Dec 13, 2015 3:25 AM, "Stephen Connolly"
> > <st...@gmail.com> wrote:
> >>
> >> <type>pom</type>?
> >
> >
> > 1. The feature descriptor is <type>xml</type>
> >
> > 2. I believe that this still adds transitive dependencies to the
> dependency
> > graph.
>
> How about the following proposition: of the type is not jar, nothing
> goes onto the classpath? Not the thing, not its dependencies?
>
That sounds reasonable. Only stuff that _has_ a classpath should expose a
classpath.
>
> >
> >
> >
> >>
> >>
> >> On Saturday 12 December 2015, Benson Margulies <bi...@gmail.com>
> >> wrote:
> >>
> >> > Sometimes, we want to declare a dependency without changing a
> classpath.
> >> >
> >> > Project A builds an OSGi bundle and a Karaf feature (classifier
> >> > 'feature', type 'xml').
> >> >
> >> > Project B wants to consume the feature. it wants to declare the
> >> > feature descriptor as a dependency, to (a) ensure reactor order, and
> >> > (b) make the dependency information available to plugins.
> >> >
> >> > But it does _not_ want A's OSGi bundle and it's dependencies in the
> >> > classpath.
> >> >
> >> > The only way out is to exclude them, one-by-one. And when someone adds
> >> > a dependency to A, you have to maintain the exclusion list.
> >> >
> >> > Another example is the tomcat plugin: it needs wars as dependencies,
> >> > and similarly it needs to avoid having their dependencies in the
> >> > classpath.
> >> >
> >> > To me, this calls out for another scope.
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> <javascript:;>
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> > <javascript:;>
> >> >
> >> >
> >>
> >> --
> >> Sent from my phone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: I wish we had a way to declare a dependency that wouldn't
participate in the classpath
Posted by Benson Margulies <bi...@gmail.com>.
On Sun, Dec 13, 2015 at 9:40 AM, Benson Margulies <bi...@gmail.com> wrote:
> On Dec 13, 2015 3:25 AM, "Stephen Connolly"
> <st...@gmail.com> wrote:
>>
>> <type>pom</type>?
>
>
> 1. The feature descriptor is <type>xml</type>
>
> 2. I believe that this still adds transitive dependencies to the dependency
> graph.
How about the following proposition: of the type is not jar, nothing
goes onto the classpath? Not the thing, not its dependencies?
>
>
>
>>
>>
>> On Saturday 12 December 2015, Benson Margulies <bi...@gmail.com>
>> wrote:
>>
>> > Sometimes, we want to declare a dependency without changing a classpath.
>> >
>> > Project A builds an OSGi bundle and a Karaf feature (classifier
>> > 'feature', type 'xml').
>> >
>> > Project B wants to consume the feature. it wants to declare the
>> > feature descriptor as a dependency, to (a) ensure reactor order, and
>> > (b) make the dependency information available to plugins.
>> >
>> > But it does _not_ want A's OSGi bundle and it's dependencies in the
>> > classpath.
>> >
>> > The only way out is to exclude them, one-by-one. And when someone adds
>> > a dependency to A, you have to maintain the exclusion list.
>> >
>> > Another example is the tomcat plugin: it needs wars as dependencies,
>> > and similarly it needs to avoid having their dependencies in the
>> > classpath.
>> >
>> > To me, this calls out for another scope.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> > <javascript:;>
>> >
>> >
>>
>> --
>> Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: I wish we had a way to declare a dependency that wouldn't
participate in the classpath
Posted by Stephen Connolly <st...@gmail.com>.
When you specify type=pom you are depending on the pom which puts an
inter-project dependency (i.e. forces the reactor order) but does not put
on the classpath... at least from what I recall...
other than that you could create a custom packaging and say that the custom
packaging is not added to the classpath... it will still be a transitive
dependency...
so how about
type=pom, optional=true
that will force the reactor order but not affect the transitive dependency
tree
On 13 December 2015 at 14:40, Benson Margulies <bi...@gmail.com>
wrote:
> On Dec 13, 2015 3:25 AM, "Stephen Connolly" <
> stephen.alan.connolly@gmail.com>
> wrote:
>
> > <type>pom</type>?
> >
>
> 1. The feature descriptor is <type>xml</type>
>
> 2. I believe that this still adds transitive dependencies to the dependency
> graph.
>
>
>
>
> >
> > On Saturday 12 December 2015, Benson Margulies <bi...@gmail.com>
> > wrote:
> >
> > > Sometimes, we want to declare a dependency without changing a
> classpath.
> > >
> > > Project A builds an OSGi bundle and a Karaf feature (classifier
> > > 'feature', type 'xml').
> > >
> > > Project B wants to consume the feature. it wants to declare the
> > > feature descriptor as a dependency, to (a) ensure reactor order, and
> > > (b) make the dependency information available to plugins.
> > >
> > > But it does _not_ want A's OSGi bundle and it's dependencies in the
> > > classpath.
> > >
> > > The only way out is to exclude them, one-by-one. And when someone adds
> > > a dependency to A, you have to maintain the exclusion list.
> > >
> > > Another example is the tomcat plugin: it needs wars as dependencies,
> > > and similarly it needs to avoid having their dependencies in the
> > > classpath.
> > >
> > > To me, this calls out for another scope.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> <javascript:;>
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > <javascript:;>
> > >
> > >
> >
> > --
> > Sent from my phone
> >
>
Re: I wish we had a way to declare a dependency that wouldn't
participate in the classpath
Posted by Benson Margulies <bi...@gmail.com>.
On Dec 13, 2015 3:25 AM, "Stephen Connolly" <st...@gmail.com>
wrote:
> <type>pom</type>?
>
1. The feature descriptor is <type>xml</type>
2. I believe that this still adds transitive dependencies to the dependency
graph.
>
> On Saturday 12 December 2015, Benson Margulies <bi...@gmail.com>
> wrote:
>
> > Sometimes, we want to declare a dependency without changing a classpath.
> >
> > Project A builds an OSGi bundle and a Karaf feature (classifier
> > 'feature', type 'xml').
> >
> > Project B wants to consume the feature. it wants to declare the
> > feature descriptor as a dependency, to (a) ensure reactor order, and
> > (b) make the dependency information available to plugins.
> >
> > But it does _not_ want A's OSGi bundle and it's dependencies in the
> > classpath.
> >
> > The only way out is to exclude them, one-by-one. And when someone adds
> > a dependency to A, you have to maintain the exclusion list.
> >
> > Another example is the tomcat plugin: it needs wars as dependencies,
> > and similarly it needs to avoid having their dependencies in the
> > classpath.
> >
> > To me, this calls out for another scope.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> > For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> >
> >
>
> --
> Sent from my phone
>
Re: I wish we had a way to declare a dependency that wouldn't
participate in the classpath
Posted by Stephen Connolly <st...@gmail.com>.
<type>pom</type>?
On Saturday 12 December 2015, Benson Margulies <bi...@gmail.com>
wrote:
> Sometimes, we want to declare a dependency without changing a classpath.
>
> Project A builds an OSGi bundle and a Karaf feature (classifier
> 'feature', type 'xml').
>
> Project B wants to consume the feature. it wants to declare the
> feature descriptor as a dependency, to (a) ensure reactor order, and
> (b) make the dependency information available to plugins.
>
> But it does _not_ want A's OSGi bundle and it's dependencies in the
> classpath.
>
> The only way out is to exclude them, one-by-one. And when someone adds
> a dependency to A, you have to maintain the exclusion list.
>
> Another example is the tomcat plugin: it needs wars as dependencies,
> and similarly it needs to avoid having their dependencies in the
> classpath.
>
> To me, this calls out for another scope.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>
--
Sent from my phone
Re: I wish we had a way to declare a dependency that wouldn't
participate in the classpath
Posted by Benson Margulies <bi...@gmail.com>.
On Sun, Dec 13, 2015 at 3:59 PM, Robert Scholte <rf...@apache.org> wrote:
> Op Sun, 13 Dec 2015 21:23:16 +0100 schreef Andreas Gudian
> <an...@gmail.com>:
>
>
>> 2015-12-13 12:05 GMT+01:00 Robert Scholte <rf...@apache.org>:
>>
>>> The first time I heard about JDK9s Jigsaw having a classpath and a
>>> modulepath, which can be used at the same time AND both containing jars,
>>> I
>>> had a big "OH NO....!". We can't change the pom, so the first thing that
>>> came to my mind was indeed using the scope for this. But that'll have a
>>> huge impact: if jars need to be used at compile time but don't have that
>>> scope, what will happen with transitive resolution for example?
>>> I had a small talk with Alan, Mark and Alexander of the Jigsaw team about
>>> this. You could say that this is a new specification of a jar which asks
>>> for a different file-extension. They said that the jar file specification
>>> was extended. I said that we can't expect from users to know what kind of
>>> jar it is. Also, buildtools shouldn't pay the price for analyzing the jar
>>> to discover if it has a module-info or not. Mark immediately answered
>>> that
>>> they should take care of it.
>>> Now that I'm working on the maven-compiler-plugin it looks like it won't
>>> be a compile time issue. However, depending on our approach it might be
>>> an
>>> issue for Surefire.
>>> So yes: I recognize the situation. Dependencies are all very classpath
>>> oriented assuming that a specific type is always used in the same way.
>>>
>>> That's why I want to drop the strict scopes for plugins. Best example is
>>> the maven-javadoc-plugin where you can add jars for bootclasspath,
>>> doclets,
>>> resources, taglets. My idea: don't add these dependencies as
>>> configuration
>>> elements, but as standard plugin dependencies with there own scope. And
>>> since there dependencies are specific for this plugin, it can choose any
>>> scope it likes and select them within its own Mojo code.
>>>
>>
>> But I would guess such specially scoped dependencies still show up on the
>> classpath of the plugin itself, right? For example, right now I'm looking
>> into MCOMPILE-203 which is about configuring the -processorpath option of
>> javac. Right now I have it working locally with a new
>> configuration-element. Using a special scope in the plugin-dependency
>> would, currently, mean polluting the plugins classpath - which wouldn't be
>> that ideal.
>>
>> Or are plugin-dependencies with funky scopes already filtered out right
>> now?
>>
>
> I would expect that for plugins only the compile and runtime scoped
> dependencies are used as their whitelist.
> Not sure what will happen with unknown scopes, but it it works then it is
> quite hard to get those dependencies (maybe including their transitive ones)
> IMO it is Maven which is responsible for resolving dependencies, and not the
> plugin with its own configuration.
The idea that I would write in a JIRA, if it passed a certain level of
plausibility-testing here, is this:
When the compile plugin and the surefire plugin (main examples) are
building classpaths, they should prune at type!=jar. No change to the
dependency tree, only to the management of classpaths by the plugins
that, well, manage classpaths. They could have options to change this
behavior in case someone really wants a war file in the classpath for
some reason, but that should not be default behavior. No need, in this
schema, to add a scope.
>
> Robert
>
>
>>>
>>> For plugins such a change is easy, but within the scope of the pom that's
>>> hard.
>>>
>>> Robert
>>>
>>>
>>> Op Sat, 12 Dec 2015 22:04:47 +0100 schreef Benson Margulies <
>>> bimargulies@gmail.com>:
>>>
>>>
>>> Sometimes, we want to declare a dependency without changing a classpath.
>>>>
>>>>
>>>> Project A builds an OSGi bundle and a Karaf feature (classifier
>>>> 'feature', type 'xml').
>>>>
>>>> Project B wants to consume the feature. it wants to declare the
>>>> feature descriptor as a dependency, to (a) ensure reactor order, and
>>>> (b) make the dependency information available to plugins.
>>>>
>>>> But it does _not_ want A's OSGi bundle and it's dependencies in the
>>>> classpath.
>>>>
>>>> The only way out is to exclude them, one-by-one. And when someone adds
>>>> a dependency to A, you have to maintain the exclusion list.
>>>>
>>>> Another example is the tomcat plugin: it needs wars as dependencies,
>>>> and similarly it needs to avoid having their dependencies in the
>>>> classpath.
>>>>
>>>> To me, this calls out for another scope.
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>
> ---------------------------------------------------------------------
> 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: I wish we had a way to declare a dependency that wouldn't
participate in the classpath
Posted by Robert Scholte <rf...@apache.org>.
Op Sun, 13 Dec 2015 21:23:16 +0100 schreef Andreas Gudian
<an...@gmail.com>:
> 2015-12-13 12:05 GMT+01:00 Robert Scholte <rf...@apache.org>:
>
>> The first time I heard about JDK9s Jigsaw having a classpath and a
>> modulepath, which can be used at the same time AND both containing
>> jars, I
>> had a big "OH NO....!". We can't change the pom, so the first thing that
>> came to my mind was indeed using the scope for this. But that'll have a
>> huge impact: if jars need to be used at compile time but don't have that
>> scope, what will happen with transitive resolution for example?
>> I had a small talk with Alan, Mark and Alexander of the Jigsaw team
>> about
>> this. You could say that this is a new specification of a jar which asks
>> for a different file-extension. They said that the jar file
>> specification
>> was extended. I said that we can't expect from users to know what kind
>> of
>> jar it is. Also, buildtools shouldn't pay the price for analyzing the
>> jar
>> to discover if it has a module-info or not. Mark immediately answered
>> that
>> they should take care of it.
>> Now that I'm working on the maven-compiler-plugin it looks like it won't
>> be a compile time issue. However, depending on our approach it might be
>> an
>> issue for Surefire.
>> So yes: I recognize the situation. Dependencies are all very classpath
>> oriented assuming that a specific type is always used in the same way.
>>
>> That's why I want to drop the strict scopes for plugins. Best example is
>> the maven-javadoc-plugin where you can add jars for bootclasspath,
>> doclets,
>> resources, taglets. My idea: don't add these dependencies as
>> configuration
>> elements, but as standard plugin dependencies with there own scope. And
>> since there dependencies are specific for this plugin, it can choose any
>> scope it likes and select them within its own Mojo code.
>>
>
> But I would guess such specially scoped dependencies still show up on the
> classpath of the plugin itself, right? For example, right now I'm looking
> into MCOMPILE-203 which is about configuring the -processorpath option of
> javac. Right now I have it working locally with a new
> configuration-element. Using a special scope in the plugin-dependency
> would, currently, mean polluting the plugins classpath - which wouldn't
> be
> that ideal.
>
> Or are plugin-dependencies with funky scopes already filtered out right
> now?
>
I would expect that for plugins only the compile and runtime scoped
dependencies are used as their whitelist.
Not sure what will happen with unknown scopes, but it it works then it is
quite hard to get those dependencies (maybe including their transitive
ones)
IMO it is Maven which is responsible for resolving dependencies, and not
the plugin with its own configuration.
Robert
>>
>> For plugins such a change is easy, but within the scope of the pom
>> that's
>> hard.
>>
>> Robert
>>
>>
>> Op Sat, 12 Dec 2015 22:04:47 +0100 schreef Benson Margulies <
>> bimargulies@gmail.com>:
>>
>>
>> Sometimes, we want to declare a dependency without changing a classpath.
>>>
>>> Project A builds an OSGi bundle and a Karaf feature (classifier
>>> 'feature', type 'xml').
>>>
>>> Project B wants to consume the feature. it wants to declare the
>>> feature descriptor as a dependency, to (a) ensure reactor order, and
>>> (b) make the dependency information available to plugins.
>>>
>>> But it does _not_ want A's OSGi bundle and it's dependencies in the
>>> classpath.
>>>
>>> The only way out is to exclude them, one-by-one. And when someone adds
>>> a dependency to A, you have to maintain the exclusion list.
>>>
>>> Another example is the tomcat plugin: it needs wars as dependencies,
>>> and similarly it needs to avoid having their dependencies in the
>>> classpath.
>>>
>>> To me, this calls out for another scope.
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: I wish we had a way to declare a dependency that wouldn't
participate in the classpath
Posted by Andreas Gudian <an...@gmail.com>.
2015-12-13 12:05 GMT+01:00 Robert Scholte <rf...@apache.org>:
> The first time I heard about JDK9s Jigsaw having a classpath and a
> modulepath, which can be used at the same time AND both containing jars, I
> had a big "OH NO....!". We can't change the pom, so the first thing that
> came to my mind was indeed using the scope for this. But that'll have a
> huge impact: if jars need to be used at compile time but don't have that
> scope, what will happen with transitive resolution for example?
> I had a small talk with Alan, Mark and Alexander of the Jigsaw team about
> this. You could say that this is a new specification of a jar which asks
> for a different file-extension. They said that the jar file specification
> was extended. I said that we can't expect from users to know what kind of
> jar it is. Also, buildtools shouldn't pay the price for analyzing the jar
> to discover if it has a module-info or not. Mark immediately answered that
> they should take care of it.
> Now that I'm working on the maven-compiler-plugin it looks like it won't
> be a compile time issue. However, depending on our approach it might be an
> issue for Surefire.
> So yes: I recognize the situation. Dependencies are all very classpath
> oriented assuming that a specific type is always used in the same way.
>
> That's why I want to drop the strict scopes for plugins. Best example is
> the maven-javadoc-plugin where you can add jars for bootclasspath, doclets,
> resources, taglets. My idea: don't add these dependencies as configuration
> elements, but as standard plugin dependencies with there own scope. And
> since there dependencies are specific for this plugin, it can choose any
> scope it likes and select them within its own Mojo code.
>
But I would guess such specially scoped dependencies still show up on the
classpath of the plugin itself, right? For example, right now I'm looking
into MCOMPILE-203 which is about configuring the -processorpath option of
javac. Right now I have it working locally with a new
configuration-element. Using a special scope in the plugin-dependency
would, currently, mean polluting the plugins classpath - which wouldn't be
that ideal.
Or are plugin-dependencies with funky scopes already filtered out right now?
>
> For plugins such a change is easy, but within the scope of the pom that's
> hard.
>
> Robert
>
>
> Op Sat, 12 Dec 2015 22:04:47 +0100 schreef Benson Margulies <
> bimargulies@gmail.com>:
>
>
> Sometimes, we want to declare a dependency without changing a classpath.
>>
>> Project A builds an OSGi bundle and a Karaf feature (classifier
>> 'feature', type 'xml').
>>
>> Project B wants to consume the feature. it wants to declare the
>> feature descriptor as a dependency, to (a) ensure reactor order, and
>> (b) make the dependency information available to plugins.
>>
>> But it does _not_ want A's OSGi bundle and it's dependencies in the
>> classpath.
>>
>> The only way out is to exclude them, one-by-one. And when someone adds
>> a dependency to A, you have to maintain the exclusion list.
>>
>> Another example is the tomcat plugin: it needs wars as dependencies,
>> and similarly it needs to avoid having their dependencies in the
>> classpath.
>>
>> To me, this calls out for another scope.
>>
>> ---------------------------------------------------------------------
>> 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: I wish we had a way to declare a dependency that wouldn't
participate in the classpath
Posted by Robert Scholte <rf...@apache.org>.
The first time I heard about JDK9s Jigsaw having a classpath and a
modulepath, which can be used at the same time AND both containing jars, I
had a big "OH NO....!". We can't change the pom, so the first thing that
came to my mind was indeed using the scope for this. But that'll have a
huge impact: if jars need to be used at compile time but don't have that
scope, what will happen with transitive resolution for example?
I had a small talk with Alan, Mark and Alexander of the Jigsaw team about
this. You could say that this is a new specification of a jar which asks
for a different file-extension. They said that the jar file specification
was extended. I said that we can't expect from users to know what kind of
jar it is. Also, buildtools shouldn't pay the price for analyzing the jar
to discover if it has a module-info or not. Mark immediately answered that
they should take care of it.
Now that I'm working on the maven-compiler-plugin it looks like it won't
be a compile time issue. However, depending on our approach it might be an
issue for Surefire.
So yes: I recognize the situation. Dependencies are all very classpath
oriented assuming that a specific type is always used in the same way.
That's why I want to drop the strict scopes for plugins. Best example is
the maven-javadoc-plugin where you can add jars for bootclasspath,
doclets, resources, taglets. My idea: don't add these dependencies as
configuration elements, but as standard plugin dependencies with there own
scope. And since there dependencies are specific for this plugin, it can
choose any scope it likes and select them within its own Mojo code.
For plugins such a change is easy, but within the scope of the pom that's
hard.
Robert
Op Sat, 12 Dec 2015 22:04:47 +0100 schreef Benson Margulies
<bi...@gmail.com>:
> Sometimes, we want to declare a dependency without changing a classpath.
>
> Project A builds an OSGi bundle and a Karaf feature (classifier
> 'feature', type 'xml').
>
> Project B wants to consume the feature. it wants to declare the
> feature descriptor as a dependency, to (a) ensure reactor order, and
> (b) make the dependency information available to plugins.
>
> But it does _not_ want A's OSGi bundle and it's dependencies in the
> classpath.
>
> The only way out is to exclude them, one-by-one. And when someone adds
> a dependency to A, you have to maintain the exclusion list.
>
> Another example is the tomcat plugin: it needs wars as dependencies,
> and similarly it needs to avoid having their dependencies in the
> classpath.
>
> To me, this calls out for another scope.
>
> ---------------------------------------------------------------------
> 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