Hi Lucinao > > This brings a good question, who is the target for these "aggregation > themes" we have been working on (e.g features, shades, etc).
The objective in my mind was to define a common set of collections of modules that brought together many of the strands of discussion that we've been having over probably the last 12 months and be useful to both extension developers alike. Various people have brought forward ideas whether that be using pom type poms as an accepted way of describing module collections, describing releasable collections using the features idea, aggregating modules together into separate jars to make life easier for users. These are all good things but there was no consistency. The thought about the new poms is a simple one. Tuscany is made up of some core function to which extensions can be added (the word base has been approrpriated from the shade idea to describe a very minimal set of extensions over core such as impl.java that most people will want in the first instance an which are required to run the basic otests). That's it really. As an extension developer I can create a maven dependency on core-runtime in order to compile against, well, the core runtime As an extension tester I can create a maven dependency on base-runtime to get the basic support required for testing extensions As a user I can create a classpath out of base-runtime + myfavouriteextension-runtime in order to run my application With the last one there are a number of ways that the user can use this information - as an ant fileset, that the maven bundle plugin generates for them - as a manifest jar that the maven bundle plugin also generates for them - manually by looking at the "which-jars" file and referencing the jars in the modules directory - The distro will also contain an aggregate jar for the base-runtime so that the user can combine base-runtime + extension-rutime if they want to In all of this I see the 80/20 rule being important. It's very easy to poke holes in it and point out that this dependency is not quite right or we're missing such and such. However for 80% of the people it feels like having a consistent approach to describing the base + extension approach to creating a Tuscany runtime will pay dividend regarless of how they choose to use it, e.g. ant fileset, manifest, aggregation, what-files. At the end of the day the user doesn't have to use this if they need a particular configuration, They can peruse the what-files list and concoct and alternative combination. >To me, > these are really targeted to end users which want to be shielded from > knowing the Tuscany module dependency graph. Having said that, I don't > think Tuscany modules should be using these at all, other then the > issues already mentioned by Raymond, I wonder about the side effect on > modularity as well as side effects the the complexity for applications > embedding/extending the Tuscany runtime. I haven't seen any side effects so far. The dependency on core-runtime rather than individual modules is a convenience using the maven pomp type pom mechanism which, as far as I know, doesn't prevent anything else in out source code base working. > > -- > Luciano Resende > http://people.apache.org/~lresende > http://twitter.com/lresende1975 > http://lresende.blogspot.com/ > Regards Simon
