dosgi-dynamic-calculator-operations fails as well... I've committed the poms with the failing samples commented out. Do you think it's worth checking them out now or wait until we implement the new build structure as we'll need to get through all of the samples again?
On Fri, Oct 1, 2010 at 10:49 AM, Florian MOGA <moga....@gmail.com> wrote: > Also calculator-osgi, calculator-rest-osgi and logging scribe are > failing... > > > On Fri, Oct 1, 2010 at 10:45 AM, Florian MOGA <moga....@gmail.com> wrote: > >> On Thu, Sep 30, 2010 at 12:15 PM, Florian MOGA <moga....@gmail.com>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 <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 >>>>> >>>> >>>> >>> >> >
