Re: About transitive dependencies
Why do you declare a test (scope) dependency to B if you call it at runtime? AFIK, B should not be used when you compile C since you declared a test (scope) dependency. -- Guillaume Le 11/09/2011 08:25, JVerstry a écrit : I came across an issue I raised on StackOverflow: http://stackoverflow.com/questions/7373105/noclassdeffounderror-org-junit-afterclass-during-annotation-processing/7375380#7375380 I have a library B having a compile dependency (i.e. scope) on A. I have a library C having a test dependency (i.e. scope) on B. When I compile C, it includes B, but not A. And since C calls B calls A, it crashes at runtime. Apparently, this is how it should work according to the dependency scope (http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope). Yet, why should users of C explicitly declare a compile dependency to A, when we know at compile time that A will be required? Shouldn't the transitivity rule be that if you have such a transitive relationship, A should always be compile dependency of A? Or is there something I am missing? The problem is that the runtime crash is really late to be notified about this issue. It does not fit with the maven philosophy. Thanks, JVerstry - 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
About transitive dependencies
I came across an issue I raised on StackOverflow: http://stackoverflow.com/questions/7373105/noclassdeffounderror-org-junit-afterclass-during-annotation-processing/7375380#7375380 I have a library B having a compile dependency (i.e. scope) on A. I have a library C having a test dependency (i.e. scope) on B. When I compile C, it includes B, but not A. And since C calls B calls A, it crashes at runtime. Apparently, this is how it should work according to the dependency scope (http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope). Yet, why should users of C explicitly declare a compile dependency to A, when we know at compile time that A will be required? Shouldn't the transitivity rule be that if you have such a transitive relationship, A should always be compile dependency of A? Or is there something I am missing? The problem is that the runtime crash is really late to be notified about this issue. It does not fit with the maven philosophy. Thanks, JVerstry - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Question about transitive dependencies
I couldn't answer this for one of the devs in our team, so I thought I'd push the question to you all for any feedback you could provide. Any insight would be great... -joe -- -- Can anyone explain to me why transitive dependencies (even of dependencies that are specified as compile scope in your project) are put on the compile time classpath? It seems to me that transitive dependencies on the compile time classpath are useless at best, since you shouldn't need them to build the project. If you have a transitive dependency that you actually do need for your project to build, doesn't that pretty much by definition mean that it should be a direct dependency of your project instead? For example say that I have a project in which I specify the artifact Foo as a dependency, and foo has a dependency on project Bar. If my project doesn't have any direct dependency on Bar then there's no reason I need Bar to be in my classpath when I build, but having it there should be benign. But if my project does depend on Bar then just specifying Foo as a dependency could cause my project to build fine. It might not even be obvious that I'm getting my Bar dependency through Foo. This situation could potentially lead to bugs in my build or in my code if the Foo project decides to upgrade to Bar 2.0 and my code isn't compatible with it or if Foo drops its dependency on Bar altogether. So, is there a reason I'm missing for why you'd ever want to put a transitive dependency on your compile time classpath? Is there a way to cause a project to not put transitive dependencies on its compile time classpath but to keep them on the runtime classpath? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about transitive dependencies
This maybe an artifact of the fact that many plugins use the classpath for runtime constraints as well. -aps On 12/1/06, Heck, Joe [EMAIL PROTECTED] wrote: I couldn't answer this for one of the devs in our team, so I thought I'd push the question to you all for any feedback you could provide. Any insight would be great... -joe -- -- Can anyone explain to me why transitive dependencies (even of dependencies that are specified as compile scope in your project) are put on the compile time classpath? It seems to me that transitive dependencies on the compile time classpath are useless at best, since you shouldn't need them to build the project. If you have a transitive dependency that you actually do need for your project to build, doesn't that pretty much by definition mean that it should be a direct dependency of your project instead? For example say that I have a project in which I specify the artifact Foo as a dependency, and foo has a dependency on project Bar. If my project doesn't have any direct dependency on Bar then there's no reason I need Bar to be in my classpath when I build, but having it there should be benign. But if my project does depend on Bar then just specifying Foo as a dependency could cause my project to build fine. It might not even be obvious that I'm getting my Bar dependency through Foo. This situation could potentially lead to bugs in my build or in my code if the Foo project decides to upgrade to Bar 2.0 and my code isn't compatible with it or if Foo drops its dependency on Bar altogether. So, is there a reason I'm missing for why you'd ever want to put a transitive dependency on your compile time classpath? Is there a way to cause a project to not put transitive dependencies on its compile time classpath but to keep them on the runtime classpath? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- What lies behind us and what lies in front of us is of little concern to what lies within us. -Ralph Waldo Emerson
Re: Question about transitive dependencies
On 12/1/06, Alexander Sack [EMAIL PROTECTED] wrote: This maybe an artifact of the fact that many plugins use the classpath for runtime constraints as well. It's also possible to avoid this behavior, by declaring a scope of runtime on the dependency. That way, the module is *not* included on the compile time classpath (unless it's declared with compile scope by someone else you depend on), but *is* included for runtime (for example, in a webapp it'd be included in WEB-INF/lib). -aps Craig
Re: Question about transitive dependencies
And in fact, one can actually remove the transitive dependencies that are unwanted during the build classpath by declaring them in the POM as provided. I believe that fits his scenario where he is building against a library that has a transitive dependency that he does not want on his build classpath for whatever reason (packaging, etc.). -aps On 12/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 12/1/06, Alexander Sack [EMAIL PROTECTED] wrote: This maybe an artifact of the fact that many plugins use the classpath for runtime constraints as well. It's also possible to avoid this behavior, by declaring a scope of runtime on the dependency. That way, the module is *not* included on the compile time classpath (unless it's declared with compile scope by someone else you depend on), but *is* included for runtime (for example, in a webapp it'd be included in WEB-INF/lib). -aps Craig -- What lies behind us and what lies in front of us is of little concern to what lies within us. -Ralph Waldo Emerson
Re: Question about transitive dependencies
On 12/1/06, Alexander Sack [EMAIL PROTECTED] wrote: And in fact, one can actually remove the transitive dependencies that are unwanted during the build classpath by declaring them in the POM as provided. I believe that fits his scenario where he is building against a library that has a transitive dependency that he does not want on his build classpath for whatever reason (packaging, etc.). My understanding is the provided is essentially the opposite of runtime ... it leaves the dependency on the compile classpath but does not include it in the output. Whereas, runtime leaves it off the compile classpath but does include it in the output. In a web app, I'll want to declare the servlet API as a provided API so that I can use it in my own code. The servlet container will make it available to me at runtime, so I don't want to include it in the war. But, if I'm also using something like the MyFaces JSF implementation, which has both an API jar and an implementation JAR, I'll want the API jar declared as compile scope (so its on the classpath and included in the war), but the impl JAR declared runtime scope (so it is *not* possible for me to accidentally compile against classes in the MyFaces implementation, where I should be programming solely to JSF APIs), but is included so that the runtime app will work. Craig -aps Craig On 12/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 12/1/06, Alexander Sack [EMAIL PROTECTED] wrote: This maybe an artifact of the fact that many plugins use the classpath for runtime constraints as well. It's also possible to avoid this behavior, by declaring a scope of runtime on the dependency. That way, the module is *not* included on the compile time classpath (unless it's declared with compile scope by someone else you depend on), but *is* included for runtime (for example, in a webapp it'd be included in WEB-INF/lib). -aps Craig -- What lies behind us and what lies in front of us is of little concern to what lies within us. -Ralph Waldo Emerson
Re: Question about transitive dependencies
On 12/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 12/1/06, Alexander Sack [EMAIL PROTECTED] wrote: And in fact, one can actually remove the transitive dependencies that are unwanted during the build classpath by declaring them in the POM as provided. I believe that fits his scenario where he is building against a library that has a transitive dependency that he does not want on his build classpath for whatever reason (packaging, etc.). My understanding is the provided is essentially the opposite of runtime ... it leaves the dependency on the compile classpath but does not include it in the output. Whereas, runtime leaves it off the compile classpath but does include it in the output. Craig, yea, your right. My apologies. I'm using provided in one project as a way to avoid output not build scope since as the original poster stated, transitive dependencies are relatively harmless. My issue was in fact that transitive dependencies were being packaged and I wanted to remove them. Again, sorry for the confusion and thanks for the correction! :D -aps -- What lies behind us and what lies in front of us is of little concern to what lies within us. -Ralph Waldo Emerson
Re: Question about transitive dependencies
Say you depend on a ClassA from dependency A. Class A extends ClassB from dependency B. When you compile against ClassA you will also need ClassB even if you do not access it directly. That is the reason B is automatically put on your compile classpath if you depend on A. There are several ways to avoid that a dependency is passed transitively. You can change the scope to provided or set set optionaltrue/optional in the POM of the dependency . As far as I understand it, both have the same effect on the compile time classpath. If you want to exclude a transitive dependency in the POM that declares the dependency, you will need to use the exclusion mechanism. More information can be found in: * http://maven.apache.org/pom.html * http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html Tom On 12/1/06, Heck, Joe [EMAIL PROTECTED] wrote: I couldn't answer this for one of the devs in our team, so I thought I'd push the question to you all for any feedback you could provide. Any insight would be great... -joe -- -- Can anyone explain to me why transitive dependencies (even of dependencies that are specified as compile scope in your project) are put on the compile time classpath? It seems to me that transitive dependencies on the compile time classpath are useless at best, since you shouldn't need them to build the project. If you have a transitive dependency that you actually do need for your project to build, doesn't that pretty much by definition mean that it should be a direct dependency of your project instead? For example say that I have a project in which I specify the artifact Foo as a dependency, and foo has a dependency on project Bar. If my project doesn't have any direct dependency on Bar then there's no reason I need Bar to be in my classpath when I build, but having it there should be benign. But if my project does depend on Bar then just specifying Foo as a dependency could cause my project to build fine. It might not even be obvious that I'm getting my Bar dependency through Foo. This situation could potentially lead to bugs in my build or in my code if the Foo project decides to upgrade to Bar 2.0 and my code isn't compatible with it or if Foo drops its dependency on Bar altogether. So, is there a reason I'm missing for why you'd ever want to put a transitive dependency on your compile time classpath? Is there a way to cause a project to not put transitive dependencies on its compile time classpath but to keep them on the runtime classpath? - 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]
Curious about transitive dependencies
Hi, I noticed you work on support for so-called transitive dependencies in Maven 2. In the absence of support for it in the current Maven release we developed a solution for this specific to the needs in our projects. Now, I would like to compare your concepts with ours. But it seems to me you haven't yet published a coherent explanation of the mechanisms you invented to make transitive dependencies work. I try to outline our concepts in a nutshell. Maybe you can tell me how these relate to yours: We distinguish projects into components and assemblies. A Maven project.xml either defines an assembly or a component. A component has code and only defines its direct, i. e. non-transitive dependencies in its project.xml. An assembly, on the other hand, doesn't have code but only configuration. And, above all, it defines all the dependencies to the assembled components including the transitive ones in its own project.xml. Transitive dependencies can be distinguished from non-transitive ones in the assembly's project.xml by a dedicated dependency property. Duplicate dependencies are eliminated and version conflicts are resolved in the assembly's project.xml. We deal with almost 100 components, i. e. Maven projects which are being further developed by us plus a large number of third party jars. On top of this we currently manage some 20 assemblies. New versions of these components practically pop up every day. All in all, this means that we have a very dynamic configuration management environment. In order to a) create assemblies efficiently and reliably, and b) keep up with the advent of new versions of dependencies in the project.xml files of dependees we developed a gui tool that uses a configurable strategy to create and update project.xml files of assemblies and components. The tool... - has an integrated repositories browser, - allows to add and to remove non-transitive dependencies to/from a project - allows to browse transitive and non-transitive dependencies and dependees recursively to an arbitrary depth - allows to analyse version conflicts in the dependencies - computes the recursive hull of indirect dependencies if the project is an assembly - automatically resolves the conflicts by selecting the appropriate version per artifact according to a selectable default strategy and user-defined exception rules - offers two default strategies: one is to select the latest release of an artifact and the other is to select the SNAPSHOT if no other rule fires The latest release strategy can distinguish between repositories which are to be scanned for the latest release available and those which are not. If the latest release is desired for an artifact that resides in a repository which must not be scanned, the search for the latest release is confined to what is reachable in the dependency graph that roots in the project currently being maintained with the tool. The latter is useful for repositories of third party artifacts which are not under full control of the software project that uses it. Here, one doesn't want to fish the latest stuff only because it exists (put there by some foreigner) but only when at least one of one's own components' really states a need for it. User-definable exception rules allow to enforce a specific version for a dependency or to deprecate, i. e. exclude specific dependencies from the list of candidate versions. In the extreme, the user could thus nail down the version for each artifact if the default rules don't yield what he desires). The default strategy and the exception rules are saved as properties in the respective project.xml. This way they are available in the next tool session again. --End of the outline of our concepts I suspect that you have arrived at a similar but surely not identical solution. Especially, I wonder how you give full control to the assembler on which versions to use in conflict situations, because I don't think you distinguish between dedicated assembly projects and component projects, don't you? The other thing that worries me is: do you compute transitive dependencies each time again when you touch the project.xml with a Maven command? I'm not asking this because I'm afraid of performance, although that could be an issue, too. But I fear the indeterminism. Regards, Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
about transitive dependencies
Some simple (?) questions about (future) transitive dependencies : If jar A declares in his POM some dependencies, let's say jaxb, jaxbimpl and easymock - jaxb is used at build time - jaxb impl is needed at runtime - easymock is used in junit tests If my webapp depends on this jar, will transitive dependencies (when avaible) automatically set all this jar to 'war.bundle=true' ? Does maven have a way to know what a dependency is needed for ? If not, why allready having POM in repository if they will have to be updated ? Nico. Our name has changed. Please update your address book to the following format: [EMAIL PROTECTED]. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
