I agree with Dims, I don't think we want to get to far down the DLL/Jar Hell road by breaking things up in to LOTS of jar files. We already have saaj.jar and jaxrpc.jar, which is bad enough, not to mention the commons stuff....
That being said, for JMS and Jabber transports I would support having in their own jar files, because I don't think they will be main stream enough for general use. (Nothing personal James!) -- Tom Jordahl Macromedia Server Development -----Original Message----- From: Steve Loughran [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 07, 2003 8:46 PM To: [EMAIL PROTECTED] Subject: Re: JMS transport not in 1.1 binary distribution ----- Original Message ----- From: "James M Snell" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 06, 2003 21:11 Subject: RE: JMS transport not in 1.1 binary distribution > Btw, I personally think that individual Axis transports should be put into > their own jar files (e.g. axis-jms.jar, axis-local.jar, axis-http.jar, > etc) so if a particular application doesn't need a particular transport it > can simply remove the jar file altogether. But that's just my opinion +1. IMO we could generic this with a general 'axis extension jar'; have a descriptor that lists classes that implement some optional plugin interface that get autocalled on plug in as AxisEngine boots up. This would be useful for handlers, transports and other things. Speaking of extensions, say I had something I was looking to commit that was definately an axis extension. Where should it go in CVS. I propose a new /extensions subdir for these things, which are not proposals but not core codebase either. -steve
