axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: JMS transport not in 1.1 binary distribution
Date Wed, 08 Jan 2003 01:43:02 GMT

----- Original Message -----
From: <>
To: <>
Cc: <>
Sent: Monday, January 06, 2003 17:54
Subject: RE: JMS transport not in 1.1 binary distribution

> <Just Kevin's Opinion>
> The ideal solution would be for me as a user to simply specify the
> transport/adapter in the wsdd file and make sure weblogic.jar (or
> jboss.jar, or whatever) is on the classpath. The developer of the
> implementation would assume I've got the appropriate third-party classes
> my classpath.

This would be good.

> The transport interface classes would be in axis.jar (or some other
> axis-supplied jar maybe similar to the 'optional.jar' that Ant supplies) -
> but not something I have to build.

I'd rather extensions which are vendor specific.

> The Ant "optional.jar" seems like a good model - they have all kinds of
> third-party interface code in there. The advantage of a single jar is both
> you have to download fewer files and the configuration is easier to manage
> over time.

Got some news for you there. Ant1.6 kills optional jar in favour of many
jars, each one stating what it depends on: 'ant-junit.jar',
'ant-xalain.jar', ... The reason for that is classpaths, and to let people
<taskdef> optional tasks, the the libraries for which can live in the
project's on lib dir; no more 'copy this to ant/lib' actions. Before
everyone panics, when ant1.6 ships we will also have an XML descriptor to
list the tasks, dataypes, matchers and other ant extensions in jars.

Similarly, Ant1.5 adds a very big 'dont call us this is not our problem'
message when <taskdef> fails, because too many people did things like
 -didnt have dependencies like junit.jar in place
 -rebuilt ant without the jars in place then blamed us
 -filed bugreps complaining tasks were broken.

FYI, the ant build process is

-whoever does the build has to have every library, even the obscure
commercial ones
-everying goes into the optional.jar or broken up successors
-Someone reverse engineered (somehow) an emulation jar that exports stub
implementations of all classes and methods used. This is no good for
distributions, as all the constants are wrong, but it is useful in
development, and for things like xdoclet.

The core point is that the more conditional dependencies you have, the
harder it is to do a release build.


View raw message