You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Francesco Mari <ma...@gmail.com> on 2013/07/30 14:22:39 UTC
Rationale behind non-standard dependency scopes
Hi,
I was wondering why using custom dependency scopes issues a warning
when the POM model is validated. Why Maven just don't ignore dependecy
scopes he cannot understand?
I was thinking to treat dependency scopes in a different way. The only
logic I've found about dependency scopes is in [1] and [2] (I'm pretty
sure there is more around), respectively how dependency scope
inheritance is computed and whether to import POM dependencies with
scope "import".
Can this logic be encapsulated in a component which is able to track
other optional "dependency scope" components? Each "dependency scope"
component will define a new dependency scope and will encapsulate the
rules about it (i.e. what happens if a dependency of the given scope
is inherited, if it can be imported, and so on).
An alternative and simpler solution could be that a "dependency scope"
component maps a custom dependency scope to one standard scope defined
by Maven, so to establish an "is-a" relationship between a custom
dependency scope and a standard one.
What do you think?
[1]: https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java#L351
[2]: https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L876
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Rationale behind non-standard dependency scopes
Posted by Arnaud Héritier <ah...@gmail.com>.
AFAIR In Maven 2.x it was possible to put anything in scopes and it was
very error prone because any unknown scope was silently transformed into
compile scope
In 3.x the choice was done to strictly check the scope with ones known by
Maven.
I agree that an API to declare new scope using extensions may be a good
thing but the problem we'll have to take care of the behavior to load such
extension when maven find such unknown scope and how old versions will
manage them.
On Tue, Jul 30, 2013 at 2:22 PM, Francesco Mari <ma...@gmail.com>wrote:
> Hi,
>
> I was wondering why using custom dependency scopes issues a warning
> when the POM model is validated. Why Maven just don't ignore dependecy
> scopes he cannot understand?
>
> I was thinking to treat dependency scopes in a different way. The only
> logic I've found about dependency scopes is in [1] and [2] (I'm pretty
> sure there is more around), respectively how dependency scope
> inheritance is computed and whether to import POM dependencies with
> scope "import".
>
> Can this logic be encapsulated in a component which is able to track
> other optional "dependency scope" components? Each "dependency scope"
> component will define a new dependency scope and will encapsulate the
> rules about it (i.e. what happens if a dependency of the given scope
> is inherited, if it can be imported, and so on).
>
> An alternative and simpler solution could be that a "dependency scope"
> component maps a custom dependency scope to one standard scope defined
> by Maven, so to establish an "is-a" relationship between a custom
> dependency scope and a standard one.
>
> What do you think?
>
> [1]:
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java#L351
> [2]:
> https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L876
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier
Re: Rationale behind non-standard dependency scopes
Posted by Francesco Mari <ma...@gmail.com>.
I agree with your point of view, I fiind it reasonable and could solve
my problem (and each other problem of the same kind).
Do you know if there is an improvement issue in Jira? If there is
none, can I open such an issue describing the desired solution in
general terms?
2013/7/30 Stephen Connolly <st...@gmail.com>:
> Yeah, I think that is probably something that will need to be addressed in
> a future pom format... something along the line of dependency attributes or
> markers that can then be used by specific plugins to pull out sections of
> dependencies.
>
> Scope should not be abused for what is really a marker question for
> plugins, IMHO
>
>
> On 30 July 2013 15:39, Francesco Mari <ma...@gmail.com> wrote:
>
>> Correct. I don't want to duplicate the configuration twice, the first
>> time in my plugin and the second time in the <dependencies> section to
>> let Maven correctly compute the build plan.
>>
>> 2013/7/30 Stephen Connolly <st...@gmail.com>:
>> > On 30 July 2013 14:23, Francesco Mari <ma...@gmail.com> wrote:
>> >
>> >> I missed to describe my use case. I will try to do it as detailed as I
>> >> can, but it can be quite verbose.
>> >>
>> >> I have a project which is built by aggregating other artifacts with
>> >> different roles: runtime OSGi bundles, plain content, testing OSGi
>> >> bundles, integration testing modules. You can't build this project
>> >> with executions of existing plugins (trust me, we tried), so a new
>> >> plugin has been written to handle the corner cases of the packaging
>> >> required by the project. The project is usually deployed as a runnable
>> >> JAR file and a .properties file containing metadata which cannot be
>> >> contained in a POM file.
>> >>
>> >> The packaging plugin contains a LifecycleParticipant as an extension,
>> >> and dependencies are automatically added on the project depending on
>> >> the configuration of the plugin. As you can imagine, the code of the
>> >> LifecycleParticipant is messy, as it tries to scan projects, plugins
>> >> and configurations to figure out what to use as dependencies of the
>> >> project. This is done for two reasons. First, the project is inside an
>> >> aggregator with the bundles it depends on, so it must be built after
>> >> its dependencies are built. Second, we often inspect dependencies of
>> >> our projects using the Maven Dependency Plugin or the Versions Maven
>> >> Plugin and we would like to have tooling support.
>> >>
>> >> The pure and correct solution would be to duplicate the same
>> >> information I have in the configuration of the plugin and to copy it
>> >> in the dependencies section of the POM. This will satisfy my
>> >> requirements, but will make the configuration of the build too
>> >> verbose.
>> >>
>> >> If I had custom dependency scopes like "runtime-bundle",
>> >> "testing-bundle", "content", etc. I could be able to still use the
>> >> dependency mechanism of Maven, let Maven assemble the POM model as
>> >> usual, parse the configuration and configure my plugin, instead of
>> >> doing it in my LifecycleParticipant, which is tedious and error prone
>> >> (other than duplicated logic). I could write my plugin to scan the
>> >> dependencies for custom scopes, instead of relying on the
>> >> configuration only.
>> >>
>> >> Do you have better ideas for this problem?
>> >>
>> >>
>> > So really this is a question of build-time information. The "exported"
>> > transitive dependencies will fit neatly into the existing scopes, but you
>> > would like a simplified *build time* configuration?
>> >
>> >
>> >> 2013/7/30 Stephen Connolly <st...@gmail.com>:
>> >> > I find the lure of the custom scopes to be a siren's call.
>> >> >
>> >> > There are maybe 2-3 "missing" scopes. all other needs are better
>> >> addressed
>> >> > with a different project structure in my view.
>> >> >
>> >> > We have the separation between test and non-test... but test is an
>> all or
>> >> > nothing... need the symmetry between the non-test scopes and the test
>> >> > scopes, e.g.
>> >> >
>> >> > compile -> test-compile
>> >> > runtime -> test-runtime
>> >> >
>> >> > I'd also want a "none" scope so that things like the maven dependency
>> and
>> >> > assembly plugins can reference project dependencies without polluting
>> >> > compile classpaths.
>> >> >
>> >> > of course the real issue that the above masks is that unit tests
>> should
>> >> not
>> >> > be using such tricks... and integration tests should be in a separate
>> >> > module, but we need the integration tests failing to block the module
>> >> that
>> >> > they are testing from being built.
>> >> >
>> >> > What is also needed is a way to signify architecturally specific
>> >> artifacts,
>> >> > and also a way to signify that artifact A subsumes or provides an
>> >> > equivalent API to artifact B so that when A is on the classpath, B is
>> >> > automatically excluded from transitive dependencies.
>> >> >
>> >> > But what I'd really like to understand is what you think you need
>> these
>> >> > custom scopes for... because perhaps I am being arrogant and assuming
>> I
>> >> > have thought of all the valid use cases and you can show me the error
>> of
>> >> my
>> >> > thinking
>> >> >
>> >> > -Stephen
>> >> >
>> >> >
>> >> > On 30 July 2013 13:22, Francesco Mari <ma...@gmail.com>
>> wrote:
>> >> >
>> >> >> Hi,
>> >> >>
>> >> >> I was wondering why using custom dependency scopes issues a warning
>> >> >> when the POM model is validated. Why Maven just don't ignore
>> dependecy
>> >> >> scopes he cannot understand?
>> >> >>
>> >> >> I was thinking to treat dependency scopes in a different way. The
>> only
>> >> >> logic I've found about dependency scopes is in [1] and [2] (I'm
>> pretty
>> >> >> sure there is more around), respectively how dependency scope
>> >> >> inheritance is computed and whether to import POM dependencies with
>> >> >> scope "import".
>> >> >>
>> >> >> Can this logic be encapsulated in a component which is able to track
>> >> >> other optional "dependency scope" components? Each "dependency scope"
>> >> >> component will define a new dependency scope and will encapsulate the
>> >> >> rules about it (i.e. what happens if a dependency of the given scope
>> >> >> is inherited, if it can be imported, and so on).
>> >> >>
>> >> >> An alternative and simpler solution could be that a "dependency
>> scope"
>> >> >> component maps a custom dependency scope to one standard scope
>> defined
>> >> >> by Maven, so to establish an "is-a" relationship between a custom
>> >> >> dependency scope and a standard one.
>> >> >>
>> >> >> What do you think?
>> >> >>
>> >> >> [1]:
>> >> >>
>> >>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java#L351
>> >> >> [2]:
>> >> >>
>> >>
>> https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L876
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> 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: Rationale behind non-standard dependency scopes
Posted by Stephen Connolly <st...@gmail.com>.
Yeah, I think that is probably something that will need to be addressed in
a future pom format... something along the line of dependency attributes or
markers that can then be used by specific plugins to pull out sections of
dependencies.
Scope should not be abused for what is really a marker question for
plugins, IMHO
On 30 July 2013 15:39, Francesco Mari <ma...@gmail.com> wrote:
> Correct. I don't want to duplicate the configuration twice, the first
> time in my plugin and the second time in the <dependencies> section to
> let Maven correctly compute the build plan.
>
> 2013/7/30 Stephen Connolly <st...@gmail.com>:
> > On 30 July 2013 14:23, Francesco Mari <ma...@gmail.com> wrote:
> >
> >> I missed to describe my use case. I will try to do it as detailed as I
> >> can, but it can be quite verbose.
> >>
> >> I have a project which is built by aggregating other artifacts with
> >> different roles: runtime OSGi bundles, plain content, testing OSGi
> >> bundles, integration testing modules. You can't build this project
> >> with executions of existing plugins (trust me, we tried), so a new
> >> plugin has been written to handle the corner cases of the packaging
> >> required by the project. The project is usually deployed as a runnable
> >> JAR file and a .properties file containing metadata which cannot be
> >> contained in a POM file.
> >>
> >> The packaging plugin contains a LifecycleParticipant as an extension,
> >> and dependencies are automatically added on the project depending on
> >> the configuration of the plugin. As you can imagine, the code of the
> >> LifecycleParticipant is messy, as it tries to scan projects, plugins
> >> and configurations to figure out what to use as dependencies of the
> >> project. This is done for two reasons. First, the project is inside an
> >> aggregator with the bundles it depends on, so it must be built after
> >> its dependencies are built. Second, we often inspect dependencies of
> >> our projects using the Maven Dependency Plugin or the Versions Maven
> >> Plugin and we would like to have tooling support.
> >>
> >> The pure and correct solution would be to duplicate the same
> >> information I have in the configuration of the plugin and to copy it
> >> in the dependencies section of the POM. This will satisfy my
> >> requirements, but will make the configuration of the build too
> >> verbose.
> >>
> >> If I had custom dependency scopes like "runtime-bundle",
> >> "testing-bundle", "content", etc. I could be able to still use the
> >> dependency mechanism of Maven, let Maven assemble the POM model as
> >> usual, parse the configuration and configure my plugin, instead of
> >> doing it in my LifecycleParticipant, which is tedious and error prone
> >> (other than duplicated logic). I could write my plugin to scan the
> >> dependencies for custom scopes, instead of relying on the
> >> configuration only.
> >>
> >> Do you have better ideas for this problem?
> >>
> >>
> > So really this is a question of build-time information. The "exported"
> > transitive dependencies will fit neatly into the existing scopes, but you
> > would like a simplified *build time* configuration?
> >
> >
> >> 2013/7/30 Stephen Connolly <st...@gmail.com>:
> >> > I find the lure of the custom scopes to be a siren's call.
> >> >
> >> > There are maybe 2-3 "missing" scopes. all other needs are better
> >> addressed
> >> > with a different project structure in my view.
> >> >
> >> > We have the separation between test and non-test... but test is an
> all or
> >> > nothing... need the symmetry between the non-test scopes and the test
> >> > scopes, e.g.
> >> >
> >> > compile -> test-compile
> >> > runtime -> test-runtime
> >> >
> >> > I'd also want a "none" scope so that things like the maven dependency
> and
> >> > assembly plugins can reference project dependencies without polluting
> >> > compile classpaths.
> >> >
> >> > of course the real issue that the above masks is that unit tests
> should
> >> not
> >> > be using such tricks... and integration tests should be in a separate
> >> > module, but we need the integration tests failing to block the module
> >> that
> >> > they are testing from being built.
> >> >
> >> > What is also needed is a way to signify architecturally specific
> >> artifacts,
> >> > and also a way to signify that artifact A subsumes or provides an
> >> > equivalent API to artifact B so that when A is on the classpath, B is
> >> > automatically excluded from transitive dependencies.
> >> >
> >> > But what I'd really like to understand is what you think you need
> these
> >> > custom scopes for... because perhaps I am being arrogant and assuming
> I
> >> > have thought of all the valid use cases and you can show me the error
> of
> >> my
> >> > thinking
> >> >
> >> > -Stephen
> >> >
> >> >
> >> > On 30 July 2013 13:22, Francesco Mari <ma...@gmail.com>
> wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> I was wondering why using custom dependency scopes issues a warning
> >> >> when the POM model is validated. Why Maven just don't ignore
> dependecy
> >> >> scopes he cannot understand?
> >> >>
> >> >> I was thinking to treat dependency scopes in a different way. The
> only
> >> >> logic I've found about dependency scopes is in [1] and [2] (I'm
> pretty
> >> >> sure there is more around), respectively how dependency scope
> >> >> inheritance is computed and whether to import POM dependencies with
> >> >> scope "import".
> >> >>
> >> >> Can this logic be encapsulated in a component which is able to track
> >> >> other optional "dependency scope" components? Each "dependency scope"
> >> >> component will define a new dependency scope and will encapsulate the
> >> >> rules about it (i.e. what happens if a dependency of the given scope
> >> >> is inherited, if it can be imported, and so on).
> >> >>
> >> >> An alternative and simpler solution could be that a "dependency
> scope"
> >> >> component maps a custom dependency scope to one standard scope
> defined
> >> >> by Maven, so to establish an "is-a" relationship between a custom
> >> >> dependency scope and a standard one.
> >> >>
> >> >> What do you think?
> >> >>
> >> >> [1]:
> >> >>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java#L351
> >> >> [2]:
> >> >>
> >>
> https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L876
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> 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: Rationale behind non-standard dependency scopes
Posted by Francesco Mari <ma...@gmail.com>.
Correct. I don't want to duplicate the configuration twice, the first
time in my plugin and the second time in the <dependencies> section to
let Maven correctly compute the build plan.
2013/7/30 Stephen Connolly <st...@gmail.com>:
> On 30 July 2013 14:23, Francesco Mari <ma...@gmail.com> wrote:
>
>> I missed to describe my use case. I will try to do it as detailed as I
>> can, but it can be quite verbose.
>>
>> I have a project which is built by aggregating other artifacts with
>> different roles: runtime OSGi bundles, plain content, testing OSGi
>> bundles, integration testing modules. You can't build this project
>> with executions of existing plugins (trust me, we tried), so a new
>> plugin has been written to handle the corner cases of the packaging
>> required by the project. The project is usually deployed as a runnable
>> JAR file and a .properties file containing metadata which cannot be
>> contained in a POM file.
>>
>> The packaging plugin contains a LifecycleParticipant as an extension,
>> and dependencies are automatically added on the project depending on
>> the configuration of the plugin. As you can imagine, the code of the
>> LifecycleParticipant is messy, as it tries to scan projects, plugins
>> and configurations to figure out what to use as dependencies of the
>> project. This is done for two reasons. First, the project is inside an
>> aggregator with the bundles it depends on, so it must be built after
>> its dependencies are built. Second, we often inspect dependencies of
>> our projects using the Maven Dependency Plugin or the Versions Maven
>> Plugin and we would like to have tooling support.
>>
>> The pure and correct solution would be to duplicate the same
>> information I have in the configuration of the plugin and to copy it
>> in the dependencies section of the POM. This will satisfy my
>> requirements, but will make the configuration of the build too
>> verbose.
>>
>> If I had custom dependency scopes like "runtime-bundle",
>> "testing-bundle", "content", etc. I could be able to still use the
>> dependency mechanism of Maven, let Maven assemble the POM model as
>> usual, parse the configuration and configure my plugin, instead of
>> doing it in my LifecycleParticipant, which is tedious and error prone
>> (other than duplicated logic). I could write my plugin to scan the
>> dependencies for custom scopes, instead of relying on the
>> configuration only.
>>
>> Do you have better ideas for this problem?
>>
>>
> So really this is a question of build-time information. The "exported"
> transitive dependencies will fit neatly into the existing scopes, but you
> would like a simplified *build time* configuration?
>
>
>> 2013/7/30 Stephen Connolly <st...@gmail.com>:
>> > I find the lure of the custom scopes to be a siren's call.
>> >
>> > There are maybe 2-3 "missing" scopes. all other needs are better
>> addressed
>> > with a different project structure in my view.
>> >
>> > We have the separation between test and non-test... but test is an all or
>> > nothing... need the symmetry between the non-test scopes and the test
>> > scopes, e.g.
>> >
>> > compile -> test-compile
>> > runtime -> test-runtime
>> >
>> > I'd also want a "none" scope so that things like the maven dependency and
>> > assembly plugins can reference project dependencies without polluting
>> > compile classpaths.
>> >
>> > of course the real issue that the above masks is that unit tests should
>> not
>> > be using such tricks... and integration tests should be in a separate
>> > module, but we need the integration tests failing to block the module
>> that
>> > they are testing from being built.
>> >
>> > What is also needed is a way to signify architecturally specific
>> artifacts,
>> > and also a way to signify that artifact A subsumes or provides an
>> > equivalent API to artifact B so that when A is on the classpath, B is
>> > automatically excluded from transitive dependencies.
>> >
>> > But what I'd really like to understand is what you think you need these
>> > custom scopes for... because perhaps I am being arrogant and assuming I
>> > have thought of all the valid use cases and you can show me the error of
>> my
>> > thinking
>> >
>> > -Stephen
>> >
>> >
>> > On 30 July 2013 13:22, Francesco Mari <ma...@gmail.com> wrote:
>> >
>> >> Hi,
>> >>
>> >> I was wondering why using custom dependency scopes issues a warning
>> >> when the POM model is validated. Why Maven just don't ignore dependecy
>> >> scopes he cannot understand?
>> >>
>> >> I was thinking to treat dependency scopes in a different way. The only
>> >> logic I've found about dependency scopes is in [1] and [2] (I'm pretty
>> >> sure there is more around), respectively how dependency scope
>> >> inheritance is computed and whether to import POM dependencies with
>> >> scope "import".
>> >>
>> >> Can this logic be encapsulated in a component which is able to track
>> >> other optional "dependency scope" components? Each "dependency scope"
>> >> component will define a new dependency scope and will encapsulate the
>> >> rules about it (i.e. what happens if a dependency of the given scope
>> >> is inherited, if it can be imported, and so on).
>> >>
>> >> An alternative and simpler solution could be that a "dependency scope"
>> >> component maps a custom dependency scope to one standard scope defined
>> >> by Maven, so to establish an "is-a" relationship between a custom
>> >> dependency scope and a standard one.
>> >>
>> >> What do you think?
>> >>
>> >> [1]:
>> >>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java#L351
>> >> [2]:
>> >>
>> https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L876
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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: Rationale behind non-standard dependency scopes
Posted by Stephen Connolly <st...@gmail.com>.
On 30 July 2013 14:23, Francesco Mari <ma...@gmail.com> wrote:
> I missed to describe my use case. I will try to do it as detailed as I
> can, but it can be quite verbose.
>
> I have a project which is built by aggregating other artifacts with
> different roles: runtime OSGi bundles, plain content, testing OSGi
> bundles, integration testing modules. You can't build this project
> with executions of existing plugins (trust me, we tried), so a new
> plugin has been written to handle the corner cases of the packaging
> required by the project. The project is usually deployed as a runnable
> JAR file and a .properties file containing metadata which cannot be
> contained in a POM file.
>
> The packaging plugin contains a LifecycleParticipant as an extension,
> and dependencies are automatically added on the project depending on
> the configuration of the plugin. As you can imagine, the code of the
> LifecycleParticipant is messy, as it tries to scan projects, plugins
> and configurations to figure out what to use as dependencies of the
> project. This is done for two reasons. First, the project is inside an
> aggregator with the bundles it depends on, so it must be built after
> its dependencies are built. Second, we often inspect dependencies of
> our projects using the Maven Dependency Plugin or the Versions Maven
> Plugin and we would like to have tooling support.
>
> The pure and correct solution would be to duplicate the same
> information I have in the configuration of the plugin and to copy it
> in the dependencies section of the POM. This will satisfy my
> requirements, but will make the configuration of the build too
> verbose.
>
> If I had custom dependency scopes like "runtime-bundle",
> "testing-bundle", "content", etc. I could be able to still use the
> dependency mechanism of Maven, let Maven assemble the POM model as
> usual, parse the configuration and configure my plugin, instead of
> doing it in my LifecycleParticipant, which is tedious and error prone
> (other than duplicated logic). I could write my plugin to scan the
> dependencies for custom scopes, instead of relying on the
> configuration only.
>
> Do you have better ideas for this problem?
>
>
So really this is a question of build-time information. The "exported"
transitive dependencies will fit neatly into the existing scopes, but you
would like a simplified *build time* configuration?
> 2013/7/30 Stephen Connolly <st...@gmail.com>:
> > I find the lure of the custom scopes to be a siren's call.
> >
> > There are maybe 2-3 "missing" scopes. all other needs are better
> addressed
> > with a different project structure in my view.
> >
> > We have the separation between test and non-test... but test is an all or
> > nothing... need the symmetry between the non-test scopes and the test
> > scopes, e.g.
> >
> > compile -> test-compile
> > runtime -> test-runtime
> >
> > I'd also want a "none" scope so that things like the maven dependency and
> > assembly plugins can reference project dependencies without polluting
> > compile classpaths.
> >
> > of course the real issue that the above masks is that unit tests should
> not
> > be using such tricks... and integration tests should be in a separate
> > module, but we need the integration tests failing to block the module
> that
> > they are testing from being built.
> >
> > What is also needed is a way to signify architecturally specific
> artifacts,
> > and also a way to signify that artifact A subsumes or provides an
> > equivalent API to artifact B so that when A is on the classpath, B is
> > automatically excluded from transitive dependencies.
> >
> > But what I'd really like to understand is what you think you need these
> > custom scopes for... because perhaps I am being arrogant and assuming I
> > have thought of all the valid use cases and you can show me the error of
> my
> > thinking
> >
> > -Stephen
> >
> >
> > On 30 July 2013 13:22, Francesco Mari <ma...@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> I was wondering why using custom dependency scopes issues a warning
> >> when the POM model is validated. Why Maven just don't ignore dependecy
> >> scopes he cannot understand?
> >>
> >> I was thinking to treat dependency scopes in a different way. The only
> >> logic I've found about dependency scopes is in [1] and [2] (I'm pretty
> >> sure there is more around), respectively how dependency scope
> >> inheritance is computed and whether to import POM dependencies with
> >> scope "import".
> >>
> >> Can this logic be encapsulated in a component which is able to track
> >> other optional "dependency scope" components? Each "dependency scope"
> >> component will define a new dependency scope and will encapsulate the
> >> rules about it (i.e. what happens if a dependency of the given scope
> >> is inherited, if it can be imported, and so on).
> >>
> >> An alternative and simpler solution could be that a "dependency scope"
> >> component maps a custom dependency scope to one standard scope defined
> >> by Maven, so to establish an "is-a" relationship between a custom
> >> dependency scope and a standard one.
> >>
> >> What do you think?
> >>
> >> [1]:
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java#L351
> >> [2]:
> >>
> https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L876
> >>
> >> ---------------------------------------------------------------------
> >> 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: Rationale behind non-standard dependency scopes
Posted by Francesco Mari <ma...@gmail.com>.
If you want a real life example which is very close to what I'm
talking about, you could take a look at [1], which is part of the
Launchpad Maven Plugin of the Apache Sling project.
[1]: https://github.com/apache/sling/blob/trunk/tooling/maven/maven-launchpad-plugin/src/main/java/org/apache/sling/maven/projectsupport/LaunchpadPluginLifecycleParticipant.java
2013/7/30 Francesco Mari <ma...@gmail.com>:
> I missed to describe my use case. I will try to do it as detailed as I
> can, but it can be quite verbose.
>
> I have a project which is built by aggregating other artifacts with
> different roles: runtime OSGi bundles, plain content, testing OSGi
> bundles, integration testing modules. You can't build this project
> with executions of existing plugins (trust me, we tried), so a new
> plugin has been written to handle the corner cases of the packaging
> required by the project. The project is usually deployed as a runnable
> JAR file and a .properties file containing metadata which cannot be
> contained in a POM file.
>
> The packaging plugin contains a LifecycleParticipant as an extension,
> and dependencies are automatically added on the project depending on
> the configuration of the plugin. As you can imagine, the code of the
> LifecycleParticipant is messy, as it tries to scan projects, plugins
> and configurations to figure out what to use as dependencies of the
> project. This is done for two reasons. First, the project is inside an
> aggregator with the bundles it depends on, so it must be built after
> its dependencies are built. Second, we often inspect dependencies of
> our projects using the Maven Dependency Plugin or the Versions Maven
> Plugin and we would like to have tooling support.
>
> The pure and correct solution would be to duplicate the same
> information I have in the configuration of the plugin and to copy it
> in the dependencies section of the POM. This will satisfy my
> requirements, but will make the configuration of the build too
> verbose.
>
> If I had custom dependency scopes like "runtime-bundle",
> "testing-bundle", "content", etc. I could be able to still use the
> dependency mechanism of Maven, let Maven assemble the POM model as
> usual, parse the configuration and configure my plugin, instead of
> doing it in my LifecycleParticipant, which is tedious and error prone
> (other than duplicated logic). I could write my plugin to scan the
> dependencies for custom scopes, instead of relying on the
> configuration only.
>
> Do you have better ideas for this problem?
>
> 2013/7/30 Stephen Connolly <st...@gmail.com>:
>> I find the lure of the custom scopes to be a siren's call.
>>
>> There are maybe 2-3 "missing" scopes. all other needs are better addressed
>> with a different project structure in my view.
>>
>> We have the separation between test and non-test... but test is an all or
>> nothing... need the symmetry between the non-test scopes and the test
>> scopes, e.g.
>>
>> compile -> test-compile
>> runtime -> test-runtime
>>
>> I'd also want a "none" scope so that things like the maven dependency and
>> assembly plugins can reference project dependencies without polluting
>> compile classpaths.
>>
>> of course the real issue that the above masks is that unit tests should not
>> be using such tricks... and integration tests should be in a separate
>> module, but we need the integration tests failing to block the module that
>> they are testing from being built.
>>
>> What is also needed is a way to signify architecturally specific artifacts,
>> and also a way to signify that artifact A subsumes or provides an
>> equivalent API to artifact B so that when A is on the classpath, B is
>> automatically excluded from transitive dependencies.
>>
>> But what I'd really like to understand is what you think you need these
>> custom scopes for... because perhaps I am being arrogant and assuming I
>> have thought of all the valid use cases and you can show me the error of my
>> thinking
>>
>> -Stephen
>>
>>
>> On 30 July 2013 13:22, Francesco Mari <ma...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I was wondering why using custom dependency scopes issues a warning
>>> when the POM model is validated. Why Maven just don't ignore dependecy
>>> scopes he cannot understand?
>>>
>>> I was thinking to treat dependency scopes in a different way. The only
>>> logic I've found about dependency scopes is in [1] and [2] (I'm pretty
>>> sure there is more around), respectively how dependency scope
>>> inheritance is computed and whether to import POM dependencies with
>>> scope "import".
>>>
>>> Can this logic be encapsulated in a component which is able to track
>>> other optional "dependency scope" components? Each "dependency scope"
>>> component will define a new dependency scope and will encapsulate the
>>> rules about it (i.e. what happens if a dependency of the given scope
>>> is inherited, if it can be imported, and so on).
>>>
>>> An alternative and simpler solution could be that a "dependency scope"
>>> component maps a custom dependency scope to one standard scope defined
>>> by Maven, so to establish an "is-a" relationship between a custom
>>> dependency scope and a standard one.
>>>
>>> What do you think?
>>>
>>> [1]:
>>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java#L351
>>> [2]:
>>> https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L876
>>>
>>> ---------------------------------------------------------------------
>>> 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: Rationale behind non-standard dependency scopes
Posted by Francesco Mari <ma...@gmail.com>.
I missed to describe my use case. I will try to do it as detailed as I
can, but it can be quite verbose.
I have a project which is built by aggregating other artifacts with
different roles: runtime OSGi bundles, plain content, testing OSGi
bundles, integration testing modules. You can't build this project
with executions of existing plugins (trust me, we tried), so a new
plugin has been written to handle the corner cases of the packaging
required by the project. The project is usually deployed as a runnable
JAR file and a .properties file containing metadata which cannot be
contained in a POM file.
The packaging plugin contains a LifecycleParticipant as an extension,
and dependencies are automatically added on the project depending on
the configuration of the plugin. As you can imagine, the code of the
LifecycleParticipant is messy, as it tries to scan projects, plugins
and configurations to figure out what to use as dependencies of the
project. This is done for two reasons. First, the project is inside an
aggregator with the bundles it depends on, so it must be built after
its dependencies are built. Second, we often inspect dependencies of
our projects using the Maven Dependency Plugin or the Versions Maven
Plugin and we would like to have tooling support.
The pure and correct solution would be to duplicate the same
information I have in the configuration of the plugin and to copy it
in the dependencies section of the POM. This will satisfy my
requirements, but will make the configuration of the build too
verbose.
If I had custom dependency scopes like "runtime-bundle",
"testing-bundle", "content", etc. I could be able to still use the
dependency mechanism of Maven, let Maven assemble the POM model as
usual, parse the configuration and configure my plugin, instead of
doing it in my LifecycleParticipant, which is tedious and error prone
(other than duplicated logic). I could write my plugin to scan the
dependencies for custom scopes, instead of relying on the
configuration only.
Do you have better ideas for this problem?
2013/7/30 Stephen Connolly <st...@gmail.com>:
> I find the lure of the custom scopes to be a siren's call.
>
> There are maybe 2-3 "missing" scopes. all other needs are better addressed
> with a different project structure in my view.
>
> We have the separation between test and non-test... but test is an all or
> nothing... need the symmetry between the non-test scopes and the test
> scopes, e.g.
>
> compile -> test-compile
> runtime -> test-runtime
>
> I'd also want a "none" scope so that things like the maven dependency and
> assembly plugins can reference project dependencies without polluting
> compile classpaths.
>
> of course the real issue that the above masks is that unit tests should not
> be using such tricks... and integration tests should be in a separate
> module, but we need the integration tests failing to block the module that
> they are testing from being built.
>
> What is also needed is a way to signify architecturally specific artifacts,
> and also a way to signify that artifact A subsumes or provides an
> equivalent API to artifact B so that when A is on the classpath, B is
> automatically excluded from transitive dependencies.
>
> But what I'd really like to understand is what you think you need these
> custom scopes for... because perhaps I am being arrogant and assuming I
> have thought of all the valid use cases and you can show me the error of my
> thinking
>
> -Stephen
>
>
> On 30 July 2013 13:22, Francesco Mari <ma...@gmail.com> wrote:
>
>> Hi,
>>
>> I was wondering why using custom dependency scopes issues a warning
>> when the POM model is validated. Why Maven just don't ignore dependecy
>> scopes he cannot understand?
>>
>> I was thinking to treat dependency scopes in a different way. The only
>> logic I've found about dependency scopes is in [1] and [2] (I'm pretty
>> sure there is more around), respectively how dependency scope
>> inheritance is computed and whether to import POM dependencies with
>> scope "import".
>>
>> Can this logic be encapsulated in a component which is able to track
>> other optional "dependency scope" components? Each "dependency scope"
>> component will define a new dependency scope and will encapsulate the
>> rules about it (i.e. what happens if a dependency of the given scope
>> is inherited, if it can be imported, and so on).
>>
>> An alternative and simpler solution could be that a "dependency scope"
>> component maps a custom dependency scope to one standard scope defined
>> by Maven, so to establish an "is-a" relationship between a custom
>> dependency scope and a standard one.
>>
>> What do you think?
>>
>> [1]:
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java#L351
>> [2]:
>> https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L876
>>
>> ---------------------------------------------------------------------
>> 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: Rationale behind non-standard dependency scopes
Posted by Stephen Connolly <st...@gmail.com>.
I find the lure of the custom scopes to be a siren's call.
There are maybe 2-3 "missing" scopes. all other needs are better addressed
with a different project structure in my view.
We have the separation between test and non-test... but test is an all or
nothing... need the symmetry between the non-test scopes and the test
scopes, e.g.
compile -> test-compile
runtime -> test-runtime
I'd also want a "none" scope so that things like the maven dependency and
assembly plugins can reference project dependencies without polluting
compile classpaths.
of course the real issue that the above masks is that unit tests should not
be using such tricks... and integration tests should be in a separate
module, but we need the integration tests failing to block the module that
they are testing from being built.
What is also needed is a way to signify architecturally specific artifacts,
and also a way to signify that artifact A subsumes or provides an
equivalent API to artifact B so that when A is on the classpath, B is
automatically excluded from transitive dependencies.
But what I'd really like to understand is what you think you need these
custom scopes for... because perhaps I am being arrogant and assuming I
have thought of all the valid use cases and you can show me the error of my
thinking
-Stephen
On 30 July 2013 13:22, Francesco Mari <ma...@gmail.com> wrote:
> Hi,
>
> I was wondering why using custom dependency scopes issues a warning
> when the POM model is validated. Why Maven just don't ignore dependecy
> scopes he cannot understand?
>
> I was thinking to treat dependency scopes in a different way. The only
> logic I've found about dependency scopes is in [1] and [2] (I'm pretty
> sure there is more around), respectively how dependency scope
> inheritance is computed and whether to import POM dependencies with
> scope "import".
>
> Can this logic be encapsulated in a component which is able to track
> other optional "dependency scope" components? Each "dependency scope"
> component will define a new dependency scope and will encapsulate the
> rules about it (i.e. what happens if a dependency of the given scope
> is inherited, if it can be imported, and so on).
>
> An alternative and simpler solution could be that a "dependency scope"
> component maps a custom dependency scope to one standard scope defined
> by Maven, so to establish an "is-a" relationship between a custom
> dependency scope and a standard one.
>
> What do you think?
>
> [1]:
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java#L351
> [2]:
> https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L876
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>