tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ant elder" <ant.el...@gmail.com>
Subject Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Date Tue, 01 Jul 2008 15:04:00 GMT
On Tue, Jul 1, 2008 at 12:09 PM, Simon Nash <nash@apache.org> wrote:

> ant elder wrote:
>
>>
>>
>> On Sun, Jun 15, 2008 at 8:52 AM, ant elder <ant.elder@gmail.com <mailto:
>> ant.elder@gmail.com>> wrote:
>>
>>
>>
>>    On Fri, Jun 13, 2008 at 10:08 PM, Mike Edwards
>>    <mike.edwards.inglenook@gmail.com
>>    <mailto:mike.edwards.inglenook@gmail.com>> 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

Mime
View raw message