Re: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
On Mon, May 11, 2009 at 9:48 AM, Todd Thiessen thies...@nortel.com wrote: Are there many cases where you want something for compilation that isn't needed at runtime? I don't see them as being separate. Really? I am surprised. Yes there is a relation between compile and runtime. However, there is a different relation between compile and test. Scope has multiple meanings here. You have scope which defines when a dependency is needed (ie: at compile or runtime); or scope that defines what code a dependency is needed for (ie: test or main). Really, test scope means compile time (the when dimension of scope) for test code (the what code dimension of scope). For instance, how does one define a test dependency that is only needed at runtime? Two different concepts stored in one variable makes this cumbersome. At test runtime I presume? You use the test scope. Is it hurting anything if it's there on the test compile classpath? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
At test runtime I presume? You use the test scope. Is it hurting anything if it's there on the test compile classpath? Its an example of how the scope definition is overloaded. Whether or not it hurts anything is moot. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
Are there many cases where you want something for compilation that isn't needed at runtime? I don't see them as being separate. Really? I am surprised. Yes there is a relation between compile and runtime. However, there is a different relation between compile and test. Scope has multiple meanings here. You have scope which defines when a dependency is needed (ie: at compile or runtime); or scope that defines what code a dependency is needed for (ie: test or main). Really, test scope means compile time (the when dimension of scope) for test code (the what code dimension of scope). For instance, how does one define a test dependency that is only needed at runtime? Two different concepts stored in one variable makes this cumbersome. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
2009/5/11 Todd Thiessen thies...@nortel.com Are there many cases where you want something for compilation that isn't needed at runtime? I don't see them as being separate. Really? I am surprised. Yes there is a relation between compile and runtime. However, there is a different relation between compile and test. Scope has multiple meanings here. You have scope which defines when a dependency is needed (ie: at compile or runtime); or scope that defines what code a dependency is needed for (ie: test or main). Really, test scope means compile time (the when dimension of scope) for test code (the what code dimension of scope). For instance, how does one define a test dependency that is only needed at runtime? Two different concepts stored in one variable makes this cumbersome. I think the answer here is that nobody had a good example at the time! The primary issue that people want to control scope for is to ensure that: 1. They do not accidentally add compile time dependencies to implementations of an API (this may be stated in different ways) so for example, if I depend on the servlet-api I do not want to reference tomcat classes from my code because I have broken portability of my code hence the three scopes: compile - put on compile and runtime classpaths. provided - put on compile classpath only runtime - put on runtime classpath only The secondary issue is unit tests, we often need additional dependencies for writing unit tests that we don't want to creep into our (non-test) code. Also it can be useful to use GPL code when writing unit tests, although you might not use the GPL code in your (non-test) code. Thus enter test - put on test classpath I agree that perhaps we should separate the two sets of classpaths, i.e. the (non-test) compile and runtime classpaths and the test compile and runtime classpaths. But the pollution of runtime dependencies into test code is less of an issue for unit tests Integration tests should go in their own module and that gives you control over the compile and runtime classpaths of that code
RE: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
I think the answer here is that nobody had a good example at the time! And even when you do, you can use exclusions which you interesting mention in your next response ;-). So if you want a particular compile transitive dependency to be included only as test, exclude it and add it to your local pom as test. I agree that the local pom should have precise control over how the scope of a dependency gets defined. But Maven is all about convention over configuration. If the convention is that compile scope should override test scope, then that is what maven should do by default. In the rare cases when a user wishes to change this behaviour, maven should provide a way to configure a transitive dependency manually. This is very similar in concept to marking a transitve dependency as exclude. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
2009/5/11 Todd Thiessen thies...@nortel.com I think the answer here is that nobody had a good example at the time! And even when you do, you can use exclusions which you interesting mention in your next response ;-). So if you want a particular compile transitive dependency to be included only as test, exclude it and add it to your local pom as test. I agree that the local pom should have precise control over how the scope of a dependency gets defined. But Maven is all about convention over configuration. If the convention is that compile scope should override test scope, then that is what maven should do by default. In I thought that Maven issued a warning if a compile scope was downgraded to test but it would appear that I might be wrong in that case. the rare cases when a user wishes to change this behaviour, maven should provide a way to configure a transitive dependency manually. This is very similar in concept to marking a transitve dependency as exclude. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
2009/5/11 Brian Fox bri...@infinity.nu: At face value the logic seems to make sense, but I haven't thought through all the ramifications. I thought Mark Hobson mentioned some cases where the opposite was desired. At this point your best bet is to prepare a proposal on http://docs.codehaus.org/display/MAVENUSER/User+Proposals with an associated Jira and then start building some consensus around the changes. Work in this area for 3.x is nearing so now's a good time to create the proposal. I'm all in favour of local test scope not overriding transitive compile scope. I've just this second been bitten by this again and had to mangle the pom to workaround it. Local dependencies shouldn't have any higher precedence that transitive ones; if you want to force a dependency's version and/or scope, then dependency management should be used for this purpose. The compile/test runtime/provided scope separation sounds interesting but I'd need some time to think it through. Let's at least get this first issue in JIRA before it gets lost, has anything been raised? Mark - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
Just created http://jira.codehaus.org/browse/MNG-4156 Regards, Stevo. On Mon, May 11, 2009 at 6:40 PM, Mark Hobson markhob...@gmail.com wrote: 2009/5/11 Brian Fox bri...@infinity.nu: At face value the logic seems to make sense, but I haven't thought through all the ramifications. I thought Mark Hobson mentioned some cases where the opposite was desired. At this point your best bet is to prepare a proposal on http://docs.codehaus.org/display/MAVENUSER/User+Proposals with an associated Jira and then start building some consensus around the changes. Work in this area for 3.x is nearing so now's a good time to create the proposal. I'm all in favour of local test scope not overriding transitive compile scope. I've just this second been bitten by this again and had to mangle the pom to workaround it. Local dependencies shouldn't have any higher precedence that transitive ones; if you want to force a dependency's version and/or scope, then dependency management should be used for this purpose. The compile/test runtime/provided scope separation sounds interesting but I'd need some time to think it through. Let's at least get this first issue in JIRA before it gets lost, has anything been raised? Mark - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
Is there any reason why would local win in this particular case? Regards, Stevo. On Sun, May 10, 2009 at 5:26 AM, Brian Fox bri...@infinity.nu wrote: On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen thies...@nortel.com wrote: Override the dependency defined in the POM, as Steve outline in his earlier response. Let me quote his explanation for ease of reference: E.g. if project P has test scoped dependency to a LIB1, and compile scoped dependency to LIB2, while LIB2 has compile scope dependency to LIB1, currently project P's war will wrongly end up without LIB1 included. In P one expects LIB1 to be available for testing, but that shouldn't affect availability of LIB1 as compile scoped transitive dependency, it should be the other way round, in this case scope of declared test scoped dependency should be broadened. I used the term override to descibe the situation when project P should have LIB1 defined as a compile dependency, when the POM actually defines it as test. But it should should only override for test dependencies, not for provided or runtime. The local pom always wins. Placing additional semantics on how things merge is troublesome. I'm sure we can think of scenarios where widening is not the right thing to do. In either case you must have the ability to resolve this yourself if it doesn't do the right thing...and the way to do that is to put what you want in the local pom. As for your lost me comment I am not sure what you would like explained. Scope basically has multiple meanings. Compile/test are both related to requiring a dependency for compilation; runtime/provided are both related to requiring a dependency only at runtime. These multiple meanings are not suited to a single variable. Are there many cases where you want something for compilation that isn't needed at runtime? I don't see them as being separate. --- Todd Thiessen
Re: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
By local I mean the pom currently being built. Stuff defined here always overrides dependencies and transitive dependencies. On Sun, May 10, 2009 at 5:34 AM, Stevo Slavić ssla...@gmail.com wrote: Is there any reason why would local win in this particular case? Regards, Stevo. On Sun, May 10, 2009 at 5:26 AM, Brian Fox bri...@infinity.nu wrote: On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen thies...@nortel.com wrote: Override the dependency defined in the POM, as Steve outline in his earlier response. Let me quote his explanation for ease of reference: E.g. if project P has test scoped dependency to a LIB1, and compile scoped dependency to LIB2, while LIB2 has compile scope dependency to LIB1, currently project P's war will wrongly end up without LIB1 included. In P one expects LIB1 to be available for testing, but that shouldn't affect availability of LIB1 as compile scoped transitive dependency, it should be the other way round, in this case scope of declared test scoped dependency should be broadened. I used the term override to descibe the situation when project P should have LIB1 defined as a compile dependency, when the POM actually defines it as test. But it should should only override for test dependencies, not for provided or runtime. The local pom always wins. Placing additional semantics on how things merge is troublesome. I'm sure we can think of scenarios where widening is not the right thing to do. In either case you must have the ability to resolve this yourself if it doesn't do the right thing...and the way to do that is to put what you want in the local pom. As for your lost me comment I am not sure what you would like explained. Scope basically has multiple meanings. Compile/test are both related to requiring a dependency for compilation; runtime/provided are both related to requiring a dependency only at runtime. These multiple meanings are not suited to a single variable. Are there many cases where you want something for compilation that isn't needed at runtime? I don't see them as being separate. --- Todd Thiessen
Re: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
Just because that's the way things are doesn't mean that's how they should be., said a character in the movie Australia. In this particular scenario, local test scoped dependency vs compile scope transitive dependency, it's my opinion that current strategy is wrong. Local test scoped dependencies shouldn't by default override compile scoped transitive dependencies. If one wanted to exclude transitive compile scoped dependency and have it available only in test scope, it would be more natural (for me at least) to require user to specify appropriate excludes section on a dependency that brought transitive dependency with it. Again, just in this particular case, requiring user to explicitly specify excludes section would more clearly state/document the intention, while currently build tool silently makes a wrong decision (maybe there are times this decision is correct, but IMO it correct in far less cases than it is wrong). Regards, Stevo. 2009/5/10 Brian Fox bri...@infinity.nu By local I mean the pom currently being built. Stuff defined here always overrides dependencies and transitive dependencies. On Sun, May 10, 2009 at 5:34 AM, Stevo Slavić ssla...@gmail.com wrote: Is there any reason why would local win in this particular case? Regards, Stevo. On Sun, May 10, 2009 at 5:26 AM, Brian Fox bri...@infinity.nu wrote: On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen thies...@nortel.com wrote: Override the dependency defined in the POM, as Steve outline in his earlier response. Let me quote his explanation for ease of reference: E.g. if project P has test scoped dependency to a LIB1, and compile scoped dependency to LIB2, while LIB2 has compile scope dependency to LIB1, currently project P's war will wrongly end up without LIB1 included. In P one expects LIB1 to be available for testing, but that shouldn't affect availability of LIB1 as compile scoped transitive dependency, it should be the other way round, in this case scope of declared test scoped dependency should be broadened. I used the term override to descibe the situation when project P should have LIB1 defined as a compile dependency, when the POM actually defines it as test. But it should should only override for test dependencies, not for provided or runtime. The local pom always wins. Placing additional semantics on how things merge is troublesome. I'm sure we can think of scenarios where widening is not the right thing to do. In either case you must have the ability to resolve this yourself if it doesn't do the right thing...and the way to do that is to put what you want in the local pom. As for your lost me comment I am not sure what you would like explained. Scope basically has multiple meanings. Compile/test are both related to requiring a dependency for compilation; runtime/provided are both related to requiring a dependency only at runtime. These multiple meanings are not suited to a single variable. Are there many cases where you want something for compilation that isn't needed at runtime? I don't see them as being separate. --- Todd Thiessen
Re: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
2009/5/10 Stevo Slavić ssla...@gmail.com Just because that's the way things are doesn't mean that's how they should be., said a character in the movie Australia. I dig that. In this particular scenario, local test scoped dependency vs compile scope transitive dependency, it's my opinion that current strategy is wrong. Local test scoped dependencies shouldn't by default override compile scoped transitive dependencies. If one wanted to exclude transitive compile scoped dependency and have it available only in test scope, it would be more natural (for me at least) to require user to specify appropriate excludes section on a dependency that brought transitive dependency with it. Again, just in this particular case, requiring user to explicitly specify excludes section would more clearly state/document the intention, while currently build tool silently makes a wrong decision (maybe there are times this decision is correct, but IMO it correct in far less cases than it is wrong). At face value the logic seems to make sense, but I haven't thought through all the ramifications. I thought Mark Hobson mentioned some cases where the opposite was desired. At this point your best bet is to prepare a proposal on http://docs.codehaus.org/display/MAVENUSER/User+Proposals with an associated Jira and then start building some consensus around the changes. Work in this area for 3.x is nearing so now's a good time to create the proposal. Regards, Stevo. 2009/5/10 Brian Fox bri...@infinity.nu By local I mean the pom currently being built. Stuff defined here always overrides dependencies and transitive dependencies. On Sun, May 10, 2009 at 5:34 AM, Stevo Slavić ssla...@gmail.com wrote: Is there any reason why would local win in this particular case? Regards, Stevo. On Sun, May 10, 2009 at 5:26 AM, Brian Fox bri...@infinity.nu wrote: On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen thies...@nortel.com wrote: Override the dependency defined in the POM, as Steve outline in his earlier response. Let me quote his explanation for ease of reference: E.g. if project P has test scoped dependency to a LIB1, and compile scoped dependency to LIB2, while LIB2 has compile scope dependency to LIB1, currently project P's war will wrongly end up without LIB1 included. In P one expects LIB1 to be available for testing, but that shouldn't affect availability of LIB1 as compile scoped transitive dependency, it should be the other way round, in this case scope of declared test scoped dependency should be broadened. I used the term override to descibe the situation when project P should have LIB1 defined as a compile dependency, when the POM actually defines it as test. But it should should only override for test dependencies, not for provided or runtime. The local pom always wins. Placing additional semantics on how things merge is troublesome. I'm sure we can think of scenarios where widening is not the right thing to do. In either case you must have the ability to resolve this yourself if it doesn't do the right thing...and the way to do that is to put what you want in the local pom. As for your lost me comment I am not sure what you would like explained. Scope basically has multiple meanings. Compile/test are both related to requiring a dependency for compilation; runtime/provided are both related to requiring a dependency only at runtime. These multiple meanings are not suited to a single variable. Are there many cases where you want something for compilation that isn't needed at runtime? I don't see them as being separate. --- Todd Thiessen
Re: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen thies...@nortel.com wrote: Override the dependency defined in the POM, as Steve outline in his earlier response. Let me quote his explanation for ease of reference: E.g. if project P has test scoped dependency to a LIB1, and compile scoped dependency to LIB2, while LIB2 has compile scope dependency to LIB1, currently project P's war will wrongly end up without LIB1 included. In P one expects LIB1 to be available for testing, but that shouldn't affect availability of LIB1 as compile scoped transitive dependency, it should be the other way round, in this case scope of declared test scoped dependency should be broadened. I used the term override to descibe the situation when project P should have LIB1 defined as a compile dependency, when the POM actually defines it as test. But it should should only override for test dependencies, not for provided or runtime. The local pom always wins. Placing additional semantics on how things merge is troublesome. I'm sure we can think of scenarios where widening is not the right thing to do. In either case you must have the ability to resolve this yourself if it doesn't do the right thing...and the way to do that is to put what you want in the local pom. As for your lost me comment I am not sure what you would like explained. Scope basically has multiple meanings. Compile/test are both related to requiring a dependency for compilation; runtime/provided are both related to requiring a dependency only at runtime. These multiple meanings are not suited to a single variable. Are there many cases where you want something for compilation that isn't needed at runtime? I don't see them as being separate. --- Todd Thiessen
RE: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
Your argument Jorg I think applies to provided and runtime scope, but not to test. The root smell here lies in the definition of scope. Test scope means needed to compile test code. Compile scope means needed to compile production and test code. These are both related to when a dependency is needed to compile. Provided and runtime scope are related to when a dependency is needed at runtime. So the way I see it, a compile transitive dependency should always override a test dependency but not provided or runtime. There is some technical debt here in terms of how scoping works. You really need a further scope classification like: Scope = compile classifier = test classifier = production Scope = runtime classifier = provided Something like this. You likely get the idea. --- Todd Thiessen -Original Message- From: news [mailto:n...@ger.gmane.org] On Behalf Of Jörg Schaible Sent: Friday, May 08, 2009 9:11 AM To: users@maven.apache.org Subject: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism Hi Stevo, Stevo Slavić wrote at Freitag, 8. Mai 2009 14:15: Issue is elsewhere. Initial example I gave included inheritance, but unwanted behavior happens even without it. E.g. if project P has test scoped dependency to a LIB1, and compile scoped dependency to LIB2, while LIB2 has compile scope dependency to LIB1, currently project P's war will wrongly end up without LIB1 included. This is the whole point: This is not wrong, Maven did it right! Actually we use scope narrowing to trim down dependencies that are not needed/only needed for test or provided by the container. In P one expects LIB1 to be available for testing, but that shouldn't affect availability of LIB1 as compile scoped transitive dependency, it should be the other way round, in this case scope of declared test scoped dependency should be broadened. Although Maven helps you with Dependency management, it is still your task as dev to actively maintain them. This implies a check of the dependency tree. As I wrote earlier, things are made worse by fact that during regular packaging/install of such an artifact no warning message is printed about narrower scope being chosen, so without appropriate (functional) tests or checking of dependency:tree one ends up knowing that dependency is missing only at runtime (it's a thril when it happens very late, at production... :) ). Broadening the scope will have some really nasty other side-effects which will again put you in the role of actively maintaining the dep tree ;-) - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
2009/5/8 Todd Thiessen thies...@nortel.com Your argument Jorg I think applies to provided and runtime scope, but not to test. The root smell here lies in the definition of scope. Test scope means needed to compile test code. Compile scope means needed to compile production and test code. These are both related to when a dependency is needed to compile. Provided and runtime scope are related to when a dependency is needed at runtime. So the way I see it, a compile transitive dependency should always override a test dependency but not provided or runtime. What do you mean by override? There is some technical debt here in terms of how scoping works. You really need a further scope classification like: Scope = compile classifier = test classifier = production Scope = runtime classifier = provided Something like this. You likely get the idea. Lost me
RE: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
Override the dependency defined in the POM, as Steve outline in his earlier response. Let me quote his explanation for ease of reference: E.g. if project P has test scoped dependency to a LIB1, and compile scoped dependency to LIB2, while LIB2 has compile scope dependency to LIB1, currently project P's war will wrongly end up without LIB1 included. In P one expects LIB1 to be available for testing, but that shouldn't affect availability of LIB1 as compile scoped transitive dependency, it should be the other way round, in this case scope of declared test scoped dependency should be broadened. I used the term override to descibe the situation when project P should have LIB1 defined as a compile dependency, when the POM actually defines it as test. But it should should only override for test dependencies, not for provided or runtime. As for your lost me comment I am not sure what you would like explained. Scope basically has multiple meanings. Compile/test are both related to requiring a dependency for compilation; runtime/provided are both related to requiring a dependency only at runtime. These multiple meanings are not suited to a single variable. --- Todd Thiessen -Original Message- From: Brian Fox [mailto:bri...@infinity.nu] Sent: Friday, May 08, 2009 11:00 AM To: Maven Users List Subject: Re: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism 2009/5/8 Todd Thiessen thies...@nortel.com Your argument Jorg I think applies to provided and runtime scope, but not to test. The root smell here lies in the definition of scope. Test scope means needed to compile test code. Compile scope means needed to compile production and test code. These are both related to when a dependency is needed to compile. Provided and runtime scope are related to when a dependency is needed at runtime. So the way I see it, a compile transitive dependency should always override a test dependency but not provided or runtime. What do you mean by override? There is some technical debt here in terms of how scoping works. You really need a further scope classification like: Scope = compile classifier = test classifier = production Scope = runtime classifier = provided Something like this. You likely get the idea. Lost me - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
