My use case is using the springframework. First, note that all dependencies that I could find in that project are not defined, and are therefore compile scope.
There's several levels of problems here involving optional dependencies that have turned transitive dependencies into a nightmare. Say I depend on spring-hibernate. This causes me to depend on both hibernate2 and hibernate3. It also causes me to depend on spring-orm (rightfully). However, that then causes me to depend on spring-ibatis, etc. for other orm implementations. Possible solutions: 1) Manually specify exclusions on everything but optional jar that I want. 2) Allow me to use an option to "turn off" transitive dependencies on that jar, and explicitly depend on the optional jars I need (such as hibernate2 in example above). 3) Create "optional" scope. Rely on repository POM to set this properly. Then explicitly depend on the optional jar. 4) Create "optional" scope. Rely on repository POM to set this proeprly. Add "inclusions" for optionally-scoped jars that mirrors exclusions for currently passed along jars. Pros: 1) Works reliably today. 2) Can work with a simple option added, without reliance on correct POM in repository for the dependency. 3) Just requires Maven developers to add another scope. 4) Seems like it provides the most accurate model and description of dependencies. Makes sense, seems clean, etc. Cons: 1) Verbose. When upgrading to a new version of a dependency that adds additional optional dependencies, have to update the exclusions. 2) Explicitly depending on transitive dependencies, including ones that are never optional. 3) Explicitly depending on transitive dependencies. Depends on proper POM in repo. 4) Most work for you wonderful developers. :) Depends on proper POM in repo. Hope this was helpful. At the moment my preference would be to have option 2 working today (well, not literally...) (since it will take some time for the repository POM's to be accurate), with 4) available as the preferred long term method. I've only been using Maven 2 for a day now, but it seems like implementing something here will make transitive dependencies a lot less painful. Please let me know if I missed something and some of what I want is available today... -Stephen Duncan Jr On 9/19/05, Brett Porter <[EMAIL PROTECTED]> wrote: > Actually, I'd have said "optional" should be equivalent to "compile" but > not passed on. > > While they might be significantly different in behaviour, I think that > the naming makes it clearer about its use: optional is things used in > some contexts but is optional and hence not passed on, while provided is > something required, but you are expected to provide in your environment. > The fact that provided is not passed on is not something your project > should need to know about (like test dependencies, but different to > optional ones that you would want to be aware of - they are sort of > passed on but unused). > > - Brett > > Allison, Bob wrote: > > >As far as the end user would see, what is the difference between > >scope=optional and scope=provided? It sounds like both scopes do the > >same thing: use the dependency in the project's compile and test phases > >and prevent the dependency from being passed transitively. How would a > >developer know which scope to use, other than some verbiage in a > >(probably unread) README somewhere? > > > >-----Original Message----- > >From: Brett Porter [mailto:[EMAIL PROTECTED] > >Sent: Sunday, September 18, 2005 20:27 > >To: Maven Developers List > >Subject: Re: optional scope for dependencies > > > > > >Kenney Westerhof wrote: > > > > > > > >>scope=provided currently does not do this (but I like it to :)) > >> > >> > >> > >> > >> > >I thought that was the point - provided doesn't pass along the > >dependency, hence can be abused as an optional scope. I'm porposing we > >actually have an optional scope that does that. This would effectively > >be the same as removing them from the repository POM, though allows us > >to warn on it at least, and perhaps factor them into the version > >resolution if the dependency is present elsewhere in the tree. > > > >BTW, I've responded to that email - we should discuss that further > >there. > > > > > > > >>Well, the excludes mechanism can deal with this. > >> > >> > >> > >> > >Yes, but that pushes the work to the client, which we are hearing > >regular complaints about. It's very verbose. > > > > > > > >>I believe there was an idea about specifying api's as dependencies > >>and a default implementation for that. If a nearer project specifies > >>another implementation, that should be used. Although I don't know > >>how this should (and can?) be implemented. For instance, a war > >>project can be considered final, but then you could also package > >>it into an ear, which might override the implementation specified > >>in the war's pom. > >> > >> > >> > >> > >This is different to this - I'm not sure what you mean. > > > > > > > >>Btw, the dependencies brought along with dom4j are needed to use that > >>project, right? Unless the project uses that project with dom4j > >> > >> > >specifies > > > > > >>those dependencies, it'll break at runtime. Isn't it the job of the > >>'nearest' conflict resolution to override versions brought in by > >>dependencies? But i guess this is not a version issue, but an > >>'implementation provider' issue? > >> > >> > >> > >> > >Again, not sure what you mean about implementation provider in relation > >to this. > > > > > > > >>Could you elaborate more on the exact problem? :) > >> > >> > >> > >> > >Yeah, probably didn't go through it enough as I thought it was well > >known. > > > >dom4j introduces a bunch of dependencies it needs to compile, but you > >most likely aren't using because they are optional. You are only using > >them if you use the piece of dom4j code that uses them. This is the same > >as velocity having a JDBC dependency for its JDBC resource loader that a > >lot of people don't use. > > > >The best solution is for dom4j to split up into a bunch of libraries > >that have smaller sets of individual dependencies, and you only depend > >on the pieces you use. As much as we can encourage that we can't enforce > >it. Letting them designate some dependencies as optional would mean that > >those are only used by specific functions not essential to the operation > >of the library, and Maven would skip them in the transitive dependency > >calculations. > > > >- Brett > > > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Stephen Duncan Jr www.stephenduncanjr.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
