In my hurry to get my ideas written and posted, I realize that I missed a few things.
First, I found that <inclusions> was suggested here: http://jira.codehaus.org/browse/MNG-702 but closed to use optional scope instead: http://jira.codehaus.org/browse/MNG-947 Whereas, of course, I'm suggesting doing both. But what I really missed was a technical issue: if you are specifying that you want to include a "optional" scope dependency, at what scope does it get used in your project? Either optional becomes a separate flag instead of a scope. Or within the <inclusion> tag you also specify the <scope>. The only problem with the latter options it that it gets rid of the symmetry between <inclusion> and <exclusion>. But it still makes sense to me. Not sure on etiquette/proper tracking here: should I put a suggestion of using <inclusions> (Including scope) as a commont on the MNG-947 issue, or just wait and see on discussion on the mailing list and a) do it later, b) let a developer who likes the idea put it on there... -Stephen Duncan Jr On 9/21/05, Stephen Duncan <[EMAIL PROTECTED]> wrote: > 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 > -- Stephen Duncan Jr www.stephenduncanjr.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
