On Fri, May 7, 2010 at 9:46 AM, ant elder <[email protected]> wrote: > On Fri, May 7, 2010 at 9:04 AM, Simon Laws <[email protected]> wrote: > >> >> OK subsequent to a chat over on freenode #tuscany is seems that there >> are four questions we are trying answer independently of the way >> samples are named. How to present: >> >> contribution build, >> contribution test, >> contribution launch, >> contribution client >> >> Personally I'd like to see sample contributions be presented as such >> and be separate from the launchers that start them up. So generally >> the pattern would be. >> >> contribution build = mvn or ant or IDE in the contribution module >> contribution test = mvn or ant or IDE in the contribution module >> contribution launch = command line launcher or script that runs the launcher >> contribution client = separate module >> > > I like the general ideas, some comments without any conclusions: > > - if the client is in a separate module then both launch and client > will need to use distributed domain support.
Some options 1/ Use local SCAClinet 2/ Use remote SCAClient and distributed domian 3/ Use interoperable binding I would be good if we can do some of each. It comes down to how we launche the contribution 1/ the contribution launcher module (which remember I would like to be separate from the contribution) contains the client class 2/ the contribution launcher module is separate from the client launcher module 3/ the client launcher just fluffs up a remote (JAXWS for example) Maybe we could use the different basic samples to differentiate, e.g. 1 = calculator 2 = helloworld 3 = another > > - if the test is actually running the contribution with Tuscany (as > opposed to being just simple unit tests of the classes) then its going > to need to include similar code and dependencies as the launch and > client agreed. maybe we should stick to unit tests. A source module for a WAR is unlikely to actually deploy the war as part of unit test I guess. > > - it seems like there are two types of samples - samples demonstrating > SCA, or samples demonstrating running Tuscany. Maybe it would help if > we more clearly separated these, eg the calculator-equinox sample is > really showing how to run Tuscany in Equinox, it doesn't need to > include the calculator contribution code and instead could just use > the actual calculator sample contribution. The > sample/webapp/helloworld sample does something to that by using the > contribution from sample/helloworld and running it within a webapp > runtime. And there are also samples that demonstrate a level of integration. So we have SCA Samples binding-ws-calculator implementation-java-calculator Tuscany Samples launcher-equinox-calculator distributed-osgi-calculator webapp-calculator Application Samples store webapp-store Is that getting closer? > >> This seems to be the case to a certain extent already for some of the >> helloworld based samples when combined with the helloworld-scaclient. >> In the helloworld case the contribution launch is currently provided >> by the module itself. To me this is less clear in instructing the user >> what a contribution is all about and how to handle one in real life >> but I'm not so opposed to suggest removing it. >> > > I quite like being able to run a contribution with mvn tuscany:run, > though it obviously only works with mvn so if we're supporting Ant we > need something else as well (which we do have currently with the > bin/tuscany.bat in a binary distribution). Right, and I think we need to decide once and for all what we're going to do about launchers. It seems complicated at the moment. > >> Anyhow, how do people feel about this approach in general? >> >> Simon >> -- >> Apache Tuscany committer: tuscany.apache.org >> Co-author of a book about Tuscany and SCA: tuscanyinaction.com >> > Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
