I've just done a build of all the samples and get the following fails: samples\running-tuscany\embedded-jse samples\running-tuscany\embedded-osgi samples\running-tuscany\embedded-osgi-base samples\learning-more\binding-ws\helloworld-ws-sdo-contribution samples\learning-more\implementation-osgi\dosgi-calculator-operations samples\learning-more\distributed-osgi\dosgi-dynamic-calculator-operations samples\learning-more\maven-osgi-junit\calculator-osgi samples\learning-more\maven-osgi-junit\calculator-rest-osgi samples\learning-more\logging-scribe
...ant On Fri, Oct 1, 2010 at 9:15 AM, Florian MOGA <[email protected]> wrote: > 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 <[email protected]> wrote: >> >> 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 >>>>> >>>> >>> >> > >
