It's been a full day since I've proposed the *-contribution renaming and no negative reactions so I'll proceed with doing the changes tomorrow morning.
On Thu, Sep 30, 2010 at 11:45 AM, Florian MOGA <moga....@gmail.com> wrote: > 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 <antel...@apache.org> wrote: > >> On Wed, Sep 29, 2010 at 5:03 PM, Florian MOGA <moga....@gmail.com> 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 >> > >
