I renamed the thread to better reflect the nature of this discussion. I have a few questions here:
1) If an application uses binding.ejb, what would the dependency look like? 2) Where are the databinding modules being aggregated? 3) Is the java component support in tuscany-runtime? Thanks, Raymond From: ant elder Sent: Tuesday, July 01, 2008 8:04 AM To: [email protected] Subject: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes On Tue, Jul 1, 2008 at 12:09 PM, Simon Nash <[EMAIL PROTECTED]> wrote: ant elder wrote: On Sun, Jun 15, 2008 at 8:52 AM, ant elder <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: On Fri, Jun 13, 2008 at 10:08 PM, Mike Edwards <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: <snip> b) A variety of functional components, that represent sets of coherent functions. Each consists of a series of the basic modules, aggregated together. Their function in life is to assist developers of applications that embed some level of Tuscany capability (including tools, Tuscany itself and so on) These are probably not agreed by folk today - we have work to do here to define these. You demonstrate the problem in your example above - you want "Basic Web Services" separate from "Web Services Security" - but for an end user, the step from using the first to using the second is a trivial addition of @required="integrity" to the SCDL. Anyone care to have a go at defining these compoennts? Thats taking a different tack to the launcher appraoch but maybe we need both and this approach would be easier for embedders so ok to move things long I'll try an initial stab at it: 1) tuscany-scdl4j An aggregated jar containing _all_ the model and stax processor classes which can be used by tools etc for for reading/writing scdl without booting a runtime. It includes all the extension classes as they generally don't drag in any other dependencies so its not really any problem to incude them. The only required dependency would be on stax, maybe some optional dependencies like wsdl4j as the wsdl extension may need that. Not sure if any of the contribution modules should be included, would have to investigate that a bit. 2) tuscany-runtime An aggregated jar containing the minimum modules to start a runtime able to run something like the simple calculator sample. Has dependencies on tuscany-scdl4j and minimal other jars - geronimo-commonj_1.1_spec, cglib, jaxb etc. 3) tuscany-api An aggregated jar containing everything tuscany/sca applications might need to compile - sca-api, SCADomain class from host-embedded, node2-api, jsp taglib etc. Has no external dependencies. 4) Single jars for all the binding and implementation type extensions which add the capability to the minimal tuscany-runtime. We're already starting to get these with the way extensions are being structured nowadays - binding-jsonrpc-runtime, binding-ejb-runtime, implementation-widget-runtime etc. The above would make life for embedders much easier like the Tuscany-Geronimo integration code (or JBoss when they come along) less likely to break over releases as we add remove modules. ...ant No comments on this after a couple of weeks so I'll go start trying it. ...ant > I'd like to help with this. Please post an update here when you have something that others can look at and get involved with. Simon Ok, in r673092 there's some minimal aggregate jars which get the calculator sample running. - tuscany-api which has the application compile dependencies - the sca-api and Tuscany SCADomain api classes - tuscany-scdl4j which has the model and stax processor classes - tuscany-runtime2 which has the runtime classes to needed to run Tuscany and just Java implementation types And there's a sample/calculator2 which is the calculator sample using these new modules. The output of "mvn dependency:tree" in calculator2 shows all the jars needed to run the sample: [INFO] org.apache.tuscany.sca:sample-calculator2:jar:1.4-SNAPSHOT [INFO] +- org.apache.tuscany.sca:tuscany-api:jar:1.4-SNAPSHOT:compile [INFO] +- org.apache.tuscany.sca:tuscany-scdl4j:jar:1.4-SNAPSHOT:runtime [INFO] | +- javax.xml.stream:stax-api:jar:1.0-2:runtime [INFO] | \- org.codehaus.woodstox:wstx-asl:jar:3.2.1:runtime [INFO] +- org.apache.tuscany.sca:tuscany-runtime2:jar:1.4-SNAPSHOT:runtime [INFO] | +- xml-apis:xml-apis:jar:1.3.03:runtime [INFO] | +- asm:asm-all:jar:3.1:runtime [INFO] | +- javax.jws:jsr181-api:jar:1.0-MR1:runtime [INFO] | +- javax.xml.bind:jaxb-api:jar:2.1:runtime [INFO] | +- org.jvnet.jaxb.reflection:jaxb2-reflection:jar:2.1.4:runtime [INFO] | +- javax.annotation:jsr250-api:jar:1.0:runtime [INFO] | +- org.apache.geronimo.specs:geronimo-commonj_1.1_spec:jar:1.0:runtime [INFO] | +- javax.activation:activation:jar:1.1:runtime [INFO] | +- org.apache.ws.commons.schema:XmlSchema:jar:1.3.2:runtime [INFO] | +- com.sun.xml.bind:jaxb-impl:jar:2.1.7:runtime [INFO] | +- cglib:cglib-nodep:jar:2.1_3:runtime [INFO] | \- javax.xml.ws:jaxws-api:jar:2.1:runtime [INFO] \- junit:junit:jar:4.2:test >From that output it looks like there are still dependencies being pulled in >that could be removed or made optional. ...ant
