On Fri, May 14, 2010 at 11:17 AM, ant elder <[email protected]> wrote: > I had a question yesterday about the makeup of the tuscany-base jar > and the answer is so far its mainly been put together with just things > i happened to find useful or look reasonable so i wonder if we should > be a bit more consistent with it if users are going to be depending on > it. > > You can see all the dependencies it has by looking in the pom.xml but > the main things included right now are: > > all tuscany core and base sca assembly > interface.java > implementation.java > interface.wsdl > binding.ws using jaxws-ri impl > binding.rmi > distributed domain and binding.sca using hazelcast > implementation-web > implementation-web jax-rs support with wink dependencies excluded > implementation-web stripes support with stripes dependencies excluded > host-jetty with dependencies excluded > contribution-osgi/implementation-osgi/node-impl-osgi/extensibility-equinox/node-launcher-equinox > with all dependencies excluded > > It has all the JDK6 included dependencies as provided scope so all the > gives dependencies jars of: asm, cglib, and XmlSchema, wsdl4j, and > hazelcast. > > The logic for what is there went something like this:- include minimum > base to to get simplest implementation.jar component running in jdk6 > and then anything that had no dependencies or only dependencies that > are already required, or anything where the dependencies could > reasonably be assumed to be already in the environment so they can be > excluded (eg jetty, osgi, stripes). Following that logic the > distributed domain support with hazelcast shouldn't really be there > but it is so i guess i just decided distributed domain support was > essential. > > So any comments on how better we could split things up? > > ...ant >
It depends what the objective of this jar is. For this kind of discussion we need to be clear what the objective is. If it's about creating a single stand-alone jar that supports the basic SCA function on top of JDK6 then it sounds like it's on the right lines. "basic" might be a better term than "base". A different content list is probably required for jars where we are expecting users to be able to switch in their own choice of extensions, for example stand-alone sca-api - as that's usually all you need to compile a contribution core function - The real common core stuff not including any replaceable extensions, such as binding-ws. stand-lone extension jars (actually some will be related through dependencies I expect) - such as binding-ws-axis2 or binding-ws-ri or binding-jms I think both objectives are valid but separate. Other users may have their own requirements to aggregate the Tuscany modules is slightly different ways so our approach should be open and straightforward enough for them to do this with minimal drama. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
