Re: [m2] Dependency Ordering Headache
Thanks everyone for your input. I'll be keeping an eye on http://jira.codehaus.org/browse/MNG-1412. If anyone has instructions for where to find the source for maven-artifact-ant and how to build it, I'd love to hear from you. I may need to figure out how to patch this in my environment before an official release becomes available. -kevin -- View this message in context: http://www.nabble.com/-m2--Dependency-Ordering-Headache-tf3668646s177.html#a10299839 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Dependency Ordering Headache
When I read things like this, I think some of the Maven people have never been working in the real corporate world. You cannot expect a project to stop for 6 month waiting for the next full release of Weblogic or any other product, just because there is no way on Maven to take a product patch into account. Try telling your manager that his flagship project must be delay half a year because your building tool does not like the way Weblogic distributes an emergency patch. I mean how fast would you think it would take to be asked to clean your desk and leave the building? J.A. Wayne Fay wrote: As a Weblogic customer, I'd complain until they resolve this issue. I agree entirely with Graham -- the fact that your dependency JARs must be ordered in a particular way to get a successful build should not be acceptable to you. Wayne -- View this message in context: http://www.nabble.com/-m2--Dependency-Ordering-Headache-tf3668646s177.html#a10305209 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Dependency Ordering Headache
I work in the corporate world every day, friend. As for incorporating a patch like this, if it is a fairly trivial patch (many are just a couple fixed class files), I would personally just unpack the affected jars, copy the patched files in, and repack them with adjusted version numbers. I'm not saying this is ideal, but its not a 6mo delay either... Wayne On 5/3/07, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: When I read things like this, I think some of the Maven people have never been working in the real corporate world. You cannot expect a project to stop for 6 month waiting for the next full release of Weblogic or any other product, just because there is no way on Maven to take a product patch into account. Try telling your manager that his flagship project must be delay half a year because your building tool does not like the way Weblogic distributes an emergency patch. I mean how fast would you think it would take to be asked to clean your desk and leave the building? J.A. Wayne Fay wrote: As a Weblogic customer, I'd complain until they resolve this issue. I agree entirely with Graham -- the fact that your dependency JARs must be ordered in a particular way to get a successful build should not be acceptable to you. Wayne -- View this message in context: http://www.nabble.com/-m2--Dependency-Ordering-Headache-tf3668646s177.html#a10305209 Sent from the Maven - Users mailing list archive at Nabble.com. - 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: [m2] Dependency Ordering Headache
Yes indeed, you could repackage the libraries by hand. But then WL can blame you for any further problem as you are hand crafting the libraries as oppose to using them as provided. Never mind if the library involves signed classes of any sort. I am not trying to defend WL or anyone else. But where I get a little of a peeve is when people say no the only way is this way and everyone else in the world is wrong and no other way should be allowed. That only slows down adoption. And Maven has very many great things for that to happen. J.A Wayne Fay wrote: I work in the corporate world every day, friend. As for incorporating a patch like this, if it is a fairly trivial patch (many are just a couple fixed class files), I would personally just unpack the affected jars, copy the patched files in, and repack them with adjusted version numbers. I'm not saying this is ideal, but its not a 6mo delay either... Wayne On 5/3/07, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: When I read things like this, I think some of the Maven people have never been working in the real corporate world. You cannot expect a project to stop for 6 month waiting for the next full release of Weblogic or any other product, just because there is no way on Maven to take a product patch into account. Try telling your manager that his flagship project must be delay half a year because your building tool does not like the way Weblogic distributes an emergency patch. I mean how fast would you think it would take to be asked to clean your desk and leave the building? J.A. Wayne Fay wrote: As a Weblogic customer, I'd complain until they resolve this issue. I agree entirely with Graham -- the fact that your dependency JARs must be ordered in a particular way to get a successful build should not be acceptable to you. Wayne -- View this message in context: http://www.nabble.com/-m2--Dependency-Ordering-Headache-tf3668646s177.html#a10305209 Sent from the Maven - Users mailing list archive at Nabble.com. - 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] -- View this message in context: http://www.nabble.com/-m2--Dependency-Ordering-Headache-tf3668646s177.html#a10308039 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Dependency Ordering Headache
I may be speaking out of turn here, but I think that maven does not have a lack of order, it simply does not allow you, the user, to control the order. Thus builds are reproducable reliably, the order does not change from one build to another. This, however, is academic. If your classpath requires order then it means there are conflicts. Conflicts are never good - let us imagine for a moment we have an interface com.mypackage.MyInter Now, this is defined in jarA and jarB and jarB contains a class com.other.MyObj. It follows that if at some point in time the signature of MyInter changes in jarA and yet jarA is first in the classpath then the class com.other.MyObj will fail to load, as it no longer implements MyInter, even though it has defined it correctly internally. Badness. Andy On 1 May 2007, at 00:14, gridplan wrote: Granted. There is obviously more than one way to roll out a fix. But in my view it's not WebLogic's job to change their approach because Maven does not embrace the notion of an ordered classpath. I don't hold as self- evident the idea that Builds which depend upon the ordering of artifacts in the classpath is one of those things which are certainly not a best practice. There is nothing wrong with order. It is central to what it means to be a Java classpath. It is how Java's classloader knows where to look for the classes it loads. It's the key to predictability, which is not only a good thing, it is essential to what I'm trying to do. Unfortunately, the classpath Maven generates is not always so well-behaved and has caused me some major grief. Hard as it may be to believe, I want to like Maven. But I also want some control over it when it demonstrates its ability to get things wrong. -kevin I disagree. The Maven model would simply require that Weblogic produce updated JARs with the patches applied, and you would roll the versions in the poms (or simply import a single pom provided by Weblogic where they manage versions and artifacts for you) and rebuild your project. This sounds far easier (and far more consistent) than depending upon jars which may or may not currently exist in a given Weblogic build. Maven is not simply another build tool like Ant or Make. It is also a vehicle for presenting and delivering build management best practices as interpreted by the Maven Dev team/PMC. Builds which depend upon the ordering of artifacts in the classpath is one of those things which are certainly not a best practice, just like code patches, and so these features are not available. As always, this is simply my opinion. Someone who is actually in the Maven Dev team may respond and say I'm completely wrong on these issues, and that support for patches and ordering of classpath items is on the TODO list, but I generally doubt it. ;-) Wayne -- View this message in context: http://www.nabble.com/-m2--Dependency- Ordering-Headache-tf3668646s177.html#a10262265 Sent from the Maven - Users mailing list archive at Nabble.com. - 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: [m2] Dependency Ordering Headache
On 5/1/07, Andrew Williams [EMAIL PROTECTED] wrote: I may be speaking out of turn here, but I think that maven does not have a lack of order, it simply does not allow you, the user, to control the order. Thus builds are reproducable reliably, the order does not change from one build to another. And yet the OP says that the order changes on Solaris vs. WindowsXP... There is some discussion of (and 20+ votes for) dependency sorting in classpath on http://jira.codehaus.org/browse/MNG-1412 . -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Dependency Ordering Headache
My apologies, I must just have been lucky with the orders being static on my projects. Andy On 1 May 2007, at 13:50, Wendy Smoak wrote: On 5/1/07, Andrew Williams [EMAIL PROTECTED] wrote: I may be speaking out of turn here, but I think that maven does not have a lack of order, it simply does not allow you, the user, to control the order. Thus builds are reproducable reliably, the order does not change from one build to another. And yet the OP says that the order changes on Solaris vs. WindowsXP... There is some discussion of (and 20+ votes for) dependency sorting in classpath on http://jira.codehaus.org/browse/MNG-1412 . -- Wendy - 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: [m2] Dependency Ordering Headache
On 5/1/07, Wendy Smoak [EMAIL PROTECTED] wrote: There is some discussion of (and 20+ votes for) dependency sorting in classpath on http://jira.codehaus.org/browse/MNG-1412 . Now its 30+ votes... And appears scheduled for 2.1.x. Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Dependency Ordering Headache
On Mon, April 30, 2007 11:15 am, gridplan wrote: I'm having a terrible time trying to convert a project that uses Ant to one that uses maven (2.0.6). The classpath in my build.xml has a specific ordering of Jars that must be followed in order for it to compile. To be honest, I think there is your problem. If order matters, it's probably because some jars contain conflicting code with other jars. The solution here is to fix the jars, not work around it in the build system. I have seen a number of projects who, for convenience, package up all their dependencies into an uberjar. Works great if their uberjar is your only dependency, but is a complete nightmare if you depend on code externally that is included in the uberjar. Rather specify the build system dependencies properly in maven, and this problem will go away. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Dependency Ordering Headache
Hi Graham, I don't think I can disentangle the dependencies so easily. With WebLogic server, the way one sets up a build environment is to source a file (usually setDomainEnv.cmd or setDomainEnv.sh -- the same file incidentally their app server sources on start-up). It adds a dozen or so WebLogic jars to the classpath (ignore the variables): $BEA_HOME/patch_weblogic920/profiles/default/sys_manifest_classpath/weblogic_patch.jar $BEA_HOME/jrockit90_150_04/lib/tools.jar $WL_HOME/server/lib/weblogic_sp.jar $WL_HOME/server/lib/weblogic.jar $WL_HOME/server/lib/webservices.jar $WL_HOME/servicebus/lib/sb-public.jar $WL_HOME/servicebus/lib/sb-common.jar $WL_HOME/servicebus/lib/sb-internal.jar $WL_HOME/servicebus/lib/sb-core.jar $WL_HOME/integration/common/lib/wli-common.jar $WL_HOME/integration/common/lib/wli-common-public.jar $WL_HOME/platform/lib/p13n/p13n_system.jar $WL_HOME/common/p13n/lib/p13n_common.jar $WL_HOME/server/lib/wlxbean.jar $WL_HOME/server/lib/apachexmlbeansutil.jar $WL_HOME/server/lib/xquery.jar $WL_HOME/server/lib/binxml.jar $WL_HOME/common/lib/log4j.jar $WL_HOME/servicebus/lib/uddi_library.jar $WL_HOME/servicebus/lib/uddi_client_v3.jar $WL_HOME/servicebus/lib/version.jar $WL_HOME/common/eval/pointbase/lib/pbembedded51.jar $WL_HOME/common/eval/pointbase/lib/pbupgrade51.jar $WL_HOME/common/eval/pointbase/lib/pbclient51.jar $WL_HOME/server/lib/xqrl.jar At that point a build.xml is free to reference any WebLogic class or WebLogic-specific Ant task it needs. I can't begin to guess why WebLogic chose this particular ordering of Jars, but it is apparently crucial. If I deviate from this prescribed order, the compilation will fail. Best, -kevin Graham Leggett wrote: On Mon, April 30, 2007 11:15 am, gridplan wrote: To be honest, I think there is your problem. If order matters, it's probably because some jars contain conflicting code with other jars. The solution here is to fix the jars, not work around it in the build system. I have seen a number of projects who, for convenience, package up all their dependencies into an uberjar. Works great if their uberjar is your only dependency, but is a complete nightmare if you depend on code externally that is included in the uberjar. Rather specify the build system dependencies properly in maven, and this problem will go away. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-m2--Dependency-Ordering-Headache-tf3668646s177.html#a10252984 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Dependency Ordering Headache
As a Weblogic customer, I'd complain until they resolve this issue. I agree entirely with Graham -- the fact that your dependency JARs must be ordered in a particular way to get a successful build should not be acceptable to you. Wayne On 4/30/07, gridplan [EMAIL PROTECTED] wrote: Hi Graham, I don't think I can disentangle the dependencies so easily. With WebLogic server, the way one sets up a build environment is to source a file (usually setDomainEnv.cmd or setDomainEnv.sh -- the same file incidentally their app server sources on start-up). It adds a dozen or so WebLogic jars to the classpath (ignore the variables): $BEA_HOME/patch_weblogic920/profiles/default/sys_manifest_classpath/weblogic_patch.jar $BEA_HOME/jrockit90_150_04/lib/tools.jar $WL_HOME/server/lib/weblogic_sp.jar $WL_HOME/server/lib/weblogic.jar $WL_HOME/server/lib/webservices.jar $WL_HOME/servicebus/lib/sb-public.jar $WL_HOME/servicebus/lib/sb-common.jar $WL_HOME/servicebus/lib/sb-internal.jar $WL_HOME/servicebus/lib/sb-core.jar $WL_HOME/integration/common/lib/wli-common.jar $WL_HOME/integration/common/lib/wli-common-public.jar $WL_HOME/platform/lib/p13n/p13n_system.jar $WL_HOME/common/p13n/lib/p13n_common.jar $WL_HOME/server/lib/wlxbean.jar $WL_HOME/server/lib/apachexmlbeansutil.jar $WL_HOME/server/lib/xquery.jar $WL_HOME/server/lib/binxml.jar $WL_HOME/common/lib/log4j.jar $WL_HOME/servicebus/lib/uddi_library.jar $WL_HOME/servicebus/lib/uddi_client_v3.jar $WL_HOME/servicebus/lib/version.jar $WL_HOME/common/eval/pointbase/lib/pbembedded51.jar $WL_HOME/common/eval/pointbase/lib/pbupgrade51.jar $WL_HOME/common/eval/pointbase/lib/pbclient51.jar $WL_HOME/server/lib/xqrl.jar At that point a build.xml is free to reference any WebLogic class or WebLogic-specific Ant task it needs. I can't begin to guess why WebLogic chose this particular ordering of Jars, but it is apparently crucial. If I deviate from this prescribed order, the compilation will fail. Best, -kevin Graham Leggett wrote: On Mon, April 30, 2007 11:15 am, gridplan wrote: To be honest, I think there is your problem. If order matters, it's probably because some jars contain conflicting code with other jars. The solution here is to fix the jars, not work around it in the build system. I have seen a number of projects who, for convenience, package up all their dependencies into an uberjar. Works great if their uberjar is your only dependency, but is a complete nightmare if you depend on code externally that is included in the uberjar. Rather specify the build system dependencies properly in maven, and this problem will go away. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-m2--Dependency-Ordering-Headache-tf3668646s177.html#a10252984 Sent from the Maven - Users mailing list archive at Nabble.com. - 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: [m2] Dependency Ordering Headache
Hi Wayne, Thank you for responding. I would say it's more a shortcoming of Maven if I'm not given control over how Jars are ordered on the classpath. Sometimes it's necessary to specify the order in which Jars appear on the classpath. For example, the first Jar, $BEA_HOME/patch_weblogic920/profiles/default/sys_manifest_classpath/weblogic_patch.jar is a placeholder. It doesn't even exist on my system. But I see why WebLogic put it there. If they ever needed to issue a patch, they'd want the Jar containing those patched classes to be picked up first. If I wanted to do the equivalent in my pom.xml, how would I order the dependencies so that Jar was picked up first? What troubles me even more than my seeming lack of control over ordering is the fact that the same POM produces a different classpath under Solaris than it does under Windows XP. In my view, the ordering should be consistent from OS to OS. Thanks again, -kevin As a Weblogic customer, I'd complain until they resolve this issue. I agree entirely with Graham -- the fact that your dependency JARs must be ordered in a particular way to get a successful build should not be acceptable to you. Wayne On 4/30/07, gridplan [EMAIL PROTECTED] wrote: Hi Graham, I don't think I can disentangle the dependencies so easily. With WebLogic server, the way one sets up a build environment is to source a file (usually setDomainEnv.cmd or setDomainEnv.sh -- the same file incidentally their app server sources on start-up). It adds a dozen or so WebLogic jars to the classpath (ignore the variables): $BEA_HOME/patch_weblogic920/profiles/default/sys_manifest_classpath/weblogic_patch.jar $BEA_HOME/jrockit90_150_04/lib/tools.jar $WL_HOME/server/lib/weblogic_sp.jar $WL_HOME/server/lib/weblogic.jar $WL_HOME/server/lib/webservices.jar $WL_HOME/servicebus/lib/sb-public.jar $WL_HOME/servicebus/lib/sb-common.jar $WL_HOME/servicebus/lib/sb-internal.jar $WL_HOME/servicebus/lib/sb-core.jar $WL_HOME/integration/common/lib/wli-common.jar $WL_HOME/integration/common/lib/wli-common-public.jar $WL_HOME/platform/lib/p13n/p13n_system.jar $WL_HOME/common/p13n/lib/p13n_common.jar $WL_HOME/server/lib/wlxbean.jar $WL_HOME/server/lib/apachexmlbeansutil.jar $WL_HOME/server/lib/xquery.jar $WL_HOME/server/lib/binxml.jar $WL_HOME/common/lib/log4j.jar $WL_HOME/servicebus/lib/uddi_library.jar $WL_HOME/servicebus/lib/uddi_client_v3.jar $WL_HOME/servicebus/lib/version.jar $WL_HOME/common/eval/pointbase/lib/pbembedded51.jar $WL_HOME/common/eval/pointbase/lib/pbupgrade51.jar $WL_HOME/common/eval/pointbase/lib/pbclient51.jar $WL_HOME/server/lib/xqrl.jar At that point a build.xml is free to reference any WebLogic class or WebLogic-specific Ant task it needs. I can't begin to guess why WebLogic chose this particular ordering of Jars, but it is apparently crucial. If I deviate from this prescribed order, the compilation will fail. Best, -kevin -- View this message in context: http://www.nabble.com/-m2--Dependency-Ordering-Headache-tf3668646s177.html#a10259457 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Dependency Ordering Headache
I disagree. The Maven model would simply require that Weblogic produce updated JARs with the patches applied, and you would roll the versions in the poms (or simply import a single pom provided by Weblogic where they manage versions and artifacts for you) and rebuild your project. This sounds far easier (and far more consistent) than depending upon jars which may or may not currently exist in a given Weblogic build. Maven is not simply another build tool like Ant or Make. It is also a vehicle for presenting and delivering build management best practices as interpreted by the Maven Dev team/PMC. Builds which depend upon the ordering of artifacts in the classpath is one of those things which are certainly not a best practice, just like code patches, and so these features are not available. As always, this is simply my opinion. Someone who is actually in the Maven Dev team may respond and say I'm completely wrong on these issues, and that support for patches and ordering of classpath items is on the TODO list, but I generally doubt it. ;-) Wayne On 4/30/07, gridplan [EMAIL PROTECTED] wrote: Hi Wayne, Thank you for responding. I would say it's more a shortcoming of Maven if I'm not given control over how Jars are ordered on the classpath. Sometimes it's necessary to specify the order in which Jars appear on the classpath. For example, the first Jar, $BEA_HOME/patch_weblogic920/profiles/default/sys_manifest_classpath/weblogic_patch.jar is a placeholder. It doesn't even exist on my system. But I see why WebLogic put it there. If they ever needed to issue a patch, they'd want the Jar containing those patched classes to be picked up first. If I wanted to do the equivalent in my pom.xml, how would I order the dependencies so that Jar was picked up first? What troubles me even more than my seeming lack of control over ordering is the fact that the same POM produces a different classpath under Solaris than it does under Windows XP. In my view, the ordering should be consistent from OS to OS. Thanks again, -kevin As a Weblogic customer, I'd complain until they resolve this issue. I agree entirely with Graham -- the fact that your dependency JARs must be ordered in a particular way to get a successful build should not be acceptable to you. Wayne On 4/30/07, gridplan [EMAIL PROTECTED] wrote: Hi Graham, I don't think I can disentangle the dependencies so easily. With WebLogic server, the way one sets up a build environment is to source a file (usually setDomainEnv.cmd or setDomainEnv.sh -- the same file incidentally their app server sources on start-up). It adds a dozen or so WebLogic jars to the classpath (ignore the variables): $BEA_HOME/patch_weblogic920/profiles/default/sys_manifest_classpath/weblogic_patch.jar $BEA_HOME/jrockit90_150_04/lib/tools.jar $WL_HOME/server/lib/weblogic_sp.jar $WL_HOME/server/lib/weblogic.jar $WL_HOME/server/lib/webservices.jar $WL_HOME/servicebus/lib/sb-public.jar $WL_HOME/servicebus/lib/sb-common.jar $WL_HOME/servicebus/lib/sb-internal.jar $WL_HOME/servicebus/lib/sb-core.jar $WL_HOME/integration/common/lib/wli-common.jar $WL_HOME/integration/common/lib/wli-common-public.jar $WL_HOME/platform/lib/p13n/p13n_system.jar $WL_HOME/common/p13n/lib/p13n_common.jar $WL_HOME/server/lib/wlxbean.jar $WL_HOME/server/lib/apachexmlbeansutil.jar $WL_HOME/server/lib/xquery.jar $WL_HOME/server/lib/binxml.jar $WL_HOME/common/lib/log4j.jar $WL_HOME/servicebus/lib/uddi_library.jar $WL_HOME/servicebus/lib/uddi_client_v3.jar $WL_HOME/servicebus/lib/version.jar $WL_HOME/common/eval/pointbase/lib/pbembedded51.jar $WL_HOME/common/eval/pointbase/lib/pbupgrade51.jar $WL_HOME/common/eval/pointbase/lib/pbclient51.jar $WL_HOME/server/lib/xqrl.jar At that point a build.xml is free to reference any WebLogic class or WebLogic-specific Ant task it needs. I can't begin to guess why WebLogic chose this particular ordering of Jars, but it is apparently crucial. If I deviate from this prescribed order, the compilation will fail. Best, -kevin -- View this message in context: http://www.nabble.com/-m2--Dependency-Ordering-Headache-tf3668646s177.html#a10259457 Sent from the Maven - Users mailing list archive at Nabble.com. - 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: [m2] Dependency Ordering Headache
Granted. There is obviously more than one way to roll out a fix. But in my view it's not WebLogic's job to change their approach because Maven does not embrace the notion of an ordered classpath. I don't hold as self-evident the idea that Builds which depend upon the ordering of artifacts in the classpath is one of those things which are certainly not a best practice. There is nothing wrong with order. It is central to what it means to be a Java classpath. It is how Java's classloader knows where to look for the classes it loads. It's the key to predictability, which is not only a good thing, it is essential to what I'm trying to do. Unfortunately, the classpath Maven generates is not always so well-behaved and has caused me some major grief. Hard as it may be to believe, I want to like Maven. But I also want some control over it when it demonstrates its ability to get things wrong. -kevin I disagree. The Maven model would simply require that Weblogic produce updated JARs with the patches applied, and you would roll the versions in the poms (or simply import a single pom provided by Weblogic where they manage versions and artifacts for you) and rebuild your project. This sounds far easier (and far more consistent) than depending upon jars which may or may not currently exist in a given Weblogic build. Maven is not simply another build tool like Ant or Make. It is also a vehicle for presenting and delivering build management best practices as interpreted by the Maven Dev team/PMC. Builds which depend upon the ordering of artifacts in the classpath is one of those things which are certainly not a best practice, just like code patches, and so these features are not available. As always, this is simply my opinion. Someone who is actually in the Maven Dev team may respond and say I'm completely wrong on these issues, and that support for patches and ordering of classpath items is on the TODO list, but I generally doubt it. ;-) Wayne -- View this message in context: http://www.nabble.com/-m2--Dependency-Ordering-Headache-tf3668646s177.html#a10262265 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] dependency ordering
This discussion kinda overlaps with an issue I raised with the eclipse plugin: http://jira.codehaus.org/browse/MNG-1412 I think the order should be nearest first, and then the order specified in the pom. Mark On 14/11/05, Nigel Magnay [EMAIL PROTECTED] wrote: The artifact being generated is effectively a merge of several other artifacts of the same type - a WAR file. It's important to get the ordering right as the overwriting precidence matters. I was just thinking of needing an extra bit of user data, much like the properties you could put on dependencies in M1 that controlled things like whether the file got included in the manifest or not; a 'proper' ordering of all dependencies does sound harder (and maybe too hard to be always right in all circumstances..) On 11/14/05, Brett Porter [EMAIL PROTECTED] wrote: Can you describe what the relevance of the ordering is? There might be something already available. The suggestion of this tag is tricky, as how does dependencies brought in transitively get ordered? - Brett On 11/14/05, Nigel Magnay [EMAIL PROTECTED] wrote: Hi - I'm doing some processing with a custom mojo that relies on the dependency information to build an artifact, but the order of processing is important. Because MavenProject.getArtifacts() returns a set, this is unordered with respect to the pom.xml; I was wondering if it's possible to add extra information in the pom, something like ... dependency groupIdblah/groupId artifactIdthing/artifactId version3.8.1/version order1/order -- /dependency dependency groupIdwoo/groupId artifactIdyay/artifactId version3/version order2/order -- /dependency ... Is there a good way of tackling this? - 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] - 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: [m2] dependency ordering
But how does that help in the situation where you declare dependencies A and B, but both declare a dependency C at the same level? Is C first, second or third when ordered? I haven't looked at this issue, but an application should avoid classpath ordering at all costs. - Brett On 11/14/05, Mark Hobson [EMAIL PROTECTED] wrote: This discussion kinda overlaps with an issue I raised with the eclipse plugin: http://jira.codehaus.org/browse/MNG-1412 I think the order should be nearest first, and then the order specified in the pom. Mark On 14/11/05, Nigel Magnay [EMAIL PROTECTED] wrote: The artifact being generated is effectively a merge of several other artifacts of the same type - a WAR file. It's important to get the ordering right as the overwriting precidence matters. I was just thinking of needing an extra bit of user data, much like the properties you could put on dependencies in M1 that controlled things like whether the file got included in the manifest or not; a 'proper' ordering of all dependencies does sound harder (and maybe too hard to be always right in all circumstances..) On 11/14/05, Brett Porter [EMAIL PROTECTED] wrote: Can you describe what the relevance of the ordering is? There might be something already available. The suggestion of this tag is tricky, as how does dependencies brought in transitively get ordered? - Brett On 11/14/05, Nigel Magnay [EMAIL PROTECTED] wrote: Hi - I'm doing some processing with a custom mojo that relies on the dependency information to build an artifact, but the order of processing is important. Because MavenProject.getArtifacts() returns a set, this is unordered with respect to the pom.xml; I was wondering if it's possible to add extra information in the pom, something like ... dependency groupIdblah/groupId artifactIdthing/artifactId version3.8.1/version order1/order -- /dependency dependency groupIdwoo/groupId artifactIdyay/artifactId version3/version order2/order -- /dependency ... Is there a good way of tackling this? - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] dependency ordering
I think I general use case for ordered dependencies is when you need two different versions of one dependency for compilation. For example I have some utility project that provides functionality for framework A. My utility project can be used with version 1.x of A and 2.x - as A changed incompatible from 1.x to 2.x and as I don't want to split my project into different versions, I need some classes of 1.x and some of 2.x for compilation. In this case the ordering is important. Now, unfortunately, this scenario is not going to work with m2 directly as m2 only allows one version of a dependency in the classpath :( Carsten Nigel Magnay wrote: The artifact being generated is effectively a merge of several other artifacts of the same type - a WAR file. It's important to get the ordering right as the overwriting precidence matters. I was just thinking of needing an extra bit of user data, much like the properties you could put on dependencies in M1 that controlled things like whether the file got included in the manifest or not; a 'proper' ordering of all dependencies does sound harder (and maybe too hard to be always right in all circumstances..) On 11/14/05, Brett Porter [EMAIL PROTECTED] wrote: Can you describe what the relevance of the ordering is? There might be something already available. The suggestion of this tag is tricky, as how does dependencies brought in transitively get ordered? -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] dependency ordering
I was just looking at that and thinking that was probably the way I
should do it.. just seemed a shame that I couldn't attach some
arbitary property inside the dependency tag, but it's no biggie.
Nigel
On 11/14/05, Brett Porter [EMAIL PROTECTED] wrote:
Right - transitivity defeats the ability to do this.
What you need to do is specify the order in configuration to your
plugin (and still declare the dependencies normally).
wars
wargroupId:artifactId1/war
wargroupId:artifactId2/war
/wars
From this you can construct an artifact filter pretty easily and
filter the ${project.artifacts}. This is how the assembly plugin
works.
- Brett
On 11/14/05, Nigel Magnay [EMAIL PROTECTED] wrote:
The artifact being generated is effectively a merge of several other
artifacts of the same type - a WAR file. It's important to get the
ordering right as the overwriting precidence matters.
I was just thinking of needing an extra bit of user data, much like
the properties you could put on dependencies in M1 that controlled
things like whether the file got included in the manifest or not; a
'proper' ordering of all dependencies does sound harder (and maybe too
hard to be always right in all circumstances..)
On 11/14/05, Brett Porter [EMAIL PROTECTED] wrote:
Can you describe what the relevance of the ordering is? There might be
something already available.
The suggestion of this tag is tricky, as how does dependencies brought
in transitively get ordered?
- Brett
On 11/14/05, Nigel Magnay [EMAIL PROTECTED] wrote:
Hi -
I'm doing some processing with a custom mojo that relies on the
dependency information to build an artifact, but the order of
processing is important. Because MavenProject.getArtifacts() returns a
set, this is unordered with respect to the pom.xml; I was wondering if
it's possible to add extra information in the pom, something like
...
dependency
groupIdblah/groupId
artifactIdthing/artifactId
version3.8.1/version
order1/order --
/dependency
dependency
groupIdwoo/groupId
artifactIdyay/artifactId
version3/version
order2/order --
/dependency
...
Is there a good way of tackling this?
-
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]
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] dependency ordering
The artifact being generated is effectively a merge of several other artifacts of the same type - a WAR file. It's important to get the ordering right as the overwriting precidence matters. I was just thinking of needing an extra bit of user data, much like the properties you could put on dependencies in M1 that controlled things like whether the file got included in the manifest or not; a 'proper' ordering of all dependencies does sound harder (and maybe too hard to be always right in all circumstances..) On 11/14/05, Brett Porter [EMAIL PROTECTED] wrote: Can you describe what the relevance of the ordering is? There might be something already available. The suggestion of this tag is tricky, as how does dependencies brought in transitively get ordered? - Brett On 11/14/05, Nigel Magnay [EMAIL PROTECTED] wrote: Hi - I'm doing some processing with a custom mojo that relies on the dependency information to build an artifact, but the order of processing is important. Because MavenProject.getArtifacts() returns a set, this is unordered with respect to the pom.xml; I was wondering if it's possible to add extra information in the pom, something like ... dependency groupIdblah/groupId artifactIdthing/artifactId version3.8.1/version order1/order -- /dependency dependency groupIdwoo/groupId artifactIdyay/artifactId version3/version order2/order -- /dependency ... Is there a good way of tackling this? - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
