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 <[EMAIL PROTECTED]> wrote: > > > > On Mon, Jul 7, 2008 at 6:58 PM, Raymond Feng <[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 > > > >
