You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2008/07/01 19:11:54 UTC
Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
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?
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 <na...@apache.org> wrote:
ant elder wrote:
On Sun, Jun 15, 2008 at 8:52 AM, ant elder <ant.elder@gmail.com <ma...@gmail.com>> wrote:
On Fri, Jun 13, 2008 at 10:08 PM, Mike Edwards
<mike.edwards.inglenook@gmail.com
<ma...@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
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Thu, Jul 10, 2008 at 5:43 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> Let me take the two prototypes to build the "Collection" and compare them
> aspect by aspect.
>
> 1) Aggregated jar:
> http://svn.apache.org/repos/asf/tuscany/java/sca/modules/scdl4j/pom.xml
> 2) Feature/Distro:
> http://svn.apache.org/repos/asf/tuscany/sandbox/sebastien/distribution/base/pom.xml
>
> a. How is it declared as a maven module?
> 1. Create a jar module, add the contained modules as dependencies, and use
> the share plugin to aggregate/merge artifacts from the modules into the
> target jar. Fairly-complicated exclusion filters and transformers have to be
> defined.
> 2. Create a pom module, add the contained modules as dependencies, add the
> descriptor for the assembly and use the assembly plugin to assemble the
> modules in a fairly-straightforward way. The distro can also contain related
> samples.
>
> b. What will be produced?
> 1: An aggregated jar that physically contains all the classes from the
> modules and merged resource files.
> 2: A zip or tar.gz that contains the modules as original jars in the
> zip/tar.gz.
>
> c. How to declare dependency to reference them in maven?
> 1: Declare a dependency to the new jar (Will the contained modules be
> pulled in as transitive dependencies in addition to the aggregated jar?)
> 2. Declare a dependency to the new pom (The contained modules will be
> pulled in as transitive dependencies)
>
> d. How to use them in non-maven?
> 1. Add the new jar to the classpath
> 2. Unzip the zip/tar.gz so that all the contained modules will be on the
> classpath (or use our ant generator, or mvn dependency:copy-dependencies to
> copy the jars over)
>
> e. How to use them in OSGi?
> 1. The new jar becomes a new bundle and it needs to merge the MANIFEST.MF
> from the contained modules. (How do we deal with the import/export,
> versioning?)
> 2. The contained modules are the bundles, no new bundles are introduced.
>
> f. Can two collections contain the overlapping modules?
> 1. No (AFAIK from Ant's response)
> 2. Yes
>
> g. How to overlay the collections into an existing installation?
> 1. Add the new jar assuming there are no duplicate
> 2. Unzip the distro and either overwrite or ignore the duplicate modules
> during the unzip
>
> h. Footprint
> 1. It might pull in extra stuff not required, for example, to support WS,
> we need to pull in scdl4j.jar which contains models for EJBs or BEPL.
> 2. Can be potentially the bare minimum if we declare the feature/distro in
> a fine-grained fashion.
>
> Please help to complete the list and correctly judged.
>
>
I'm not ignoring this, just waiting to see what the request for user
feedback on the user lists shows up.
...ant
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Let me take the two prototypes to build the "Collection" and compare them
aspect by aspect.
1) Aggregated jar:
http://svn.apache.org/repos/asf/tuscany/java/sca/modules/scdl4j/pom.xml
2) Feature/Distro:
http://svn.apache.org/repos/asf/tuscany/sandbox/sebastien/distribution/base/pom.xml
a. How is it declared as a maven module?
1. Create a jar module, add the contained modules as dependencies, and use
the share plugin to aggregate/merge artifacts from the modules into the
target jar. Fairly-complicated exclusion filters and transformers have to be
defined.
2. Create a pom module, add the contained modules as dependencies, add the
descriptor for the assembly and use the assembly plugin to assemble the
modules in a fairly-straightforward way. The distro can also contain related
samples.
b. What will be produced?
1: An aggregated jar that physically contains all the classes from the
modules and merged resource files.
2: A zip or tar.gz that contains the modules as original jars in the
zip/tar.gz.
c. How to declare dependency to reference them in maven?
1: Declare a dependency to the new jar (Will the contained modules be pulled
in as transitive dependencies in addition to the aggregated jar?)
2. Declare a dependency to the new pom (The contained modules will be pulled
in as transitive dependencies)
d. How to use them in non-maven?
1. Add the new jar to the classpath
2. Unzip the zip/tar.gz so that all the contained modules will be on the
classpath (or use our ant generator, or mvn dependency:copy-dependencies to
copy the jars over)
e. How to use them in OSGi?
1. The new jar becomes a new bundle and it needs to merge the MANIFEST.MF
from the contained modules. (How do we deal with the import/export,
versioning?)
2. The contained modules are the bundles, no new bundles are introduced.
f. Can two collections contain the overlapping modules?
1. No (AFAIK from Ant's response)
2. Yes
g. How to overlay the collections into an existing installation?
1. Add the new jar assuming there are no duplicate
2. Unzip the distro and either overwrite or ignore the duplicate modules
during the unzip
h. Footprint
1. It might pull in extra stuff not required, for example, to support WS, we
need to pull in scdl4j.jar which contains models for EJBs or BEPL.
2. Can be potentially the bare minimum if we declare the feature/distro in a
fine-grained fashion.
Please help to complete the list and correctly judged.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Nash" <na...@apache.org>
Sent: Thursday, July 10, 2008 12:57 AM
To: <de...@tuscany.apache.org>
Cc: <us...@tuscany.apache.org>
Subject: Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany
extensions, was: Distribution zips and what they contain, was: SCA runtimes
> haleh mahbod wrote:
>> Hi Ant,
>> when you refer to a user, do you mean an embedder or an application
>> developer?
>> I am looking at [1] link where the first draft of functional components
>> were defined. I am assuming it is the embedders.
>>
>> Let's say I am an embedder wanting to use ejb. What are the steps that I
>> take with the component proposal vs the feature proposal to use ejb
>> feature? What are the pros and cons?
>> I am wondering if Tuscany embedders could share their experience here?
>> How are they solving this problem today that seems to be satisfactory for
>> them? Are we solving a problem that is not a real issue for Tuscany
>> embedders?
>>
> This would not affect someone who is developing a business application
> within a predefined environment. It would affect the packaging and
> distribution of that application with its dependency on Tuscany or
> some elements of Tuscany. In this sense I think it affects all
> Tuscany users, as any real application developed using Tuscany will
> need to be packaged and distributed before it can be used by others.
> It also affects embedders who want to incorporate all or part of
> Tuscany into platform or middleware offerings.
>
> I believe our packaging and distribution story needs to be as simple
> and consumable as possible, while providing flexibility for different
> selections of Tuscany functionality. Having this story depend on
> maven, an extension registry, or a launcher would fail to achieve the
> necessary level of simplicity. Packaging Tuscany as a manageable
> and fairly stable set of jar files/OSGi bundles whose purpose and
> dependencies are easy to understand does achieve the simplicity goal.
>
> Simon
>
>> [1]:
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/functional+components+at+runtime
>> Haleh
>> On 7/8/08, *ant elder* <antelder@apache.org
>> <ma...@apache.org>> wrote:
>>
>>
>>
>> On Mon, Jul 7, 2008 at 6:58 PM, Raymond Feng <enjoyjava@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> What are the benefits do we intend to provide for users with the
>> "components"-based aggregation? Simplicity and ease of use.
>>
>> Take the scdl jar aggregate as an example, a user wants to process
>> some scdl - things like reading and writing composites, perhaps
>> validating or manipulating the model programatically - they don't
>> know what binding or component types may be used they just want it
>> to work with what ever is in the scdl. Right now to do that they
>> need to explicitly use a vast list of tuscany modules and that list
>> of modules is continually changing over time so every time they pick
>> up a new build their code breaks. With the tuscany-scdl aggregate
>> they can just use that single jar and that will continue to work
>> over new builds and releases.
>>
>> IMHO, we can use the "feature" idea to address the requirements
>> of b) in Mike's original e-mail without the restriction of
>> non-overlapping and side-effort of producing new jars.
>> Meanwhile, the alignment of feature/distribution gives us the
>> flexibility to balance the granularities. A distribution is also
>> a feature and we can also easily group features into a
>> distribution.
>> The "feature" idea of having a Maven pom module instead of an
>> aggregate jar helps users when building with Maven but it doesn't
>> help non Maven users and it doesn't help with aspects out side of
>> the Maven build process such as packaging and distribution, users
>> are still going to have to deal with the vast and changing list of
>> individual Tuscany module jars.
>>
>> ...ant
>>
>>
>
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany
extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by Simon Nash <na...@apache.org>.
haleh mahbod wrote:
> Hi Ant,
>
> when you refer to a user, do you mean an embedder or an application
> developer?
> I am looking at [1] link where the first draft of functional components
> were defined. I am assuming it is the embedders.
>
> Let's say I am an embedder wanting to use ejb. What are the steps that I
> take with the component proposal vs the feature proposal to use ejb
> feature? What are the pros and cons?
>
> I am wondering if Tuscany embedders could share their experience here?
> How are they solving this problem today that seems to be satisfactory
> for them? Are we solving a problem that is not a real issue for Tuscany
> embedders?
>
This would not affect someone who is developing a business application
within a predefined environment. It would affect the packaging and
distribution of that application with its dependency on Tuscany or
some elements of Tuscany. In this sense I think it affects all
Tuscany users, as any real application developed using Tuscany will
need to be packaged and distributed before it can be used by others.
It also affects embedders who want to incorporate all or part of
Tuscany into platform or middleware offerings.
I believe our packaging and distribution story needs to be as simple
and consumable as possible, while providing flexibility for different
selections of Tuscany functionality. Having this story depend on
maven, an extension registry, or a launcher would fail to achieve the
necessary level of simplicity. Packaging Tuscany as a manageable
and fairly stable set of jar files/OSGi bundles whose purpose and
dependencies are easy to understand does achieve the simplicity goal.
Simon
>
> [1]:
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/functional+components+at+runtime
>
>
> Haleh
>
> On 7/8/08, *ant elder* <antelder@apache.org
> <ma...@apache.org>> wrote:
>
>
>
> On Mon, Jul 7, 2008 at 6:58 PM, Raymond Feng <enjoyjava@gmail.com
> <ma...@gmail.com>> wrote:
>
> What are the benefits do we intend to provide for users with the
> "components"-based aggregation?
>
>
> Simplicity and ease of use.
>
> Take the scdl jar aggregate as an example, a user wants to process
> some scdl - things like reading and writing composites, perhaps
> validating or manipulating the model programatically - they don't
> know what binding or component types may be used they just want it
> to work with what ever is in the scdl. Right now to do that they
> need to explicitly use a vast list of tuscany modules and that list
> of modules is continually changing over time so every time they pick
> up a new build their code breaks. With the tuscany-scdl aggregate
> they can just use that single jar and that will continue to work
> over new builds and releases.
>
>
>
>
> IMHO, we can use the "feature" idea to address the requirements
> of b) in Mike's original e-mail without the restriction of
> non-overlapping and side-effort of producing new jars.
> Meanwhile, the alignment of feature/distribution gives us the
> flexibility to balance the granularities. A distribution is also
> a feature and we can also easily group features into a
> distribution.
>
>
>
> The "feature" idea of having a Maven pom module instead of an
> aggregate jar helps users when building with Maven but it doesn't
> help non Maven users and it doesn't help with aspects out side of
> the Maven build process such as packaging and distribution, users
> are still going to have to deal with the vast and changing list of
> individual Tuscany module jars.
>
> ...ant
>
>
>
>
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany
extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by Simon Nash <na...@apache.org>.
haleh mahbod wrote:
> Hi Ant,
>
> when you refer to a user, do you mean an embedder or an application
> developer?
> I am looking at [1] link where the first draft of functional components
> were defined. I am assuming it is the embedders.
>
> Let's say I am an embedder wanting to use ejb. What are the steps that I
> take with the component proposal vs the feature proposal to use ejb
> feature? What are the pros and cons?
>
> I am wondering if Tuscany embedders could share their experience here?
> How are they solving this problem today that seems to be satisfactory
> for them? Are we solving a problem that is not a real issue for Tuscany
> embedders?
>
This would not affect someone who is developing a business application
within a predefined environment. It would affect the packaging and
distribution of that application with its dependency on Tuscany or
some elements of Tuscany. In this sense I think it affects all
Tuscany users, as any real application developed using Tuscany will
need to be packaged and distributed before it can be used by others.
It also affects embedders who want to incorporate all or part of
Tuscany into platform or middleware offerings.
I believe our packaging and distribution story needs to be as simple
and consumable as possible, while providing flexibility for different
selections of Tuscany functionality. Having this story depend on
maven, an extension registry, or a launcher would fail to achieve the
necessary level of simplicity. Packaging Tuscany as a manageable
and fairly stable set of jar files/OSGi bundles whose purpose and
dependencies are easy to understand does achieve the simplicity goal.
Simon
>
> [1]:
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/functional+components+at+runtime
>
>
> Haleh
>
> On 7/8/08, *ant elder* <antelder@apache.org
> <ma...@apache.org>> wrote:
>
>
>
> On Mon, Jul 7, 2008 at 6:58 PM, Raymond Feng <enjoyjava@gmail.com
> <ma...@gmail.com>> wrote:
>
> What are the benefits do we intend to provide for users with the
> "components"-based aggregation?
>
>
> Simplicity and ease of use.
>
> Take the scdl jar aggregate as an example, a user wants to process
> some scdl - things like reading and writing composites, perhaps
> validating or manipulating the model programatically - they don't
> know what binding or component types may be used they just want it
> to work with what ever is in the scdl. Right now to do that they
> need to explicitly use a vast list of tuscany modules and that list
> of modules is continually changing over time so every time they pick
> up a new build their code breaks. With the tuscany-scdl aggregate
> they can just use that single jar and that will continue to work
> over new builds and releases.
>
>
>
>
> IMHO, we can use the "feature" idea to address the requirements
> of b) in Mike's original e-mail without the restriction of
> non-overlapping and side-effort of producing new jars.
> Meanwhile, the alignment of feature/distribution gives us the
> flexibility to balance the granularities. A distribution is also
> a feature and we can also easily group features into a
> distribution.
>
>
>
> The "feature" idea of having a Maven pom module instead of an
> aggregate jar helps users when building with Maven but it doesn't
> help non Maven users and it doesn't help with aspects out side of
> the Maven build process such as packaging and distribution, users
> are still going to have to deal with the vast and changing list of
> individual Tuscany module jars.
>
> ...ant
>
>
>
>
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by haleh mahbod <hm...@gmail.com>.
Hi Ant,
when you refer to a user, do you mean an embedder or an application
developer?
I am looking at [1] link where the first draft of functional components were
defined. I am assuming it is the embedders.
Let's say I am an embedder wanting to use ejb. What are the steps that I
take with the component proposal vs the feature proposal to use ejb feature?
What are the pros and cons?
I am wondering if Tuscany embedders could share their experience here? How
are they solving this problem today that seems to be satisfactory for them?
Are we solving a problem that is not a real issue for Tuscany embedders?
[1]:
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/functional+components+at+runtime
Haleh
On 7/8/08, ant elder <an...@apache.org> wrote:
>
>
>
> On Mon, Jul 7, 2008 at 6:58 PM, Raymond Feng <en...@gmail.com> wrote:
>
>> What are the benefits do we intend to provide for users with the
>> "components"-based aggregation?
>>
>
> Simplicity and ease of use.
>
> Take the scdl jar aggregate as an example, a user wants to process some
> scdl - things like reading and writing composites, perhaps validating or
> manipulating the model programatically - they don't know what binding or
> component types may be used they just want it to work with what ever is in
> the scdl. Right now to do that they need to explicitly use a vast list of
> tuscany modules and that list of modules is continually changing over time
> so every time they pick up a new build their code breaks. With the
> tuscany-scdl aggregate they can just use that single jar and that will
> continue to work over new builds and releases.
>
>
>
>>
>> IMHO, we can use the "feature" idea to address the requirements of b) in
>> Mike's original e-mail without the restriction of non-overlapping
>> and side-effort of producing new jars. Meanwhile, the alignment of
>> feature/distribution gives us the flexibility to balance the granularities.
>> A distribution is also a feature and we can also easily group features into
>> a distribution.
>>
>>
>
> The "feature" idea of having a Maven pom module instead of an aggregate jar
> helps users when building with Maven but it doesn't help non Maven users and
> it doesn't help with aspects out side of the Maven build process such as
> packaging and distribution, users are still going to have to deal with the
> vast and changing list of individual Tuscany module jars.
>
> ...ant
>
>
>
>
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by haleh mahbod <hm...@gmail.com>.
Hi Ant,
when you refer to a user, do you mean an embedder or an application
developer?
I am looking at [1] link where the first draft of functional components were
defined. I am assuming it is the embedders.
Let's say I am an embedder wanting to use ejb. What are the steps that I
take with the component proposal vs the feature proposal to use ejb feature?
What are the pros and cons?
I am wondering if Tuscany embedders could share their experience here? How
are they solving this problem today that seems to be satisfactory for them?
Are we solving a problem that is not a real issue for Tuscany embedders?
[1]:
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/functional+components+at+runtime
Haleh
On 7/8/08, ant elder <an...@apache.org> wrote:
>
>
>
> On Mon, Jul 7, 2008 at 6:58 PM, Raymond Feng <en...@gmail.com> wrote:
>
>> What are the benefits do we intend to provide for users with the
>> "components"-based aggregation?
>>
>
> Simplicity and ease of use.
>
> Take the scdl jar aggregate as an example, a user wants to process some
> scdl - things like reading and writing composites, perhaps validating or
> manipulating the model programatically - they don't know what binding or
> component types may be used they just want it to work with what ever is in
> the scdl. Right now to do that they need to explicitly use a vast list of
> tuscany modules and that list of modules is continually changing over time
> so every time they pick up a new build their code breaks. With the
> tuscany-scdl aggregate they can just use that single jar and that will
> continue to work over new builds and releases.
>
>
>
>>
>> IMHO, we can use the "feature" idea to address the requirements of b) in
>> Mike's original e-mail without the restriction of non-overlapping
>> and side-effort of producing new jars. Meanwhile, the alignment of
>> feature/distribution gives us the flexibility to balance the granularities.
>> A distribution is also a feature and we can also easily group features into
>> a distribution.
>>
>>
>
> The "feature" idea of having a Maven pom module instead of an aggregate jar
> helps users when building with Maven but it doesn't help non Maven users and
> it doesn't help with aspects out side of the Maven build process such as
> packaging and distribution, users are still going to have to deal with the
> vast and changing list of individual Tuscany module jars.
>
> ...ant
>
>
>
>
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@apache.org>.
On Mon, Jul 7, 2008 at 6:58 PM, Raymond Feng <en...@gmail.com> wrote:
> What are the benefits do we intend to provide for users with the
> "components"-based aggregation?
>
Simplicity and ease of use.
Take the scdl jar aggregate as an example, a user wants to process some scdl
- things like reading and writing composites, perhaps validating or
manipulating the model programatically - they don't know what binding or
component types may be used they just want it to work with what ever is in
the scdl. Right now to do that they need to explicitly use a vast list of
tuscany modules and that list of modules is continually changing over time
so every time they pick up a new build their code breaks. With the
tuscany-scdl aggregate they can just use that single jar and that will
continue to work over new builds and releases.
> IMHO, we can use the "feature" idea to address the requirements of b) in
> Mike's original e-mail without the restriction of non-overlapping
> and side-effort of producing new jars. Meanwhile, the alignment of
> feature/distribution gives us the flexibility to balance the granularities.
> A distribution is also a feature and we can also easily group features into
> a distribution.
>
>
The "feature" idea of having a Maven pom module instead of an aggregate jar
helps users when building with Maven but it doesn't help non Maven users and
it doesn't help with aspects out side of the Maven build process such as
packaging and distribution, users are still going to have to deal with the
vast and changing list of individual Tuscany module jars.
...ant
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by Raymond Feng <en...@gmail.com>.
What are the benefits do we intend to provide for users with the "components"-based aggregation?
IMHO, we can use the "feature" idea to address the requirements of b) in Mike's original e-mail without the restriction of non-overlapping and side-effort of producing new jars. Meanwhile, the alignment of feature/distribution gives us the flexibility to balance the granularities. A distribution is also a feature and we can also easily group features into a distribution.
Thanks,
Raymond
From: ant elder
Sent: Monday, July 07, 2008 4:10 AM
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
That all sounds reasonable to me.
To help anyone else hunting around for "Mike's original note on this" the link is: http://apache.markmail.org/message/nplwkkncelkwwrrk
...ant
On Mon, Jul 7, 2008 at 11:59 AM, Simon Nash <na...@apache.org> wrote:
Raymond Feng wrote:
Hi,
It seems that the fundamental difference we're having is whether two tuscany features can contain the same module. For example, if I build the web service feature and jsonrpc feature, both of them would contain core-spi and databinding modules.
The other thing is that I see a feature can contain other features too.
I don't think the "components" that Ant has described and started
to produce are at the same level as the "features" that Raymond has
proposed and the "distributions" that Sebastien has produced.
Going back to Mike's original note on this, I see the components
playing the role described for level b) and the features/distributions
playing the role described for level c).
If the component split is correct, it would have the following
properties:
1. Each maven module would belong to exactly one component.
2. Features/distributions would be assembled from components and
not from maven modules directly.
3. The assembly of a feature/distribution from components would
not drag in "too much" that is not needed by the feature or
distribution.
How much in point 3 above is "too much" is a subjective judgment
and some might have different views on this. I'd suggest the
following criteria as a starting point for discussion:
a. No unnecessary third party dependencies.
b. No additional system resources (e.g., ports, threads) consumed.
c. No slowdown on any code paths.
If we can achieve the above, then I don't see any problem with
physically aggregating modules together into component jars/bundles
and using these component jars/bundles to build features or
distributions.
If the component approach works out, I'd like to add support
for it in the build, so that a specified selection of components
could be built without building other components. Also, when
building a component, it should not be necessary to build the
other components on which the component depends, if these are
available in binary form.
Simon
Thanks,
Raymond
*From:* ant elder <ma...@apache.org>
*Sent:* Wednesday, July 02, 2008 9:05 AM
*To:* tuscany-dev <ma...@ws.apache.org>
*Subject:* Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
This went to me not the dev list, comments in line
...ant
On Wed, Jul 2, 2008 at 4:57 PM, Raymond Feng <enjoyjava@gmail.com <ma...@gmail.com>> wrote:
Hi,
Can you provide us some use cases for the aggregated jars?
I think it's very important that we don't physically merge module
jars into a feature jar.
Let's assume we have two features: f1 and f2. f1 contains modules m1
and m2, f2 contains m1 and m3.
If that happens then likely we don't have the aggregation granularity correct. Could you provide an example of that using actual Tuscany modules and the aggregations suggested so far?
If we produce f1.jar and f2.jar, what's going to happen if my
application uses both f1 and f2? If we declare maven dependencies to
f1 and f2, we end up with a classpath containing f1.jar and f2.jar.
All the classes/resources from module m1 will be duplicate in these
two jars. The jar aggregation also prevents a feature to be depended
by another feature for the same reason. Even when we put maven on
the side, do you expect the user to download both f1.jar and f2.jar
to support both features? If so, we still have the duplicating
artifacts issue.
Also thinking about OSGi, adding feature jars will be problematic
too. If it's just a descriptor, then adding a feature just pulls
into the contained module bundles.
I'm not seeing the problems you're hinting at, could you be more specific or give concrete examples?
...ant
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
That all sounds reasonable to me.
To help anyone else hunting around for "Mike's original note on this" the
link is: http://apache.markmail.org/message/nplwkkncelkwwrrk
...ant
On Mon, Jul 7, 2008 at 11:59 AM, Simon Nash <na...@apache.org> wrote:
> Raymond Feng wrote:
>
>> Hi,
>> It seems that the fundamental difference we're having is whether two
>> tuscany features can contain the same module. For example, if I build the
>> web service feature and jsonrpc feature, both of them would contain core-spi
>> and databinding modules.
>> The other thing is that I see a feature can contain other features too.
>>
>>
> I don't think the "components" that Ant has described and started
> to produce are at the same level as the "features" that Raymond has
> proposed and the "distributions" that Sebastien has produced.
>
> Going back to Mike's original note on this, I see the components
> playing the role described for level b) and the features/distributions
> playing the role described for level c).
>
> If the component split is correct, it would have the following
> properties:
> 1. Each maven module would belong to exactly one component.
> 2. Features/distributions would be assembled from components and
> not from maven modules directly.
> 3. The assembly of a feature/distribution from components would
> not drag in "too much" that is not needed by the feature or
> distribution.
>
> How much in point 3 above is "too much" is a subjective judgment
> and some might have different views on this. I'd suggest the
> following criteria as a starting point for discussion:
> a. No unnecessary third party dependencies.
> b. No additional system resources (e.g., ports, threads) consumed.
> c. No slowdown on any code paths.
>
> If we can achieve the above, then I don't see any problem with
> physically aggregating modules together into component jars/bundles
> and using these component jars/bundles to build features or
> distributions.
>
> If the component approach works out, I'd like to add support
> for it in the build, so that a specified selection of components
> could be built without building other components. Also, when
> building a component, it should not be necessary to build the
> other components on which the component depends, if these are
> available in binary form.
>
> Simon
>
> Thanks,
>> Raymond
>>
>> *From:* ant elder <ma...@apache.org>
>> *Sent:* Wednesday, July 02, 2008 9:05 AM
>> *To:* tuscany-dev <ma...@ws.apache.org>
>> *Subject:* Re: Grouping/Aggregating tuscany modules, was: Re: Tracking
>> Tuscany extensions, was: Distribution zips and what they contain, was: SCA
>> runtimes
>>
>> This went to me not the dev list, comments in line
>>
>> ...ant
>>
>> On Wed, Jul 2, 2008 at 4:57 PM, Raymond Feng <enjoyjava@gmail.com<mailto:
>> enjoyjava@gmail.com>> wrote:
>>
>> Hi,
>> Can you provide us some use cases for the aggregated jars?
>> I think it's very important that we don't physically merge module
>> jars into a feature jar.
>> Let's assume we have two features: f1 and f2. f1 contains modules
>> m1
>> and m2, f2 contains m1 and m3.
>>
>> If that happens then likely we don't have the aggregation granularity
>> correct. Could you provide an example of that using actual Tuscany modules
>> and the aggregations suggested so far?
>>
>> If we produce f1.jar and f2.jar, what's going to happen if my
>> application uses both f1 and f2? If we declare maven dependencies to
>> f1 and f2, we end up with a classpath containing f1.jar and f2.jar.
>> All the classes/resources from module m1 will be duplicate in these
>> two jars. The jar aggregation also prevents a feature to be depended
>> by another feature for the same reason. Even when we put maven on
>> the side, do you expect the user to download both f1.jar and f2.jar
>> to support both features? If so, we still have the duplicating
>> artifacts issue.
>> Also thinking about OSGi, adding feature jars will be problematic
>> too. If it's just a descriptor, then adding a feature just pulls
>> into the contained module bundles.
>>
>>
>> I'm not seeing the problems you're hinting at, could you be more specific
>> or give concrete examples?
>>
>> ...ant
>>
>>
>
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Wed, Jul 2, 2008 at 5:38 PM, ant elder <an...@gmail.com> wrote:
>
>
> On Wed, Jul 2, 2008 at 5:34 PM, Raymond Feng <en...@gmail.com> wrote:
>
>> Hi,
>>
>> It seems that the fundamental difference we're having is whether two
>> tuscany features can contain the same module. For example, if I build the
>> web service feature and jsonrpc feature, both of them would contain core-spi
>> and databinding modules.
>>
>
> Thats not how i was thinking it would look like, i didn't expect the
> jsonrpc or ws ones would include those core-spi or databinding classes. To
> use a ws feature you'd also need to use the tuscany-runtime and tuscany-scdl
> jars.
>
> ...ant
>
>
I stopped with these aggregation examples while this discussion was going
on, maybe i should go continue so there's things like ws support and a
calculator-ws sample to make it clearer?
...ant
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Wed, Jul 2, 2008 at 5:34 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> It seems that the fundamental difference we're having is whether two
> tuscany features can contain the same module. For example, if I build the
> web service feature and jsonrpc feature, both of them would contain core-spi
> and databinding modules.
>
Thats not how i was thinking it would look like, i didn't expect the jsonrpc
or ws ones would include those core-spi or databinding classes. To use a ws
feature you'd also need to use the tuscany-runtime and tuscany-scdl jars.
...ant
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany
extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by Simon Nash <na...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> It seems that the fundamental difference we're having is whether two
> tuscany features can contain the same module. For example, if I build
> the web service feature and jsonrpc feature, both of them would contain
> core-spi and databinding modules.
>
> The other thing is that I see a feature can contain other features too.
>
I don't think the "components" that Ant has described and started
to produce are at the same level as the "features" that Raymond has
proposed and the "distributions" that Sebastien has produced.
Going back to Mike's original note on this, I see the components
playing the role described for level b) and the features/distributions
playing the role described for level c).
If the component split is correct, it would have the following
properties:
1. Each maven module would belong to exactly one component.
2. Features/distributions would be assembled from components and
not from maven modules directly.
3. The assembly of a feature/distribution from components would
not drag in "too much" that is not needed by the feature or
distribution.
How much in point 3 above is "too much" is a subjective judgment
and some might have different views on this. I'd suggest the
following criteria as a starting point for discussion:
a. No unnecessary third party dependencies.
b. No additional system resources (e.g., ports, threads) consumed.
c. No slowdown on any code paths.
If we can achieve the above, then I don't see any problem with
physically aggregating modules together into component jars/bundles
and using these component jars/bundles to build features or
distributions.
If the component approach works out, I'd like to add support
for it in the build, so that a specified selection of components
could be built without building other components. Also, when
building a component, it should not be necessary to build the
other components on which the component depends, if these are
available in binary form.
Simon
> Thanks,
> Raymond
>
> *From:* ant elder <ma...@apache.org>
> *Sent:* Wednesday, July 02, 2008 9:05 AM
> *To:* tuscany-dev <ma...@ws.apache.org>
> *Subject:* Re: Grouping/Aggregating tuscany modules, was: Re: Tracking
> Tuscany extensions, was: Distribution zips and what they contain, was:
> SCA runtimes
>
> This went to me not the dev list, comments in line
>
> ...ant
>
> On Wed, Jul 2, 2008 at 4:57 PM, Raymond Feng <enjoyjava@gmail.com
> <ma...@gmail.com>> wrote:
>
> Hi,
>
> Can you provide us some use cases for the aggregated jars?
>
> I think it's very important that we don't physically merge module
> jars into a feature jar.
>
> Let's assume we have two features: f1 and f2. f1 contains modules m1
> and m2, f2 contains m1 and m3.
>
>
> If that happens then likely we don't have the aggregation granularity
> correct. Could you provide an example of that using actual Tuscany
> modules and the aggregations suggested so far?
>
>
> If we produce f1.jar and f2.jar, what's going to happen if my
> application uses both f1 and f2? If we declare maven dependencies to
> f1 and f2, we end up with a classpath containing f1.jar and f2.jar.
> All the classes/resources from module m1 will be duplicate in these
> two jars. The jar aggregation also prevents a feature to be depended
> by another feature for the same reason. Even when we put maven on
> the side, do you expect the user to download both f1.jar and f2.jar
> to support both features? If so, we still have the duplicating
> artifacts issue.
>
> Also thinking about OSGi, adding feature jars will be problematic
> too. If it's just a descriptor, then adding a feature just pulls
> into the contained module bundles.
>
>
>
> I'm not seeing the problems you're hinting at, could you be more
> specific or give concrete examples?
>
> ...ant
>
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by Raymond Feng <en...@gmail.com>.
Hi,
It seems that the fundamental difference we're having is whether two tuscany features can contain the same module. For example, if I build the web service feature and jsonrpc feature, both of them would contain core-spi and databinding modules.
The other thing is that I see a feature can contain other features too.
Thanks,
Raymond
From: ant elder
Sent: Wednesday, July 02, 2008 9:05 AM
To: tuscany-dev
Subject: Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
This went to me not the dev list, comments in line
...ant
On Wed, Jul 2, 2008 at 4:57 PM, Raymond Feng <en...@gmail.com> wrote:
Hi,
Can you provide us some use cases for the aggregated jars?
I think it's very important that we don't physically merge module jars into a feature jar.
Let's assume we have two features: f1 and f2. f1 contains modules m1 and m2, f2 contains m1 and m3.
If that happens then likely we don't have the aggregation granularity correct. Could you provide an example of that using actual Tuscany modules and the aggregations suggested so far?
If we produce f1.jar and f2.jar, what's going to happen if my application uses both f1 and f2? If we declare maven dependencies to f1 and f2, we end up with a classpath containing f1.jar and f2.jar. All the classes/resources from module m1 will be duplicate in these two jars. The jar aggregation also prevents a feature to be depended by another feature for the same reason. Even when we put maven on the side, do you expect the user to download both f1.jar and f2.jar to support both features? If so, we still have the duplicating artifacts issue.
Also thinking about OSGi, adding feature jars will be problematic too. If it's just a descriptor, then adding a feature just pulls into the contained module bundles.
I'm not seeing the problems you're hinting at, could you be more specific or give concrete examples?
...ant
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@apache.org>.
This went to me not the dev list, comments in line
...ant
On Wed, Jul 2, 2008 at 4:57 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> Can you provide us some use cases for the aggregated jars?
>
> I think it's very important that we don't physically merge module jars into
> a feature jar.
>
> Let's assume we have two features: f1 and f2. f1 contains modules m1 and
> m2, f2 contains m1 and m3.
>
If that happens then likely we don't have the aggregation granularity
correct. Could you provide an example of that using actual Tuscany modules
and the aggregations suggested so far?
> If we produce f1.jar and f2.jar, what's going to happen if my application
> uses both f1 and f2? If we declare maven dependencies to f1 and f2, we end
> up with a classpath containing f1.jar and f2.jar. All the classes/resources
> from module m1 will be duplicate in these two jars. The jar aggregation also
> prevents a feature to be depended by another feature for the same reason.
> Even when we put maven on the side, do you expect the user to download both
> f1.jar and f2.jar to support both features? If so, we still have the
> duplicating artifacts issue.
>
> Also thinking about OSGi, adding feature jars will be problematic too. If
> it's just a descriptor, then adding a feature just pulls into the contained
> module bundles.
>
>
I'm not seeing the problems you're hinting at, could you be more specific or
give concrete examples?
...ant
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
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 <en...@gmail.com> 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 <an...@apache.org>
> *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 <en...@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 <an...@gmail.com>
>> *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 <na...@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
>>>> <ma...@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
>>
>>
>
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by Raymond Feng <en...@gmail.com>.
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 <en...@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 <na...@apache.org> wrote:
ant elder wrote:
On Sun, Jun 15, 2008 at 8:52 AM, ant elder <ant.elder@gmail.com <ma...@gmail.com>> wrote:
On Fri, Jun 13, 2008 at 10:08 PM, Mike Edwards
<mike.edwards.inglenook@gmail.com
<ma...@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
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@apache.org>.
On Tue, Jul 1, 2008 at 6:11 PM, Raymond Feng <en...@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 <an...@gmail.com>
> *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 <na...@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
>>> <ma...@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
>
>