----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> 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 transport > implementation would assume I've got the appropriate third-party classes on > 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. -steve
