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
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
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
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
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
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.
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
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
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
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
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,
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,
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
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
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
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
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
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
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
19 matches
Mail list logo
