Kenney Westerhof wrote: >On Thu, 15 Sep 2005, Brett Porter wrote: > > > >>This is intentional. Why does project A declare it as "provided"? That >>is only intended to be used in the "end POM" itself. If you really >>require it at compile time, and intend to pass it on, you should use >>"compile" scope. >> >> > >I'm not sure I follow - since when are scopes meant to be used >in 'end POMs' or 'lib POMs' or ...? I don't think people >know how their projects are being used in advance.. if a dependencies >scope adds some limitation to the use of that project, shouldn't that >be enforced/marked somewhere else in the pom? Or is the mere presence >of a 'scope=provided' dependency reason enough not to extend classes in >some pom? A project doesn't know in advance some of its classes are going >to be extended (the problem also appears when you just extend one of the >classes, even if you don't add / override any methods. ) > > This is exaclt ythe argument I'd use for not passing on a provided dependency. How do you know that everything that uses your library will provide that dependency? provided is only intended for use in the final packaging plugins like a war, ear or assembly.
>Say I use some 3rd party lib and decide i want some AOP done on those >classes (that _might_ work), or I want to extend a class (or create a >wrapper) to make it a Plexus component.. that sure isn't intended. >And you can't expect all projects that use the servletapi to define >it with scope=compile. > If it is intended for reuse, then it should always list it as compile. >I'm not even sure wheter redefining that dependency >with scope=provided will work (but it probably will). > > Well, if the other is going to be compile, it must. >And, provided is meant as 'available in the _runtime_ environment', not >'available in dependent projects'. > > Right, but the runtime environment is not the same for each project. >But I probably have a wrong understanding of 'scope=provided'.. >It's just - when I extend a class, I get this message 'cannot find ><some.package.name.SomeClass>', and i'd have to skim through all >non-included dependencies (transitively!) to find out what dependency >I should add (sounds like maven 1 to me ;)) > :) We should talk this through - after all , if we're confused what hope do the users have! It all seems straight forward to me, but it has come up a couple of times. Let's figure out if we really disagree or whether its just a lack of documentation of what it is/does. Thanks, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
