Isn't the point here that compile scope would turn into runtime scope *when transitive*?
So this is not the same as the current trick of putting <optional>true</optional> on a dependency. In general I am in favour if demoting dependencies to runtime when transitive (we always warned this was the long term plan)... But I think we do need a scope for dependencies that are an explicit contract, ie they would *stay* compile scope, if we co that route On Sunday, 13 April 2014, Jason van Zyl <ja...@takari.io> wrote: > > On Apr 13, 2014, at 8:11 AM, Lennart Jörelid > <lennart.jore...@gmail.com<javascript:;>> > 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<javascript:;> > >: > > > >> > >> On Apr 12, 2014, at 7:24 AM, Lennart Jörelid > >> <lennart.jore...@gmail.com<javascript:;>> > 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 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 > > > > > > > > > > -- Sent from my phone
