On Wed, Sep 29, 2010 at 11:26 AM, Simon Laws <[email protected]> wrote: > On Wed, Sep 29, 2010 at 11:09 AM, Florian MOGA <[email protected]> wrote: >> I personally like the shell and the shell idea very much and I agree it >> would be the way to go (no Maven/Ant discrimination). The major problem in >> using the shell is that it implies a decent amount of knowledge with terms >> like domain, node, contribution which (we all know) aren't very well defined >> in our documentation on the website and the specs. >> I remember the early days of getting familiar with Tuscany when I had a hard >> time running the samples as they implied various launchers which were >> running tuscany embedded and didn't help very much in understanding the >> runtime as I had no "low level" control over it. All I wanted to see were >> jars which I could run and wars which i could deploy manually (things that i >> was already familiar with). I find Ant's suggestion for the save feature >> very good and it solves this problem. >> However, the user still needs to configure his contributions manually at the >> moment. My proposal is to also have a feature for the shell that can run >> tuscany shell script files. This will make things nice and easy. This is >> also a feature i suggest we need to have as it makes complex domain >> configurations to be started up very easy. I've listed more advantages here >> [1]. I see these tuscany shell script files as files containing shell >> commands on each line. This way, the user can either start the runtime using >> the shell scripts we'd provide either "export" or "save" it to a standalone >> jar and run it manually. >> Thoughts? >> [1] http://www.mail-archive.com/[email protected]/msg13683.html >> > > Shell scripting is an interesting idea and certainly something that > could be added. However, to me, it sounds more like a power user > convenience. > > Here's another approach. Why not simply imagine a directory structure > that lays out the various parts of the problem, e..g > > domain1 > contributions > contribution1.zip > (contributions don't need to be here physically if they are > accessible from elsewhere via a URL) > nodes > node1config.xml > > Then run a "shell" (I put it in speach marks as we seem to have > several shells at the moment and I'm not sure what is actually being > discussed here) over it and have it start the available node config > (or indeed create a new node config and start that). >
The "tuscany shell script files as files containing shell commands on each line" and the node1config.xml approaches seem pretty similar. You can actually use files of shell commands right now by just redirecting sysin from a file (eg java -jar tuscany-base-nodep-2.0-20100929.095517-1.jar < fileOfCmds) but ther doesn't seem to be any way to switch back to read from the console afterwards so it might be better to add an extra startup parameter for the command file, and that way you can run the script commands and then use the shell command line to continue using commands to display the state and make updates. I like the idea of supporting node xml as well though so think we should add shell commands like load and save that read and write the xml files. And then you can have something like helloworld.xml and in the shell do load helloworld.xml to run the helloworld sample. And for each of the samples provide the xml file to configure everything for the sample. ...ant
