On Apr 12, 2014, at 7:24 AM, Lennart Jörelid <lennart.jore...@gmail.com> wrote:
> 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. This simply is not the case. It is precisely for manageability reasons in large projects that you need to be specific. Projects with 100, or 200, or 500 projects. If you do not declare your direct dependencies all manner of problems abound. The problem of repeating the version of a particular dependency, which is really the important aspect, is mitigated by dependencyManagement but a project should always declare its dependencies. We do not enforce this right now and if you want to rely on a transitive dependency without the use of dependencyManagement then you are subject to a version of dependency that the conflict resolver hands over. You're not going to convince anyone here that's a good idea. The heuristics and data don't exist, yet, to have the system make the correct choice or at least help you make a correct choice as there are many possible correct choices. In practice you know your points of integration where you mesh conflict in your dependencies until many parts are integrated into a final runtime where you simply have to manage what goes into it, there's no real way around that. Being explicit all the way along makes analysis, integration and final provisioning manageable. > 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). > We are not. One project cannot imply the requirements of another. > 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. > In practice for many years I have not found this to be the case with large Maven projects. Not specifying your requirements, in any situation really, leads to problems. > 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. > Or find tools which are better that don't require that. In the case of code coverage I've used Jacoco for years, it is a simple agent model and does everything else required itself without the need for other mucking with the classes. Well, it does have a offline instrumentation mode but I don't recommend using that method and neither do the Jacoco folks. So in light of modern techniques this classpath monkey patching or static instrumentation is not required anymore. > 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* We do. The standard mechanism for a plugin to declare its dependencies if it requires something to run. Furthermore a plugin declaration by a user can provider additional dependencies if the plugin itself has extension points that a user can provide. Or if the plugin author has provided options where you need to have one thing on the classpath vs another then the user is instructed to add set A of dependencies to the plugin declaration vs set B. Instead of providing a configuration which the plugin acts upon internally to go fetch dependencies and modify the execution classpath. What we have is declarative and I believe is sufficient for all reasonable requirements. > 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. > Like I said above you can do that if you want, but it's not manageable at all. We may one day enforce that you declare all direct requirements but nothing stops you in Maven 3.x from putting a blindfold on and throwing the darts at the version selection board. > > 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 > +==============================+ Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
