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]
