Also calculator-osgi, calculator-rest-osgi and logging scribe are failing...
On Fri, Oct 1, 2010 at 10:45 AM, Florian MOGA <[email protected]> wrote: > 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 >>>> >>> >>> >> >
