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]
