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]
