maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Rationale behind non-standard dependency scopes
Date Tue, 30 Jul 2013 14:52:08 GMT
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 <mari.francesco@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 <stephen.alan.connolly@gmail.com>:
> > On 30 July 2013 14:23, Francesco Mari <mari.francesco@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 <stephen.alan.connolly@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 <mari.francesco@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message