On Mon, Jan 26, 2009 at 8:13 PM, Raymond Feng <[email protected]> wrote:
> 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. > Currently I just include everything in modules which is not ideal... <fileset id="tuscany.jars" dir="${distro.root}/modules"> <include name="*.jar" /> <include name="*/*.jar" /> </fileset> <war destfile="${sample.war}" webxml="${sample.root}/src/main/webapp/WEB-INF/web.xml"> <fileset dir="${sample.root}/src/main/webapp"/> <lib refid="tuscany.jars"/> <classes dir="${sample.root}/target/classes"/> </war> If we want to allow people to build wars from ant scripts then we need to have a way for building a lib path from selected features. An alternative is to say that people can;t do this with ant but need to use maven to build wars and use the maven dependencies. A step back from what we have in 1.x though so I'd rather we continue to support any compiles in this case. We could generate the "fileset" for each feature an maybe this is the easiest way but I was interested to know if you had something in mind without generating more files. > - 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 agree that the idea of having groups of jars represented in the all distribrio and the though that these groups might be separately distributed are different points. I think we need to try different granularity of groups to see what works. The smallest granularity is propably an extension and multiple extensions in a group produce the "features" that are in svn now. > I'll post more as they come to mind. > > Simon > > [1] > http://cs.joensuu.fi/~jeliot/help/EJava/EJava-language.html<http://cs.joensuu.fi/%7Ejeliot/help/EJava/EJava-language.html> >
