Thanks for participating, most of these sound like good ideas but I'm not convinced about (3) as the aggregate jars are about more than just managing Maven dependencies. How about for now we keep them as aggregate jars and re-review this once they're more complete?
...ant On Wed, Jul 2, 2008 at 3:04 AM, Raymond Feng <[EMAIL PROTECTED]> wrote: > 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> > > *-*<http://svn.apache.org/repos/asf/tuscany/sandbox/sebastien/distribution/base/pom.xml#> > <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 <[EMAIL PROTECTED]> > *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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> >> *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 <[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 >> >> >
