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" <[EMAIL PROTECTED]>
Sent: Thursday, July 10, 2008 12:57 AM
To: <[email protected]>
Cc: <[EMAIL PROTECTED]>
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* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
On Mon, Jul 7, 2008 at 6:58 PM, Raymond Feng <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
