On Fri, May 14, 2010 at 2:40 PM, Simon Laws <[email protected]> wrote: > 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. >
The intention of current makeup was actually both of those - a minimal set of jars to get started with that is extensible so you can add more jars as you want to extend the functionality. And along with that the thoughts that: (1) it doesn't actually matter so much if it includes code that some use cases don't use as long as that doesn't drag in cause extra dependencies. (eg binding.rmi is included and only has a few k to the jar size. (2) its ok to include default implementations because if a different implementation of something is included on the classpath it can be made to override the default impl included in the base jar by using either ranking or be setting properties on the NodeFactory. (so base includes the JAXWS binding.ws impl but if the axis2 based one is included on the classpath that could be used instead. For (1) to work flexibly perhaps there needs to also be an easy way to disable things such as a NodeFactory property to disable an extension, eg so binding.rmi could be disabled so it wouldn't be recognized even if it was being used in a .composite ...ant If it gets broken down too much then it looses the benefits of aggregating the existing modules, so
