Oh I know it is the recommended practise, but I believe that particular recommendation is flawed since it does not consider the needs of *big* systems with reactors containing lots of projects. Basically the recommendation is to repeat some information (i.e. dependency specs) which is already implied/required (by depending on a project where the information is already provided).
Repeating redundant information is not too much of a hassle when considering small reactors with few maven projects. It is hugely annoying already when a reactor consists of around 40 projects - and such a reactor would equate only a small enterprise project, particularly if modularization like JBoss Modules, OSGi or Jigsaw is applied. I can see the merit in using an immutable classpath for projects, since Maven core would get simpler and smoother mechanics. I can also see the need for some plugins to add dependencies to various classpaths - to facilitate some common operations such as instrumenting classes or the like. I just don't want to have to repeat dependencies all over a reactor when these dependencies are already implied by normal transitive dependency mechanics - that would imply a huge and completely unneccessary workload. My recommendation is to provide a core-controlled mechanics to enable plugins to add dependencies to *their own execution* if we want to make the classpath immutable otherwise. Overriding the "I want to add dependencies" method can easily be detected by analysis tools and computed for reports, while preserving a simpler logic in the core for dependency resolution. My recommendation is also to completely ignore the suggestion that we would have to repeat dependencies which are implied by transitive dependency mechanics. This would create lots of unnecessary work for bigger projects. 2014-04-11 1:23 GMT+02:00 Barrie Treloar <baerr...@gmail.com>: > 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. > > > http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.htmlwill > report failures for you so you can check. > -- -- +==============================+ | Bästa hälsningar, | [sw. "Best regards"] | | Lennart Jörelid | EAI Architect & Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: l...@jguru.se | URL: www.jguru.se | Phone | (skype): jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==============================+
