On Apr 13, 2014, at 8:11 AM, Lennart Jörelid <lennart.jore...@gmail.com> wrote:
> Hello all, > > Let’s see if we can focus on the issue at hand here. > > 12 apr 2014 kl. 16:59 skrev Jason van Zyl <ja...@takari.io>: > >> >> 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. > > You seem to consider transitive dependencies "unspecific” or ”unmanageable” - > as opposed to the nature of explicit dependency declarations repeated > throughout the entire reactor. This is not the case; in declaring a > dependency to an API project from an impl project within the same reactor I > automatically say ”I will use/import the dependencies from the API I am > implementing” … and then adding dependency declarations used only by the > local impl project itself. I don’t want to repeat all dependency definitions > from the API project *again* within the impl project since it would only add > bloat to my impl project dependency definitions. > I'm happy to chat in IRC, but in your first sentence you make an assumption which isn't true and then carry on to write the rest of the email. Transitive dependencies are certainly manageable. I am also not suggesting to change the current mechanics with compile scope, and I've never seen any OSGi project where it didn't explicitly define its direct requirements so I'm interested knowing you you got that working at all. And while this email chain could go on for days a 20 minute chat in IRC would be more productive. Just pop into #maven on irc.codehaus.org and we can carry on there. > I believe that all of us agree that it is sensible to define a Parent POM > containing a dependencyManagement section to harmonize versions and default > scopes of dependencies used throughout the reactor. This implies that all > [external] dependencies within POMs in the reactor are defined on the form > > <dependency> > <groupId>org.slf4j</groupId> > <artifactId>slf4j-api</artifactId> > </dependency> > > What you are suggesting is that we should change the current mechanics of > Maven within compile scope (but not runtime/test scope since we would > actually need the transitive dependencies there, if I understand your > suggestion correctly) to force us to repeat all dependency definitions > already present within projects I depend upon. I’m saying this is a poor > idea, since it will require maven users to repeat the dependency (such as the > example above) in all projects within the reactor - even if they depend on > other projects in the reactor that already defined it. Your suggestion of > ignoring today’s transitive dependencies in compile scope would only make > sense if you believe that the majority of people using Maven out there do not > understand transitive dependencies at all …. implying we should make them > repeat dependency mechanics ”for clarity”. In my view, this is an incorrect > assumption. > > Let’s compare the tasks required for refactoring a big reactor with the two > mechanics: > > Whenever I would like to change the version of the slf4j-api within my > reactor I still would need only change the dependencyManagement element in > the parent POM. No change from today’s mechanics there. > Whenever I would like to change the actual dependency from slf4j-api to > something else I would need to change the code in all projects. No change > from today. > If I use today’s transitive dependency mechanics, I could need to alter the > actual dependency definition in 1 project within the reactor if I so choose. > With your suggestion I would have to change the dependency in all 402 > projects within the reactor instead. I’m suggestion therefore that this is a > pretty poor idea since all projects require the slf4j-api during runtime > anyways, implying that the explicit dependency definition in all the projects > is completely redundant information. Having the version defined within the > parent’s DependencyManagement and the dependency itself defined within a > project I depend upon is sufficient, and requires no declaration repetition. > Your suggestion is a change in current maven mechanics which makes sense only > for reasons of internal Maven development, but no sense for the *users* of > Maven. That is why I suggest that your view would be impractical for a > sensible way forwards. > >> Projects with 100, or 200, or 500 projects. If you do not declare your >> direct dependencies all manner of problems abound. > > Not at all. My last project built 402 OSGi compliant JARs without any problem > using the current (transitive dependency) mechanics. > Going for your suggestion to change the maven mechanics would have caused us > loads of extra, unnecessary work since any form of refactoring in terms of > dependencies would have required us not only to change the code but also a > flush of POMs. The current Maven mechanics for transitive dependencies > implies we didn’t have to change the slush of POMs and therefore saved us > loads of work. > > Moreover, I am grateful that each POM defines only the dependencies unique to > that project - implying I can easily see which dependencies are added in a > chain of dependent projects within a reactor. This becomes difficult with > your suggestion, since POMs would be cluttered with the transitive dependency > definitions of its dependent projects. > >> 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. > > Noone is arguing (I certainly hope) that you should avoid defining > dependencies within the dependencyManagement section of a parent POM. > That is a completely separate issue from having to repeat existing transitive > dependency declarations within all POMs in a reactor. > >>> 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. > > Uhm … yes, in terms of [transitive] Dependencies which we are discussing here. > If project A depend on project B which itself has a defined compile-scope > dependency (say C), then project A has an implied/transitive dependency to C. > > That dependency is certainly required within the runtime scope of A, so I’m > saying that the same visibility rules should hold for the compile scope as > well. > >>> 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. > > Again, transitive dependencies are not arbitrary, incomprehensible or > ”unspecified”. > What leads to problems is people not understanding the conceptual model of > how transitive dependencies are handled (or not knowing that there are > several plugins that can assist in visualizing or enforcing those > dependencies for them). Let’s solve the correct problem here; transitive > dependencies themselves are not a problem. > >>> 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. > > In normal enterprise settings, the build tooling is frequently not something > you are at liberty to change on a whim. > That is the reality I believe we should cater for. > > > // Bästa hälsningar, > // [sw. "Best regards" > // > // Lennart Jörelid > // lennart.jore...@gmail.com > > > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham
