Ant, I've been looking around and seen that node.xml is actually something already existing. Is this something we added or is it in the spec as well? Indeed, it would add consistency if you can generate and load node.xml as well.
The "run" command is exactly what I'm suggesting as well as the startup parameter. Didn't have the time to look deeper into the code but i believe it doesn't require major changes in the shell code. What do you think about a history/log feature? I'm thinking of something like logging all the commands you enter in the shell in a tuscany.log file in the directory from where you start the shell. This is helpful when you start doing configurations for a project and when you're done you already have a script with all your work. This is inspired by Spring Roo, you can check out their shell to get the feel of these features. On Thu, Sep 30, 2010 at 10:43 AM, ant elder <[email protected]> wrote: > On Wed, Sep 29, 2010 at 5:03 PM, Florian MOGA <[email protected]> wrote: > > 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). > > Yep thats what i was thinking would be useful. > > > 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...). > > What isn't so obvious is that this is a facility that already exsists > with the Node API. Theres some examples of it in the nodes itests, eg > > https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/itest/nodes/two-nodes-two-vms-hazelcast/client-config.xml > > So having the shell support loading and saving those types of config > files is really just adding consistency. > > > 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. > > > > The scripts of shell commands seem useful to me too, and as i > commented earlier it is possible already by redirecting the console > input though that isn't very flexible. How about adding something like > a "run" command to the shell that has a parameter thats a url to a > file containing shell commands and executes them? It might be good to > also be able to have that as a parameter when starting the shell so > the commands in the file run as soon as the shell starts. > > How does that sound, any modifications or alternative suggestions? > > ...ant >
