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]
