tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raymond Feng" <enjoyj...@gmail.com>
Subject Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Date Tue, 01 Jul 2008 17:11:54 GMT
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?


From: ant elder 
Sent: Tuesday, July 01, 2008 8:04 AM
To: dev@tuscany.apache.org 
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 <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>>

       On Fri, Jun 13, 2008 at 10:08 PM, Mike Edwards

       <mailto:mike.edwards.inglenook@gmail.com>> wrote:


           b) A variety of functional components, that represent sets of
           coherent functions.

             Each consists of a series of the basic modules, aggregated
             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.


    No comments on this after a couple of weeks so I'll go start trying it.


  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.


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

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. 


View raw message