I personally like the shell and the shell idea very much and I agree it would be the way to go (no Maven/Ant discrimination). The major problem in using the shell is that it implies a decent amount of knowledge with terms like domain, node, contribution which (we all know) aren't very well defined in our documentation on the website and the specs.
I remember the early days of getting familiar with Tuscany when I had a hard time running the samples as they implied various launchers which were running tuscany embedded and didn't help very much in understanding the runtime as I had no "low level" control over it. All I wanted to see were jars which I could run and wars which i could deploy manually (things that i was already familiar with). I find Ant's suggestion for the save feature very good and it solves this problem. However, the user still needs to configure his contributions manually at the moment. My proposal is to also have a feature for the shell that can run tuscany shell script files. This will make things nice and easy. This is also a feature i suggest we need to have as it makes complex domain configurations to be started up very easy. I've listed more advantages here [1]. I see these tuscany shell script files as files containing shell commands on each line. This way, the user can either start the runtime using the shell scripts we'd provide either "export" or "save" it to a standalone jar and run it manually. Thoughts? [1] http://www.mail-archive.com/[email protected]/msg13683.html On Wed, Sep 29, 2010 at 12:02 PM, ant elder <[email protected]> wrote: > On Wed, Sep 29, 2010 at 8:52 AM, Florian MOGA <[email protected]> wrote: > > > @Ant: What kind of sample are you thinking of in order to show the > > sca-contribution.xml file? Can you give me an example (maybe an itest)? > > There are a couple of issues we need to decide on, one is how to run > the getting started contributions and the other is how to invoke the > services. I've been wondering about using the shell as the approach to > run things but its not that clear yet if everyone likes the shell and > there is some work to do to get it to work beautifully. I've also been > wondering if we really need separate contributions for absolutley > everything and maybe it might be simpler is some contributions include > several composites. But here's a rough outline of the sort of thing > i've been thinking might work: > > 1) helloworld > Start the shell and do: > > install helloworld-contribution.jar -start > > The helloworld contribution would have an sca-contribution.xml > defining the helloworld.composite as deployable and the component impl > would have @Init and @EagerInit so you'd see "Hello world" printed on > the console. > > 2) helloworld with a ws binding. Either a speperate contribution or > include a helloworldws.composite in the helloworld contribution. The > composite has the helloworld component with the service using > binding.ws. In the shell do "installed" to see the installed > contributions and the composites in there and then: > > start helloworld-contribution helloworldws.composite > > That will start the ws endpoint and you'll see the url printed on the > console. You can then do a ?wsdl on that url in a browser to see the > wsdl but it would be nice to actually invoke the service. To do that > we could have some Java ws client to run but that needs build scripts > etc which makes it complicated, i found a html page client in > servicemix that we could try which i've committed in > getting-started/wsClinet.html. > > 3) Next we could do a new contribution that uses <include> or > <implementation.composite> (perhaps named scdl-include-contribution) > taht uses the helloworld.composite from (1). That wont work as the > helloworld-contribution doesn't export its resources so this step > could show using overiding that with an external sca-contribution.xml. > So in the shell uninstall helloworld-contribution and then do: > > install helloworld-contribution.jar -metaData -metadata > new-sca-contribution.xml > install scdl-include-contribution -start > > And that should show the included component output again. > > 4..x) continue on like that showing all the things we want to do, > changing helloworld to using <implementation.spring> instead of > <implementation.java>, scopes, callbacks, scdl <wire>, adding external > .composte files to a contribution etc using new contributions and > external side files as necessary. > > It would be nice is you could configure a bunch of contribution and > composites in the shell and then have a save command that writes out > teh contributions and a node config xml file that you can then use in > a standalone Java program or webapp to run what you'd configured. > > Anyway, how does that sound? If it doesn't use the shell then you need > lots of launchers and standalone Java programs to run all the thinngs > along with Maven and Ant build scripts to run them all and it might > start looking a bit complicated. > > ...ant >
