tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Laws <simonsl...@googlemail.com>
Subject Re: Samples tidy up
Date Fri, 07 May 2010 08:04:42 GMT
On Thu, May 6, 2010 at 2:16 PM, Simon Laws <simonslaws@googlemail.com> wrote:
> On Thu, May 6, 2010 at 2:12 PM, ant elder <antelder@apache.org> wrote:
>> On Thu, May 6, 2010 at 2:07 PM, Simon Laws <simonslaws@googlemail.com> wrote:
>>> On Thu, May 6, 2010 at 12:42 PM, Simon Laws <simonslaws@googlemail.com>
wrote:
>>>> On Thu, May 6, 2010 at 12:05 PM, ant elder <antelder@apache.org> wrote:
>>>>> On Thu, May 6, 2010 at 11:47 AM, Simon Laws <simonslaws@googlemail.com>
wrote:
>>>>>> On Thu, May 6, 2010 at 11:35 AM, ant elder <ant.elder@gmail.com>
wrote:
>>>>>>> What if anything do we need to do to tidy up the samples for
the
>>>>>>> upcoming release? Consistency across similar types of samples
seems
>>>>>>> like it could be improved for example so they're run in similar
ways.
>>>>>>> I've been slowly going through making the standalone contribution
>>>>>>> samples runnable using "mvn tuscany:run" and the webapp samples
with
>>>>>>> "mvn jetty:run", what else would people like to see?
>>>>>>>
>>>>>>>   ...ant
>>>>>>>
>>>>>>
>>>>>> Well personally I'd rename some of them so that the technology that
>>>>>> they're trying to demonstrate comes first (and I'm happy to do that
if
>>>>>> no-one objects). Some of them are general and their names are fine.
>>>>>> I'd also create a sub directory to hold samples with multiple parts,
>>>>>> e.g. a reference and a service. It just looks a jumble at the moment.
>>>>>>
>>>>>
>>>>> Could you give some examples of what you'd change? Here's the list of
>>>>> the top level samples:
>>>>>
>>>>> binding-ws-calculator
>>>>> calculator
>>>>> calculator-equinox
>>>>> calculator-osgi
>>>>> calculator-rmi-reference
>>>>> calculator-rmi-service
>>>>> dosgi-calculator
>>>>> dosgi-calculator-operations
>>>>> dosgi-dynamic-calculator
>>>>> dosgi-dynamic-calculator-operations
>>>>> helloworld
>>>>> helloworld-bpel
>>>>> helloworld-scaclient
>>>>> helloworld-spring
>>>>> helloworld-ws-sdo
>>>>> implementation-java-calculator
>>>>> store
>>>>> store-webapp
>>>>>
>>>>>   ...ant
>>>>>
>>>>
>>>> I would change this list to be...
>>>>
>>>>
>>>> binding-ws-calculator
>>>> binding-ws-sdo-helloworld
>>>> binding.sca-calculator
>>>> binding-rmi-calculator
>>>>    binding-rmi-calculator-reference
>>>>    binding-rmi-calculator-service
>>>> launcher-equinox-calculator
>>>> osgi-bundle-calculator
>>>> dosgi-calculator
>>>>    dosgi-calculator
>>>>    dosgi-calculator-operations
>>>> dosgi-dynamic-calculator
>>>>    dosgi-dynamic-calculator
>>>>    dosgi-dynamic-calculator-operations
>>>> implementation-java-calculator
>>>> implementation-java-helloworld
>>>> implementation-bpel-helloworld
>>>> implementation-spring-helloworld
>>>> scaclient-helloworld
>>>> store
>>>> store-webapp
>>>>
>>>> Simon
>>>>
>>>> --
>>>> Apache Tuscany committer: tuscany.apache.org
>>>> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>>>>
>>>
>>> Another thing I'm concerned about re. samples is that we don't now
>>> have good representation in itest/distribution. Am looking at if we
>>> can pull some more in (particularly one of the osgi based ones as we
>>> keep breaking the osgi based otest runtime). I note that quite a few
>>> have been removed recently, e.g. the webapp ones. Were these the ones
>>> that were proving unreliable?
>>>
>>
>> The tests are now included in the indivdual webapp modules. I did say
>> why in the commit log:
>> http://apache.markmail.org/message/eollllnqrg5mjqpx
>>
>> Remove the idstribution webapp tests. These didn't work well for a number of
>> reasons. they didn't test what was in the distribution as the distribution
>> doesn't include the built webapps. Because they need a dependency on the
>> distribution all the all distro dependencies get on the classpath so they're not
>> testing what is included in the webapp. There seems to be bugs oin the cargo
>> plugin so that it doesn't free up all its resourecs till the very end of the
>> build
>>
>>   ...ant
>>
>
> k, seems reasonable, we then need to pull the non-webapp ones in.
>
> Simon
>
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>

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

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.

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

Mime
View raw message