On Thu, Sep 30, 2010 at 12:15 PM, Florian MOGA <[email protected]> wrote:
> 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. I've completed the renaming of the contribution-* samples to *-contribution. Some observations below: - store is a contribution? it uses impl.widget, is it a webapp as well? - i see we have poms in each and every directory. do you find it better having a single pom at the root level of the samples folder? are things easier to maintain this way? - should artifact names reflect the directory name? - does logging-scribe fit better into the applications or learning-more section? - moved helloworld-jms into a separate binding-jms folder. is there any reason it was in implementation-web? - wouldn't implementation-extension fit better in a "extending-tuscany" category? in time we'll also add this type of samples for bindings and other things and they'll be hard to find inside the learning-more folder... - what's the async folder? it's got modules-like pom and seems to include a launcher... shouldn't the launcher get into running-tuscany and the other one into getting-started as comments say it demonstrates synchronous/asynchronous invocation? - there are a number of samples which are not marked either as contributions or webapps: maven-osgi-junit, distributed-osgi, implementation-composite folder. Should these samples have "-contribution" appended at the end? would that make the names unnecessarily long? The faster I get your feedback on the above points, the faster we approach completing this task. I'm currently performing a full build locally. The running-tuscany/embedded-* , binding-ws/helloworld-ws-sdo-contribution and implementation-osgi/dosgi-calculator-operations samples are failing they're tests. I've commented them out in their parent poms... Do you have any idea on how can those be fixed? > On Thu, Sep 30, 2010 at 11:45 AM, Florian MOGA <[email protected]> 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 <[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 >>> >> >> >
