maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Barrie Treloar <baerr...@gmail.com>
Subject Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies
Date Fri, 11 Apr 2014 05:43:29 GMT
On 11 April 2014 14:40, Chris Graham <chrisgwarp@gmail.com> wrote:

>
>
> Sent from my iPhone
>
> On 11/04/2014, at 9:23 AM, Barrie Treloar <baerrach@gmail.com> wrote:
>
> > On 10 April 2014 23:37, Lennart J├Ârelid <lennart.jorelid@gmail.com>
> wrote:
> >
> >> So ... the consequence of your approach would be that POMs throughout a
> >> maven reactor would have to repeat a dependency declaration if the
> classes
> >> in your maven project "directly" import a type. This - to me - seems not
> >> only complex to resolve in a big reactor, but quite user-unfriendly as
> >> well. An example shows this, I think:
> >>
> >
> > This is the *recommended* best practice.
> >
> > If you use something directly, then you should be explicit about that
> > dependency.
>
> If I've followed this thread and fully understood it, the proposal is to
> force the declaration of a dependency in the current Pom, even if they are
> declared as dependencies of your declared dependency, ie transitive
> dependencies.
>
>
This thread is about making the classpath immutable to plugins.
As per Jason's original email if a plugin wants to change the classpath
they should declare it in the plugin pom, or document that users should
declare it in their pom.



> Does this not effectively disable the use of transitive dependencies?
>
>
Additionally this thread had stuff included around Mark Derricutt's email
that suggested Maven change its behaviour so that compile time dependencies
are not transitive.
Which is what the recommended best practice is to do anyway.

Runtime would still be transitive.

>
> I find transitive dependencies one of the most useful, powerful features
> of Maven.
>
> Without them, it takes me back to the (horrid) Ant days of manually having
> walk the dependency tree.
>
> And what of consolidation/library poms, where one Pom lists 100's of other
> jars needed? The WebSphere Process Server one (172 jars!) comes to mind.
>

Consolidation or library poms would mostly contain runtime dependencies and
not be a problem.

For compile time dependencies the two ways to do this are via inheritance
or includes.
Inheritance (i.e. parent poms) works because the dependency management
defines what versions to use, and in the child you select what you actually
want.
If there are too many things to define in the child then maybe the include
way would be better.
I can't remember whether include is vaporware though...

http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-best-practice.htmlsays
"There's a certain point defined more by style and experience where you
decide that minimal duplication of configuration is a small price to pay
for allowing projects [...] to remain completely independent. Designing a
huge set of thirty plus projects which all inherit five levels of POM
configuration isn't always the best idea."

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