Hi, Please see my comments inline.
Thanks, Raymond From: Simon Laws Sent: Monday, January 26, 2009 7:00 AM To: [email protected] Subject: Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples with the distributions [[snip]] Hi I'm adding the three samples I've been playing with to the build and the distribution so we can experiment with the process/scripts. I'd like to exploit M1 to get the process a slick as we can while we have a small number of modules. The binding-ws-calculator and host-webapp-calculator samples don't actually work yet as samples. The related function still needs some work. +1 to use samples to validate the distribution structure and grouping. Looking through the distribuion I have some questions/comments; - why "ejava"? Any relation to [1]:-) "ejava" stands for "Enterprise Java". It will potentially include Enterprise Java related pieces such as binding.rmi, binding.ejb, binding.jms, implementation.ejb, implementation.web etc. - How to get hold of the list of jars for a given feature so that I can build a war including the minimum set of jars. It could be an option if the war just referenced an external tuscany distribution but users may not have the option to install one so we probably still need to include the runtime in the war. Is there a trick to extract this info from a manifest. I'd rather not generate another ant script with that info if we can avoid it. How do you produce the WAR file? If you are using maven, then you can add the dependency to the distribution pom project, such as tuscany-distribution-core:pom. For ANT, it's typically done via the war ant task which has the lib element that defines a fileSet. We can easily generate something like modules.lst for each distribution for easy parsing. - tuscany-distribution-ejava etc. This is a question about naming really. I'm undecided as to whether we should actually distribute these things but I am very keen that our distribution(s) are structured so that people can depend on sensible chunks of function rather than all of it. Do we anticipate that there will be groups of function here that aren't named distribution, e.g. tuscany-extension-implementation-bpel or tuscany-extension-binding-jms so that people can include manifests for individual extensions rather than larger groups of them? I think it's about granularity and different combinations of functional modules. Tuscany can only ship a limited number of distros. If we get the technique very simple to declare a "feature", then we can potentially make many configurations available. With what we have, "feature" can extend from one or more features and features can also have overlaps. In fact, we don't have to build a distro for every single feature we define. We can have much less distros than features. For example, one "all" distro can have configurations for "core", "ejava", "webservice" features. I'll post more as they come to mind. Simon [1] http://cs.joensuu.fi/~jeliot/help/EJava/EJava-language.html
