>From my latest experience I'd go with 2 required launchers for the samples:
1. the tuscany shell - it's so easy to start with 'mvn tuscany:run' or with the provided scripts. The fact that you can interactively invoke deployed services has a huge plus for user experience. One mention would be that at the moment the shell does not support webapps but that might not be hard to achieve. 2. a unit test - very useful when the user imports the sample in it's own IDE. Gives him the ability to start the runtime, perform debug (if interested in a step-by-step execution) really easy. Also, it helps us to keep track of the broken samples. Regarding documentation, I don't have an idea on how to structure it.. to be honest, I don't know where to start from and I think this is part of a more general topic involving more aspects like the website changes we'll have to do soon. I'll start a separate topic for this to gather ideas. I'm not keen into having an ant build file in every sample. If someone wants to use ant, shouldn't they download all dependencies manually? Won't they use maven for that task anyway? What about ivy? On Thu, Feb 10, 2011 at 11:10 AM, ant elder <antel...@apache.org> wrote: > On Tue, Feb 8, 2011 at 7:18 PM, ant elder <antel...@apache.org> wrote: > > On Tue, Feb 8, 2011 at 1:26 PM, Simon Laws <simonsl...@googlemail.com> > wrote: > >> On Tue, Feb 8, 2011 at 12:58 PM, ant elder <antel...@apache.org> wrote: > >>> On Tue, Feb 8, 2011 at 11:09 AM, Florian Moga <moga....@gmail.com> > wrote: > >>>> Maybe it's time to take a decision so we all know where we're heading. > From > >>>> what I see we've got 2 options: > >>>> 1/ do the release now according to Mike's suggestion > >>>> 2/ discuss documentation and sample structure and launchers, review > and > >>>> update all samples accordingly, do the release > >>>> I tend to go with 1/ as it gives us the possibility to do more > frequent > >>>> releases, to incrementally improve the quality of our samples and > doesn't > >>>> imply a big effort which we don't afford at the moment. However, I'm > not > >>>> opposing to 2/ if everybody else agrees on this option as I'm not > directly > >>>> affected if the release is shipped in 1 week or 1 month. > >>>> > >>> > >>> I don't mind making an RC3 according to the 1/ approach this weekend, > >>> i have everything set up still from RC1+2 so it wont take too long. > >>> But i would first like to see a few others agree to the approach as > >>> I'd like to try to avoid spending more time on another RC only to have > >>> someone complain that some sample is missing and want yet another > >>> respin. > >>> > >>> ...ant > >>> > >> > >> If people want to see Beta2 go out now that fine by me but we've had > >> some good discussions on the samples over the last few days so it > >> would be good to get straight on with a Beta3 and make samples the > >> focus of that. > >> > >> Simon > >> > > > > Ok so views on both sides, to move this along how about: > > > > - take a branch from current trunk for the beta2 RC3, maybe or not I > > or someone will actually go ahead and do the work to make a release > > from that branch > > - in trunk go ahead with the new sample approach, so move everything > > somewhere else, fix them up and move back to trunk/samples as they > > become ready, and once thats done do a beta3 release (or if beta2 > > never happen call this beta2). > > > > If no one objects I'll do this is a couple of days. While we wait > > there's nothing stopping anyone continuing to work on the current > > trunk samples. > > > > ...ant > > > > I have now done these. There's a beta2 branch for the release, and all > the trunk samples are now in contrib/samples and the helloworld sample > is in unreleased/samples where we can continuing with making it like > we want. > > ...ant >
