On 11 April 2014 14:40, Chris Graham <chrisgw...@gmail.com> wrote: > > > Sent from my iPhone > > On 11/04/2014, at 9:23 AM, Barrie Treloar <baerr...@gmail.com> wrote: > > > On 10 April 2014 23:37, Lennart Jörelid <lennart.jore...@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."
