tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raymond Feng" <enjoyj...@gmail.com>
Subject Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Date Wed, 02 Jul 2008 02:04:07 GMT
Hi,

I have looked into what you have checked in. I think we need to make the following refinements:

1) IMO, this kind of collection of tuscany modules is very similar to Eclipse features which
is the deployment descriptor of a set of Eclipse plugins. For the sake of discussion, let
me call them tuscany features. Two features should be able to contain the same module. 

2) The maven module for a tuscany feature should be just a pom project which declares the
contained tuscany modules as dependencies. 

<project> 
  <modelVersion>4.0.0</modelVersion> 
<artifactId>tuscany-scdl4j</artifactId> 
  <packaging>pom</packaging> 
- <dependencies>
           <!-- All the contained modules should be declared her as dependency -->
<dependencies>
</project>

The applications or other features can just declare the tuscany feature pom project as a dependency
to reference that feature. 

It seems that the distro prototype added by Sebastien has already taken the pom project approach.
See http://svn.apache.org/repos/asf/tuscany/sandbox/sebastien/distribution/base/pom.xml.

3) The feature module should not try to aggregate the modules into a new jar. As the new jar
will consume more storage, add duplicate classes and does not support overlay. 

4) We should add a new folder such as "features" to host all defined feature modules. IMO,
the "scdl4j" should be checked in under this "features" folder instead of "modules" which
hosts all the physical/atomic modules. The other option is to check them in under "distribution".
The distro should be just an aggregation of one or more features.

Thanks,
Raymond


From: ant elder 
Sent: Tuesday, July 01, 2008 4:51 PM
To: dev@tuscany.apache.org 
Subject: Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was:
Distribution zips and what they contain, was: SCA runtimes





On Tue, Jul 1, 2008 at 6:11 PM, Raymond Feng <enjoyjava@gmail.com> wrote:

  I renamed the thread to better reflect the nature of this discussion. 

Maybe we need a discussion thread on all the subject line fiddling that goes on these days
;-)
 

  I have a few questions here:

  1) If an application uses binding.ejb, what would the dependency look like?


I've not added ejb support yet but ideally it would be something like just adding the binding-ejb-runtime
jar, along with the standard tuscany-api, tuscany-scdl4j, and tuscany-runtime jars.



  2) Where are the databinding modules being aggregated?


The runtime jar currenlty contains the modules: tuscany-core-databinding, tuscany-databinding,
tuscany-databinding-jaxb
 
I guess the other ones like databinding-axiom, databinding-fastinfoset etc would be optional
ones that you'd add as single jars if required. Actually no, databinding-axiom and databinding-jaxb-axiom
could be included in a tuscany-runtime-ws-axis2 agregate jar that includes everything you
need to use web services. So something like a calculator-ws sample would use the jars: tuscany-api,
tuscany-scdl4j, tuscany-runtime, and tuscany-runtime-ws-axis2


  3) Is the java component support in tuscany-runtime?

Currently yes, it seemed to make sense to include that one implementation type.
 
WDYT? All this is quite embryonic so feel free to point out flaws or dive in with alternatives.




  Thanks,
  Raymond


  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>>
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