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. ) 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. I'm not even sure wheter redefining that dependency with scope=provided will work (but it probably will). And, provided is meant as 'available in the _runtime_ environment', not 'available in dependent projects'. It also means 'compile scope only, and runtime too, but don't package it or add it to the runtime classpath since it'll be available'. So when my dependent project wants to compile, provided jars should be on the classpath, I think. 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 ;)) -- Kenney > > Cheers, > Brett > > Kenney Westerhof wrote: > > >Hi, i'm facing this problem: > > > >Project A has a servlet implementation that (obviously) extends > >HttpServlet and has a dependency on servletapi, scope=provided. > > > >Project B depends on project A (scope=compile), and extends the servlet > >defined in A. Now, if it doesn't call/override methods in A that > >have a servletapi parameter (i.e. HttpServletRequest), B doesn't need > >to have a dep on servletapi. > > > >However, as soon as B overrides/uses a method that has HttpServletRequest > >as a parameter, it requires a dependency on servletapi. > > > >This seems odd to me. I just want to extend A, depend on it, so I get > >everything I need, and just override a method that does a > >System.out.prinltn and delegates to the parent (for instance). Why would I > >need to specify a dependency on servletapi then myself? > > > >I've located the place where scope=provided gets nuked in transitive > >dependencies: maven-artifact's DefaultArtifactFactory.createArtifact. > > > >I really want to make the provided scope inheritable, but wanted to > >check with you guys first to see wheter this is wanted and wheter to do > >this now of after beta-1 is released. > > > >WDYT? > > > >-- Kenney > > > >--------------------------------------------------------------------- > >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] > -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
