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
