>From what I understand node.xml would be the final configuration that you would export from the shell after adding/installing all the contributributions (please correct me if i'm wrong). Wouldn't this bring a bit more overhead as it adds a new syntax, etc. Does it bring more things other than a succession of simple commands? (It's possible i haven't fully understood what node.xml contains...). Also, in the case where they would both do the same thing, I'd go for self-explaining scripts rather than plain xml which developers dislike.
Being able to export the full application with all the dependencies included sounds like a must-have to me. On Wed, Sep 29, 2010 at 2:24 PM, ant elder <[email protected]> wrote: > 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 >
