Re: scope provided not transitively inherited?
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. 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]
Re: scope provided not transitively inherited?
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]
Re: scope provided not transitively inherited?
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]
scope provided not transitively inherited?
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]
