Hi, I've been checking out the shell module as it seems a useful tool to have and I'm also a fan of command line tools :). Considering the fact that it is still a work in progress I can say i found it really nice as a general impression. Here are some observations I made while using it:
- haven't been able to *install* any contributions... i always got some validation error, either xml schema or class not found. i've tried installing samples from trunk either packaged (in war or jar format) either by passing the directory of the sample - at first sight i had a hard time making distinction between *install*and *start*, probably because the *help install *description was quite vague - "*Creates an installed contribution with a supplied root contribution, installed at abase URI". *What is installed contribution? Checking help start I could deduce from "*The second form of the start command starts in standalone mode not part of any SCA domain." *that the first form is probably used in conjunction with a domain and probably i could use * install* to add contributions to the domain. - performing *install* on a contribution folder which was previously built throws a validation exception stating that there are duplicate contributions. this is probably due to the fact that it can find the contribution in *src/* as well as in *target/*. When I'm running install on the folder i'm expecting to install from src which is the most up-to-date. If i wanted the built artifact i could pass the path to it directly or to the *target/ *directory. - i'm familiar with tuscany for a few months now and i still get confused by all the different type of uris you have to take into account when developing/deploying an sca contribution. If we're targeting this shell also for people just wanting to give tuscany a try and will probably use the shell, we might need to somehow get the terms like contribution uri, domain uri, composite uri and the relation between them explained very clearly either in the documentation on the site or in the shell hints or help. Just as a short disclaimer, I might not be familiar enough with all the sca/tuscany terms so read the above comments with this in mind. Thinking of enhancements for the shell, I believe supporting the ability to have the shell start logging the commands which were entered and running tuscany shell scripts by passing a file as a parameter will bring considerable advantages. This will enable automating complex sca deployments simply by running a script. Choosing the embedded container when running start will also be a plus. This module makes me think of Spring Roo [0]. This tool has a different purpose but check out this presentation at Google I/O [1] and then the list of technologies it integrates with [2]. This is quite impressive and it hasn't started for a long time. Haven't followed any trends but i believe this will gain much popularity from now on and I find it a good step forward for Tuscany and Tuscany popularity if we can contribute a Tuscany integration in there. From what I've read Spring Roo is based on AOP and is monitoring the filesystem for the automatically Roo annotated classes. At a first glance I don't find it extremely complex to be generating and updating the composite dynamically when a class is modified. Thoughts? Not having that much experience with AOP... Florian [0] http://www.springsource.org/roo/ [1] http://www.youtube.com/watch?v=GQHlhIIxCIc&feature=channel [2] http://www.springsource.org/roo/why On Thu, Aug 19, 2010 at 8:41 AM, Jean-Sebastien Delfino < jsdelf...@apache.org> wrote: > Simon Nash wrote: > >> Raymond Feng wrote: >> >>> Sorry for the late reply. The message skipped out of my attention. >>> >>> My understanding is that a domain is the administrative (governance) >>> boundary for SCA composite applications. Why does the Shell needs to switch >>> between multiple domains within the same session. Typically, most admin >>> consoles connect to one "boundary" at a time. For example: >>> >>> * OSGi console connects to an instance of the OSGi runtime >>> * WebSphere admin console talks to a ND manager for a cell >>> * Telnet/SSH connects to a host >>> >>> Why cannot we have the Shell session be associated with one SCA domain at >>> a time, for example: >>> >>> shell <domainURI> >>> tuscany> (all the commands are within the domain) >>> tuscany> >>> >> There are testing scenarios where it's necessary to bring up and run >> multiple domains at the same time. I think it would be useful to be >> able to do this from a single shell rather than needing to bring up >> separate shells to control each of the domains. >> >> > as well as multi-tenant configurations, where a runtime is used to host > apps for multiple tenants, each tenant having his own admin domain. > > -- > Jean-Sebastien >
