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: [email protected]
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
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
