2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Florian MOGA <mo...@gmail.com>]

Hi,

I've decided to open a separate thread for this discussion as this topic is
big enough. I've tried all the samples from 2.0-beta2 rc2 and here are my
findings:

- sample-scdl-include-contribution (fails to load contribution when using
mvn tuscany:run, is there another way to start the runtime for this sample?)
- sample-dosgi-calculator-operations (org.osgi.framework.BundleException:
The bundle could not be resolved.)
- sample-dosgi-dynamic-calculator-operations
(org.osgi.framework.BundleException: The bundle could not be resolved.)
- sample-implementation-bpel-contribution (fails to load contribution when
using mvn tuscany:run, is there another way to start the runtime for this
sample?)
- sample-implementation-bpel-webapp ("Cant find BPEL Process" at startup)
- sample-implementation-composite-helloworld-contribution
(java.lang.IllegalArgumentException: Contribution not found as file or
dependency: ..\helloworld\target\sample-helloworld.jar)
- sample-implementation-composite-helloworld-ws-contribution
(java.lang.IllegalArgumentException: Contribution not found as file or
dependency: ..\helloworld-recursive\target\sample-helloworld-recursive.jar)
- sample-implementation-java-calculator-async-contribution (Caused by:
org.xml.sax.SAXParseException; systemId: http://calculator/; lineNumber: 2;
columnNumber: 132; The value of the attribute
"prefix="xmlns",localpart="ns4",rawname="xmlns:ns4"" is invalid. Prefixed
namespace bindings may not be empty.)
- sample-implementation-script-calculator(Caused by:
java.lang.IllegalStateException: Provider factory not found for class:
org.apache.tuscany.sca.implementation.script.impl.ScriptImplementationImpl)
- sample-implementation-spring-helloworld-webapp (fails at startup)
- sample-implementation-web-helloworld-js-client-webapp (functionality
broken)
- sample-implementation-web-helloworld-jsf-webapp (functionality broken)
- sample-sca-client-calculator(Caused by: java.lang.IllegalStateException:
Provider factory not found for class:
org.apache.tuscany.sca.implementation.script.impl.ScriptImplementationImpl)
- sample-sca-client-helloworld (Caused by: java.lang.IllegalStateException:
Provider factory not found for class:
org.apache.tuscany.sca.implementation.script.impl.ScriptImplementationImpl)
- shell (scripts don't load successfully)
- maven-osgi-junit (exceptions in junit log)
- sample-store (tests pass but when using Launch.java ->
ClassNotFoundException)
- feed in sample-store-webapp returns 404
- eightball-webapp (when clicking Ask returns 500)

There are samples that don't have Java classes or unit tests as launchers so
I've started them using mvn tuscany:run. Let me know if those samples
should've been launched differently.

How should we approach all those issues? It might worth having the
discussion about the consistent way of running samples now and applying
changes along with fixing the samples. Same with documentation.

Florian

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@gmail.com>]

On Mon, Feb 7, 2011 at 11:04 AM, Florian Moga <mo...@gmail.com> wrote:
> I totally agree but in my estimation this operation requires at least one or
> two weeks of work and we haven't agreed yet on the format of the
> documentation and what are the required launchers. We're already in RC2,
> can't we just make the release with the samples as they are now (without the
> ones that are broken and can't be fixed in a reasonable amount of time)?
> After this we can spin beta3 and start working on samples based on what we
> agree meanwhile.
>

I'm tempted to say lets just go for it and start right away now while
we have the momentum and willing people. If something comes up that
someone really really needs to get out in a release then we could
always take a release branch from an SVN revision before we started
this messing with the samples.

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Florian Moga <mo...@gmail.com>]

I totally agree but in my estimation this operation requires at least one or
two weeks of work and we haven't agreed yet on the format of the
documentation and what are the required launchers. We're already in RC2,
can't we just make the release with the samples as they are now (without the
ones that are broken and can't be fixed in a reasonable amount of time)?
After this we can spin beta3 and start working on samples based on what we
agree meanwhile.

On Mon, Feb 7, 2011 at 12:42 PM, Simon Laws <si...@googlemail.com>wrote:

> > I think we're in violent agreement here!  Let's pick a small and
> > useful set of high-quality samples to include in the release, then
> > make sure (by automated tests as far as possible) that these samples
> > continue to work in future releases.  All other samples would go
> > somewhere else in svn (unreleased/samples?) which would be much more
> > of a mixed bag.  Newly created samples would be added to the mixed bag.
> >
> > In future major releases, we could (if we want to) take carefully
> > chosen samples out of the mixed bag and "promote" them to be added
> > to the release.  The reverse is also possible, where we could "retire"
> > a released sample that no longer seems to be serving much of a useful
> > purpose, by moving it from the released samples to the mixed bag.
> >
> >  Simon
> >
> >
>
> +1. I would add (as it's not clear to me from this thread) that we
> should complete those samples that we choose for this limited set.
>
> - they work
> - the are run automatically in the build so we can detect if they fail
> in the future
> - they can be run easily by the user, e.g.. simple run command, no
> need to compile first, usable from Eclipse ???
> - documentation is in place in the format that we ultimately want it
> to appear in
>
> We can then use this as the pattern for reintroducing whichever
> samples are deemed to be appropriate in the future.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Laws <si...@googlemail.com>]

> I think we're in violent agreement here!  Let's pick a small and
> useful set of high-quality samples to include in the release, then
> make sure (by automated tests as far as possible) that these samples
> continue to work in future releases.  All other samples would go
> somewhere else in svn (unreleased/samples?) which would be much more
> of a mixed bag.  Newly created samples would be added to the mixed bag.
>
> In future major releases, we could (if we want to) take carefully
> chosen samples out of the mixed bag and "promote" them to be added
> to the release.  The reverse is also possible, where we could "retire"
> a released sample that no longer seems to be serving much of a useful
> purpose, by moving it from the released samples to the mixed bag.
>
>  Simon
>
>

+1. I would add (as it's not clear to me from this thread) that we
should complete those samples that we choose for this limited set.

- they work
- the are run automatically in the build so we can detect if they fail
in the future
- they can be run easily by the user, e.g.. simple run command, no
need to compile first, usable from Eclipse ???
- documentation is in place in the format that we ultimately want it
to appear in

We can then use this as the pattern for reintroducing whichever
samples are deemed to be appropriate in the future.

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Mike Edwards <mi...@gmail.com>]

On 07/02/2011 12:05, ant elder wrote:
> On Mon, Feb 7, 2011 at 8:51 AM, Simon Nash<na...@apache.org>  wrote:
<snip>
>> I think we're in violent agreement here!  Let's pick a small and
>> useful set of high-quality samples to include in the release, then
>> make sure (by automated tests as far as possible) that these samples
>> continue to work in future releases.  All other samples would go
>> somewhere else in svn (unreleased/samples?) which would be much more
>> of a mixed bag.  Newly created samples would be added to the mixed bag.
>>
>> In future major releases, we could (if we want to) take carefully
>> chosen samples out of the mixed bag and "promote" them to be added
>> to the release.  The reverse is also possible, where we could "retire"
>> a released sample that no longer seems to be serving much of a useful
>> purpose, by moving it from the released samples to the mixed bag.
>>
>>   Simon
>>
>>
>
> I see, ok well i guess i'd be willing to give that a try. We've not
> been very good at finding consensus in the past which is one of the
> reasons we've ended up with this "anyone can do anything" approach so
> i can see there may be problems, but it will be an interesting
> experiment.
>
>     ...ant
>
Folks,

Let me make a proposal that we can implement right now for Beta2.

Remove all samples from the build EXCEPT for the following, which we make work "out of the box":

getting-started\helloworld-contribution
getting-started\helloworld-webapp

I think that for the moment, we can put in an HTML file which then points at all the other samples, 
but back in the repo, with a brief explanation as to what they do and what they show.

Over time, we can add back more samples into the build, but only once they are brought up to scratch.

Something we need to concentrate on is to make sure that any documentation is correct and especially 
any suggested ways of running the samples actually work - at the moment, the READMEs for the 
helloworld samples simply don't work if you follow the instructions in the READMEs.

I think that this minimal approach allows us to make quick progress while improving the experience 
for end users.


Yours,  Mike.

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@gmail.com>]

On Mon, Feb 7, 2011 at 8:51 AM, Simon Nash <na...@apache.org> wrote:
> ant elder wrote:
>>
>> On Sun, Feb 6, 2011 at 10:36 PM, Simon Nash <na...@apache.org> wrote:
>>
>>>> I do agree good quality samples are important for users though. Maybe
>>>> if we have this more strict quality approach then we also need to do
>>>> some vetting of what goes into samples so there isn't so many of them
>>>> and try to include just a few main ones in the releases, perhaps with
>>>> others available in SVN which we document as available?
>>>>
>>>>  ...ant
>>>>
>>>>
>>> That's exactly what I was suggesting.  Quality is more important than
>>> quantity.  Let's be selective and only include samples in a release if
>>> they are working and have some documentation saying how to run them.
>>> For those that make the cut, I think there is a requirement to keep
>>> them working in future releases (both major and minor), so let's make
>>> the selection with that in mind.
>>>
>>
>> That wasn't quite what i was suggesting, I meant a include only a
>> small and controlled set of samples of samples. I don't think it
>> scales with everyone able to add any old sample they happen to like
>> and have that require for ever more that it is manually reviewed by
>> everyone at every release time and any issues be release blockers.
>>
>>  ...ant
>>
>>
> I think we're in violent agreement here!  Let's pick a small and
> useful set of high-quality samples to include in the release, then
> make sure (by automated tests as far as possible) that these samples
> continue to work in future releases.  All other samples would go
> somewhere else in svn (unreleased/samples?) which would be much more
> of a mixed bag.  Newly created samples would be added to the mixed bag.
>
> In future major releases, we could (if we want to) take carefully
> chosen samples out of the mixed bag and "promote" them to be added
> to the release.  The reverse is also possible, where we could "retire"
> a released sample that no longer seems to be serving much of a useful
> purpose, by moving it from the released samples to the mixed bag.
>
>  Simon
>
>

I see, ok well i guess i'd be willing to give that a try. We've not
been very good at finding consensus in the past which is one of the
reasons we've ended up with this "anyone can do anything" approach so
i can see there may be problems, but it will be an interesting
experiment.

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Nash <na...@apache.org>]

ant elder wrote:
> On Sun, Feb 6, 2011 at 10:36 PM, Simon Nash <na...@apache.org> wrote:
> 
>>> I do agree good quality samples are important for users though. Maybe
>>> if we have this more strict quality approach then we also need to do
>>> some vetting of what goes into samples so there isn't so many of them
>>> and try to include just a few main ones in the releases, perhaps with
>>> others available in SVN which we document as available?
>>>
>>>   ...ant
>>>
>>>
>> That's exactly what I was suggesting.  Quality is more important than
>> quantity.  Let's be selective and only include samples in a release if
>> they are working and have some documentation saying how to run them.
>> For those that make the cut, I think there is a requirement to keep
>> them working in future releases (both major and minor), so let's make
>> the selection with that in mind.
>>
> 
> That wasn't quite what i was suggesting, I meant a include only a
> small and controlled set of samples of samples. I don't think it
> scales with everyone able to add any old sample they happen to like
> and have that require for ever more that it is manually reviewed by
> everyone at every release time and any issues be release blockers.
> 
>   ...ant
> 
> 
I think we're in violent agreement here!  Let's pick a small and
useful set of high-quality samples to include in the release, then
make sure (by automated tests as far as possible) that these samples
continue to work in future releases.  All other samples would go
somewhere else in svn (unreleased/samples?) which would be much more
of a mixed bag.  Newly created samples would be added to the mixed bag.

In future major releases, we could (if we want to) take carefully
chosen samples out of the mixed bag and "promote" them to be added
to the release.  The reverse is also possible, where we could "retire"
a released sample that no longer seems to be serving much of a useful
purpose, by moving it from the released samples to the mixed bag.

   Simon

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@gmail.com>]

On Sun, Feb 6, 2011 at 10:36 PM, Simon Nash <na...@apache.org> wrote:

>> I do agree good quality samples are important for users though. Maybe
>> if we have this more strict quality approach then we also need to do
>> some vetting of what goes into samples so there isn't so many of them
>> and try to include just a few main ones in the releases, perhaps with
>> others available in SVN which we document as available?
>>
>>   ...ant
>>
>>
> That's exactly what I was suggesting.  Quality is more important than
> quantity.  Let's be selective and only include samples in a release if
> they are working and have some documentation saying how to run them.
> For those that make the cut, I think there is a requirement to keep
> them working in future releases (both major and minor), so let's make
> the selection with that in mind.
>

That wasn't quite what i was suggesting, I meant a include only a
small and controlled set of samples of samples. I don't think it
scales with everyone able to add any old sample they happen to like
and have that require for ever more that it is manually reviewed by
everyone at every release time and any issues be release blockers.

  ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Nash <na...@apache.org>]

ant elder wrote:
> On Sun, Feb 6, 2011 at 2:44 PM, Simon Nash <na...@apache.org> wrote:
>> Florian MOGA wrote:
>>> I've just checked out "mvn ant:ant" and seems to do a decent job in
>>> generating an ant build file.
>>> Figuring out what should samples look like imply taking other decisions
>>> first (how will documentation look like, what type of launcher is required,
>>> ...). So, for now I'd suggest to temporarily move the samples that don't
>>> work at all and require a reasonable amount of resources to fix (most of
>>> them are trivial fixes so there will be a fairly small number that will get
>>> moved). IMO that should be enough to ship the release. After that we might
>>> need to first agree on the other topics in order to have a knowledgeable
>>> context for this discussion.
>>>
>> +1 for this approach.  See my comments below for what I think it means
>> for a sample to "work".
>>
>>> On Sun, Feb 6, 2011 at 1:48 PM, ant elder <ant.elder@gmail.com
>>> <ma...@gmail.com>> wrote:
>>>
>>>    On Sun, Feb 6, 2011 at 11:32 AM, Simon Nash <nash@apache.org
>>>    <ma...@apache.org>> wrote:
>>>     > Florian MOGA wrote:
>>>     >>
>>>     >> Current naming with beta isn't that flexible. We could continue
>>>    doing a
>>>     >> lot of betaX releases or start naming betaX.X. I'm fine with
>>>    both of them.
>>>     >> After we get 2.0 out we can start having 2.0.1, 2.0.2 ... 2.1,
>>>    2.1.1, ....,
>>>     >> 2.2 and things will get more obvious.
>>>     >>
>>>     >> Regarding samples, we can either move them to unreleased/ and
>>>    move them
>>>     >> back as they get fixed or we can just open a ticket with
>>>    subtasks for each
>>>     >> sample to keep track of them. I assume we're now doing a 'minor'
>>>    release so
>>>     >> doesn't really matter at the moment.
>>>     >>
>>>     > IMO it would be better to only include samples that work.  It's
>>>     > frustrating and confusing for users when they attempt to run a
>>> sample
>>>     > that's included in a release and find that it doesn't work.
>>>     >
>>>     > Are there a few samples that could be got working quite easily?
>>>     > If so, I think it would be good to include those few in this release
>>>     > and move the rest to unreleased/ until the next major release.
>>>     > If the release includes working samples (even a few) then we could
>>>     > regard it as a "major" release.
>>>     >
>>>     >  Simon
>>>     >
>>>
>>>    That sounds reasonable but what does "work" mean? Up till now we've
>>>    had no minimum standard so anyone can add anything to samples/ and it
>>>    gets included in a release. I'd probably in favour of tightening that
>>>    up a bit now but I wonder if we'd agree on a minimum set of
>>>    requirements.
>>>
>>>    We have samples with no Ant build, no doc, no obvious way of running
>>>    them, and not even a sentence in a README saying what the purpose of
>>>    the sample is, but some of them do still "work" if you happen to know
>>>    what to do with it. Must there be proper tests so we know if the
>>>    sample gets broken? What if someone doesn't particularly care about
>>>    Ant builds so doesn't write a build.xml, is that sample excluded or is
>>>    a release held up till someone else write the build file?
>>>
>>>      ...ant
>>>
>>>
>> From a user perspective, I think at a minimum:
>>  1) There must be instructions saying how to build and run the sample and
>>    what the sample should do if it runs successfully.
>>  2) The sample must build and run successfully if the user follows the
>>    instructions provided.
>>
>> The other things you mentioned are desirable but not essential:
>>  3) an ant script for building and/or running the sample
>>  4) automated tests for ensuring that the sample works
>>
>> When someone is creating a new sample that doesn't yet meet the minimum
>> release requirements, I think it should go in unreleased/ initially and
>> be moved to the main trunk when it meets the release requirements.
>>
>>  Simon
>>
>>
> 
> An issue with that approach is that it will make getting releases out
> harder as there's a good chance some sample will have some problem and
> someone will insist on a respin to fix it.
> 
Once a sample is working, it should continue to work.  If it stops working
then this presumably indicates a runtime problem, which should raise a
concern about whether the runtime code is in good enough shape to release.

> I think we need to find ways to make doing release easier so that we
> do them more often. We have most things automated now like legal
> stuff, header checking, and simplified NOTICE file which has helped a
> lot, but this new approach is going back to needing to spend ages
> manually reviewing and running all samples and opening things up for
> people to ask for more RC respins.
>
I don't understand why this approach would make releases harder to do.
If we eliminate the samples that aren't working, and avoid adding any
new samples in minor releases, this should reduce the time needed to
verify that the included samples are working.

> I do agree good quality samples are important for users though. Maybe
> if we have this more strict quality approach then we also need to do
> some vetting of what goes into samples so there isn't so many of them
> and try to include just a few main ones in the releases, perhaps with
> others available in SVN which we document as available?
> 
>    ...ant
> 
> 
That's exactly what I was suggesting.  Quality is more important than
quantity.  Let's be selective and only include samples in a release if
they are working and have some documentation saying how to run them.
For those that make the cut, I think there is a requirement to keep
them working in future releases (both major and minor), so let's make
the selection with that in mind.

   Simon

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Florian MOGA <mo...@gmail.com>]

Just to be clear, I'm totally +1 for doing major and minor releases. My
comment above was related to Simon's concern about how many samples are
actually working and isn't contrary to the major/minor approach. Fixing the
trivial ones shouldn't require more than a few days. Is it ok to spin RC3 on
Wednesday if no other build issues occur? I'm planning to spend the next 2
days on fixing as many samples as possible. Would it also be possible for
you guys to be present on IRC the next days if I'm reaching a dead end at
some point? Thanks.


On Sun, Feb 6, 2011 at 8:07 PM, ant elder <an...@gmail.com> wrote:

> On Sun, Feb 6, 2011 at 2:44 PM, Simon Nash <na...@apache.org> wrote:
> > Florian MOGA wrote:
> >>
> >> I've just checked out "mvn ant:ant" and seems to do a decent job in
> >> generating an ant build file.
> >> Figuring out what should samples look like imply taking other decisions
> >> first (how will documentation look like, what type of launcher is
> required,
> >> ...). So, for now I'd suggest to temporarily move the samples that don't
> >> work at all and require a reasonable amount of resources to fix (most of
> >> them are trivial fixes so there will be a fairly small number that will
> get
> >> moved). IMO that should be enough to ship the release. After that we
> might
> >> need to first agree on the other topics in order to have a knowledgeable
> >> context for this discussion.
> >>
> > +1 for this approach.  See my comments below for what I think it means
> > for a sample to "work".
> >
> >> On Sun, Feb 6, 2011 at 1:48 PM, ant elder <ant.elder@gmail.com
> >> <ma...@gmail.com>> wrote:
> >>
> >>    On Sun, Feb 6, 2011 at 11:32 AM, Simon Nash <nash@apache.org
> >>    <ma...@apache.org>> wrote:
> >>     > Florian MOGA wrote:
> >>     >>
> >>     >> Current naming with beta isn't that flexible. We could continue
> >>    doing a
> >>     >> lot of betaX releases or start naming betaX.X. I'm fine with
> >>    both of them.
> >>     >> After we get 2.0 out we can start having 2.0.1, 2.0.2 ... 2.1,
> >>    2.1.1, ....,
> >>     >> 2.2 and things will get more obvious.
> >>     >>
> >>     >> Regarding samples, we can either move them to unreleased/ and
> >>    move them
> >>     >> back as they get fixed or we can just open a ticket with
> >>    subtasks for each
> >>     >> sample to keep track of them. I assume we're now doing a 'minor'
> >>    release so
> >>     >> doesn't really matter at the moment.
> >>     >>
> >>     > IMO it would be better to only include samples that work.  It's
> >>     > frustrating and confusing for users when they attempt to run a
> >> sample
> >>     > that's included in a release and find that it doesn't work.
> >>     >
> >>     > Are there a few samples that could be got working quite easily?
> >>     > If so, I think it would be good to include those few in this
> release
> >>     > and move the rest to unreleased/ until the next major release.
> >>     > If the release includes working samples (even a few) then we could
> >>     > regard it as a "major" release.
> >>     >
> >>     >  Simon
> >>     >
> >>
> >>    That sounds reasonable but what does "work" mean? Up till now we've
> >>    had no minimum standard so anyone can add anything to samples/ and it
> >>    gets included in a release. I'd probably in favour of tightening that
> >>    up a bit now but I wonder if we'd agree on a minimum set of
> >>    requirements.
> >>
> >>    We have samples with no Ant build, no doc, no obvious way of running
> >>    them, and not even a sentence in a README saying what the purpose of
> >>    the sample is, but some of them do still "work" if you happen to know
> >>    what to do with it. Must there be proper tests so we know if the
> >>    sample gets broken? What if someone doesn't particularly care about
> >>    Ant builds so doesn't write a build.xml, is that sample excluded or
> is
> >>    a release held up till someone else write the build file?
> >>
> >>      ...ant
> >>
> >>
> > From a user perspective, I think at a minimum:
> >  1) There must be instructions saying how to build and run the sample and
> >    what the sample should do if it runs successfully.
> >  2) The sample must build and run successfully if the user follows the
> >    instructions provided.
> >
> > The other things you mentioned are desirable but not essential:
> >  3) an ant script for building and/or running the sample
> >  4) automated tests for ensuring that the sample works
> >
> > When someone is creating a new sample that doesn't yet meet the minimum
> > release requirements, I think it should go in unreleased/ initially and
> > be moved to the main trunk when it meets the release requirements.
> >
> >  Simon
> >
> >
>
> An issue with that approach is that it will make getting releases out
> harder as there's a good chance some sample will have some problem and
> someone will insist on a respin to fix it.
>
> I think we need to find ways to make doing release easier so that we
> do them more often. We have most things automated now like legal
> stuff, header checking, and simplified NOTICE file which has helped a
> lot, but this new approach is going back to needing to spend ages
> manually reviewing and running all samples and opening things up for
> people to ask for more RC respins.
>
> I do agree good quality samples are important for users though. Maybe
> if we have this more strict quality approach then we also need to do
> some vetting of what goes into samples so there isn't so many of them
> and try to include just a few main ones in the releases, perhaps with
> others available in SVN which we document as available?
>
>   ...ant
>

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@gmail.com>]

On Sun, Feb 6, 2011 at 2:44 PM, Simon Nash <na...@apache.org> wrote:
> Florian MOGA wrote:
>>
>> I've just checked out "mvn ant:ant" and seems to do a decent job in
>> generating an ant build file.
>> Figuring out what should samples look like imply taking other decisions
>> first (how will documentation look like, what type of launcher is required,
>> ...). So, for now I'd suggest to temporarily move the samples that don't
>> work at all and require a reasonable amount of resources to fix (most of
>> them are trivial fixes so there will be a fairly small number that will get
>> moved). IMO that should be enough to ship the release. After that we might
>> need to first agree on the other topics in order to have a knowledgeable
>> context for this discussion.
>>
> +1 for this approach.  See my comments below for what I think it means
> for a sample to "work".
>
>> On Sun, Feb 6, 2011 at 1:48 PM, ant elder <ant.elder@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>>    On Sun, Feb 6, 2011 at 11:32 AM, Simon Nash <nash@apache.org
>>    <ma...@apache.org>> wrote:
>>     > Florian MOGA wrote:
>>     >>
>>     >> Current naming with beta isn't that flexible. We could continue
>>    doing a
>>     >> lot of betaX releases or start naming betaX.X. I'm fine with
>>    both of them.
>>     >> After we get 2.0 out we can start having 2.0.1, 2.0.2 ... 2.1,
>>    2.1.1, ....,
>>     >> 2.2 and things will get more obvious.
>>     >>
>>     >> Regarding samples, we can either move them to unreleased/ and
>>    move them
>>     >> back as they get fixed or we can just open a ticket with
>>    subtasks for each
>>     >> sample to keep track of them. I assume we're now doing a 'minor'
>>    release so
>>     >> doesn't really matter at the moment.
>>     >>
>>     > IMO it would be better to only include samples that work.  It's
>>     > frustrating and confusing for users when they attempt to run a
>> sample
>>     > that's included in a release and find that it doesn't work.
>>     >
>>     > Are there a few samples that could be got working quite easily?
>>     > If so, I think it would be good to include those few in this release
>>     > and move the rest to unreleased/ until the next major release.
>>     > If the release includes working samples (even a few) then we could
>>     > regard it as a "major" release.
>>     >
>>     >  Simon
>>     >
>>
>>    That sounds reasonable but what does "work" mean? Up till now we've
>>    had no minimum standard so anyone can add anything to samples/ and it
>>    gets included in a release. I'd probably in favour of tightening that
>>    up a bit now but I wonder if we'd agree on a minimum set of
>>    requirements.
>>
>>    We have samples with no Ant build, no doc, no obvious way of running
>>    them, and not even a sentence in a README saying what the purpose of
>>    the sample is, but some of them do still "work" if you happen to know
>>    what to do with it. Must there be proper tests so we know if the
>>    sample gets broken? What if someone doesn't particularly care about
>>    Ant builds so doesn't write a build.xml, is that sample excluded or is
>>    a release held up till someone else write the build file?
>>
>>      ...ant
>>
>>
> From a user perspective, I think at a minimum:
>  1) There must be instructions saying how to build and run the sample and
>    what the sample should do if it runs successfully.
>  2) The sample must build and run successfully if the user follows the
>    instructions provided.
>
> The other things you mentioned are desirable but not essential:
>  3) an ant script for building and/or running the sample
>  4) automated tests for ensuring that the sample works
>
> When someone is creating a new sample that doesn't yet meet the minimum
> release requirements, I think it should go in unreleased/ initially and
> be moved to the main trunk when it meets the release requirements.
>
>  Simon
>
>

An issue with that approach is that it will make getting releases out
harder as there's a good chance some sample will have some problem and
someone will insist on a respin to fix it.

I think we need to find ways to make doing release easier so that we
do them more often. We have most things automated now like legal
stuff, header checking, and simplified NOTICE file which has helped a
lot, but this new approach is going back to needing to spend ages
manually reviewing and running all samples and opening things up for
people to ask for more RC respins.

I do agree good quality samples are important for users though. Maybe
if we have this more strict quality approach then we also need to do
some vetting of what goes into samples so there isn't so many of them
and try to include just a few main ones in the releases, perhaps with
others available in SVN which we document as available?

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Nash <na...@apache.org>]

Florian MOGA wrote:
> I've just checked out "mvn ant:ant" and seems to do a decent job in 
> generating an ant build file. 
> 
> Figuring out what should samples look like imply taking other decisions 
> first (how will documentation look like, what type of launcher is 
> required, ...). So, for now I'd suggest to temporarily move the samples 
> that don't work at all and require a reasonable amount of resources to 
> fix (most of them are trivial fixes so there will be a fairly small 
> number that will get moved). IMO that should be enough to ship the 
> release. After that we might need to first agree on the other topics in 
> order to have a knowledgeable context for this discussion.
> 
+1 for this approach.  See my comments below for what I think it means
for a sample to "work".

> On Sun, Feb 6, 2011 at 1:48 PM, ant elder <ant.elder@gmail.com 
> <ma...@gmail.com>> wrote:
> 
>     On Sun, Feb 6, 2011 at 11:32 AM, Simon Nash <nash@apache.org
>     <ma...@apache.org>> wrote:
>      > Florian MOGA wrote:
>      >>
>      >> Current naming with beta isn't that flexible. We could continue
>     doing a
>      >> lot of betaX releases or start naming betaX.X. I'm fine with
>     both of them.
>      >> After we get 2.0 out we can start having 2.0.1, 2.0.2 ... 2.1,
>     2.1.1, ....,
>      >> 2.2 and things will get more obvious.
>      >>
>      >> Regarding samples, we can either move them to unreleased/ and
>     move them
>      >> back as they get fixed or we can just open a ticket with
>     subtasks for each
>      >> sample to keep track of them. I assume we're now doing a 'minor'
>     release so
>      >> doesn't really matter at the moment.
>      >>
>      > IMO it would be better to only include samples that work.  It's
>      > frustrating and confusing for users when they attempt to run a sample
>      > that's included in a release and find that it doesn't work.
>      >
>      > Are there a few samples that could be got working quite easily?
>      > If so, I think it would be good to include those few in this release
>      > and move the rest to unreleased/ until the next major release.
>      > If the release includes working samples (even a few) then we could
>      > regard it as a "major" release.
>      >
>      >  Simon
>      >
> 
>     That sounds reasonable but what does "work" mean? Up till now we've
>     had no minimum standard so anyone can add anything to samples/ and it
>     gets included in a release. I'd probably in favour of tightening that
>     up a bit now but I wonder if we'd agree on a minimum set of
>     requirements.
> 
>     We have samples with no Ant build, no doc, no obvious way of running
>     them, and not even a sentence in a README saying what the purpose of
>     the sample is, but some of them do still "work" if you happen to know
>     what to do with it. Must there be proper tests so we know if the
>     sample gets broken? What if someone doesn't particularly care about
>     Ant builds so doesn't write a build.xml, is that sample excluded or is
>     a release held up till someone else write the build file?
> 
>       ...ant
> 
> 
 From a user perspective, I think at a minimum:
  1) There must be instructions saying how to build and run the sample and
     what the sample should do if it runs successfully.
  2) The sample must build and run successfully if the user follows the
     instructions provided.

The other things you mentioned are desirable but not essential:
  3) an ant script for building and/or running the sample
  4) automated tests for ensuring that the sample works

When someone is creating a new sample that doesn't yet meet the minimum
release requirements, I think it should go in unreleased/ initially and
be moved to the main trunk when it meets the release requirements.

   Simon

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Florian Moga <mo...@gmail.com>]

On Mon, Feb 7, 2011 at 10:57 PM, Florian Moga <mo...@gmail.com> wrote:

> How does the shell operate with webapps? I've tried loading
> helloworld-webapp with mvn tuscany:run and I got a ClassNotFoundException on
> a jetty related class. I've added jetty dependencies to the shell module and
> now i'm getting:
>
> Feb 7, 2011 8:33:48 PM
> org.apache.tuscany.sca.core.runtime.impl.EndpointReferenceBinderImpl []
> (ComponentReferenceTargetNotFound)
> WARNING: Component reference target not found at deployment time, it might
> be a remote service elsewhere in the SCA Domain so well try and resolve it
> again at runtime: {1}
> 2011-02-07 20:33:48.163::INFO:  Logging to STDERR via
> org.mortbay.log.StdErrLog
>
> Embedded error: org.apache.tuscany.sca.runtime.ActivationException:
> java.lang.UnsupportedOperationException
>
> Could you give me some tips on what to do next?
>
>
Are you able to start a webapp using the shell?

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Nash <na...@apache.org>]

ant elder wrote:
> On Tue, Apr 5, 2011 at 10:20 AM, Simon Nash <na...@apache.org> wrote:
>> Luciano Resende wrote:
>>> On Mon, Apr 4, 2011 at 9:12 AM, Raymond Feng <en...@gmail.com> wrote:
>>>> I like the "commit then review" approach much better. When we add samples
>>>> into trunk, we have the responsibility to keep them working (in the right
>>>> way).
>>> +1, And this might really be the reason for having this whole
>>> discussion. In Tuscany, usually people would dump samples into samples
>>> and only look into them when during the release time. Having a reduced
>>> number of samples will help, but sample ownership might be the main
>>> issue here.
>>>
>> I agree that sample code shouldn't be dumped into trunk with the expectation
>> that someone will get it into proper shape for the next release.
>>
>> Regarding ownership, this word might be interpreted in different ways by
>> different people.  If it means that someone who commits a new sample should
>> do the whole job of making sure that it meets all the requirements for
>> samples in trunk, I'm +1 for this.  Another interpretation of ownership
>> could
>> be to regard a particular individual as responsible for maintaining
>> particular
>> samples (or other parts of the codebase) on an ongoing basis.  In Tuscany we
>> don't have this kind of personal ownership but instead regard the whole
>> community as responsible, and I wouldn't want to see that change.
>>
>> For non-sample code that's added to trunk, I think we have general agreement
>> that the new code needs to build OK, have unit tests, and pass its unit
>> tests.
>>
>> For sample code that's added to trunk, all the above apply and there are
>> additional requirements that the sample includes documentation describing
>> what it does, how to run it, and the expected results from running it.
>> It's also a requirement that the sample runs correctly and does what the
>> documentation says it will do.
>>
>>  Simon
>>
>>
> 
> What we know from recent and past events is that there isn't really
> that much agreement on many things and that people may get upset if
> things are taken out of trunk. If you read back in the sample thread
> even something like the requirement to have a sample readme doesn't
> have universal support, and, if a readme is so banal that it doesn't
> add much over what you already get from the sample name then the
> existence of one doesn't really make the world that much of a better
> place. I think one of the most important things we can do is try to
> keep each other happy. We've a relatively small dev community so we
> should do what we can to keep everyone involved and productive and
> find ways to make space for everyone to do what we they think is
> important or useful.
> 
>    ...ant
> 
> 
Yes, keeping each other happy is definitely a good thing.  However,
let's not forget that we have users who will definitely not be happy
if we deliver releases with samples that don't work or have no
instructions for running them or have instructions that are wrong.
Also, certain members of our own community will not be happy if we
deliver releases that cause our users to be unhappy.

I'll start a separate discussion thread on whether our community
agrees with the principle of establishing some minimum standards
for the samples in trunk that we deliver in our released binary
disitributions.  If there's agreement on that, I'll start a discussion
on what those mimimum standards should be.

   Simon

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@gmail.com>]

On Mon, Apr 4, 2011 at 5:12 PM, Raymond Feng <en...@gmail.com> wrote:
> I like the "commit then review" approach much better. When we add samples
> into trunk, we have the responsibility to keep them working (in the right
> way).
> Thanks,
> Raymond

I agree. Its been interesting trying the alternative approach but i
don't think it really works for Tuscany.

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@gmail.com>]

On Tue, Apr 5, 2011 at 10:20 AM, Simon Nash <na...@apache.org> wrote:
> Luciano Resende wrote:
>>
>> On Mon, Apr 4, 2011 at 9:12 AM, Raymond Feng <en...@gmail.com> wrote:
>>>
>>> I like the "commit then review" approach much better. When we add samples
>>> into trunk, we have the responsibility to keep them working (in the right
>>> way).
>>
>> +1, And this might really be the reason for having this whole
>> discussion. In Tuscany, usually people would dump samples into samples
>> and only look into them when during the release time. Having a reduced
>> number of samples will help, but sample ownership might be the main
>> issue here.
>>
> I agree that sample code shouldn't be dumped into trunk with the expectation
> that someone will get it into proper shape for the next release.
>
> Regarding ownership, this word might be interpreted in different ways by
> different people.  If it means that someone who commits a new sample should
> do the whole job of making sure that it meets all the requirements for
> samples in trunk, I'm +1 for this.  Another interpretation of ownership
> could
> be to regard a particular individual as responsible for maintaining
> particular
> samples (or other parts of the codebase) on an ongoing basis.  In Tuscany we
> don't have this kind of personal ownership but instead regard the whole
> community as responsible, and I wouldn't want to see that change.
>
> For non-sample code that's added to trunk, I think we have general agreement
> that the new code needs to build OK, have unit tests, and pass its unit
> tests.
>
> For sample code that's added to trunk, all the above apply and there are
> additional requirements that the sample includes documentation describing
> what it does, how to run it, and the expected results from running it.
> It's also a requirement that the sample runs correctly and does what the
> documentation says it will do.
>
>  Simon
>
>

What we know from recent and past events is that there isn't really
that much agreement on many things and that people may get upset if
things are taken out of trunk. If you read back in the sample thread
even something like the requirement to have a sample readme doesn't
have universal support, and, if a readme is so banal that it doesn't
add much over what you already get from the sample name then the
existence of one doesn't really make the world that much of a better
place. I think one of the most important things we can do is try to
keep each other happy. We've a relatively small dev community so we
should do what we can to keep everyone involved and productive and
find ways to make space for everyone to do what we they think is
important or useful.

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Nash <na...@apache.org>]

Luciano Resende wrote:
> On Mon, Apr 4, 2011 at 9:12 AM, Raymond Feng <en...@gmail.com> wrote:
>> I like the "commit then review" approach much better. When we add samples
>> into trunk, we have the responsibility to keep them working (in the right
>> way).
> 
> +1, And this might really be the reason for having this whole
> discussion. In Tuscany, usually people would dump samples into samples
> and only look into them when during the release time. Having a reduced
> number of samples will help, but sample ownership might be the main
> issue here.
> 
I agree that sample code shouldn't be dumped into trunk with the expectation
that someone will get it into proper shape for the next release.

Regarding ownership, this word might be interpreted in different ways by
different people.  If it means that someone who commits a new sample should
do the whole job of making sure that it meets all the requirements for
samples in trunk, I'm +1 for this.  Another interpretation of ownership could
be to regard a particular individual as responsible for maintaining particular
samples (or other parts of the codebase) on an ongoing basis.  In Tuscany we
don't have this kind of personal ownership but instead regard the whole
community as responsible, and I wouldn't want to see that change.

For non-sample code that's added to trunk, I think we have general agreement
that the new code needs to build OK, have unit tests, and pass its unit tests.

For sample code that's added to trunk, all the above apply and there are
additional requirements that the sample includes documentation describing
what it does, how to run it, and the expected results from running it.
It's also a requirement that the sample runs correctly and does what the
documentation says it will do.

   Simon

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Luciano Resende <lu...@gmail.com>]

On Mon, Apr 4, 2011 at 9:12 AM, Raymond Feng <en...@gmail.com> wrote:
> I like the "commit then review" approach much better. When we add samples
> into trunk, we have the responsibility to keep them working (in the right
> way).

+1, And this might really be the reason for having this whole
discussion. In Tuscany, usually people would dump samples into samples
and only look into them when during the release time. Having a reduced
number of samples will help, but sample ownership might be the main
issue here.

-- 
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Florian Moga <mo...@gmail.com>]

It looks like in the end there's been a misunderstanding about the process.
Personally, I would like to have a "review first" approach as it helps
improving the code quality over time but that doesn't seem to work for us so
it's ok to move forward with the previous approach. Glad we're all speaking
the same language now.

Regarding the consistency of the samples, I consider this a very important
aspect which we should maintain as it helps a lot new users. Especially the
way the samples are launched. I'm saying this from my own experience with
Tuscany last year when I had a hard time understanding concepts partly
because I wasn't able to start the samples. I believe that a user starting
to look at Tuscany is much more concerned to understand components,
services, references, scdl rather than deployment environments in the early
stage. For that kind of experiments, we have the running-tuscany/ category
which is excellent for that. This is the reasoning behind me supporting the
shell all the time. It provides an easy to use, build tool agnostic way of
starting the samples and even more, gives the user the ability to interact
with components. I find this a suitable way of presenting the samples to the
users. Let me know if you feel different.

Florian


On Mon, Apr 4, 2011 at 7:12 PM, Raymond Feng <en...@gmail.com> wrote:

> I like the "commit then review" approach much better. When we add samples
> into trunk, we have the responsibility to keep them working (in the right
> way).
>
> Thanks,
> Raymond
>  *________________________________________________________________
>  Raymond Feng
> rfeng@apache.org
> Apache Tuscany PMC member and committer: tuscany.apache.org
> Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
> Personal Web Site: www.enjoyjava.com
> ________________________________________________________________*
>
> On Apr 4, 2011, at 9:04 AM, Simon Nash wrote:
>
> ant elder wrote:
>
> On Mon, Apr 4, 2011 at 2:14 PM, Simon Nash <na...@apache.org> wrote:
>
> Also in [1], I said that a new sample that doesn't yet meet the mandatory
>
> release requirements should go in unreleased/ initially.  AFAICT, the store
>
> sample does meet the mandatory release requirements, so I'm not sure why
>
> it was moved to unreleased/.
>
>
> Because without asking first there is no way of know if there is
>
> consensus with everyone to include something in trunk. I give up on
>
> this new approach to the samples, it is sucking away way to much time.
>
> Please from now on lets go back to trunk/samples working just the same
>
> as any other part of tuscany svn.
>
>   ...ant
>
> I think the process should work the other way round, i.e., that if
> a sample is committed to trunk and it doesn't meet the mandatory
> requirements (which we can discuss and hopefully agree), then it should
> be moved to unreleased/ until it does meet the mandatory requirements.
> Is this a workable approach?
>
>  Simon
>
>
>

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Raymond Feng <en...@gmail.com>]

I like the "commit then review" approach much better. When we add samples into trunk, we have the responsibility to keep them working (in the right way). 

Thanks,
Raymond
________________________________________________________________ 
Raymond Feng
rfeng@apache.org
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
________________________________________________________________

On Apr 4, 2011, at 9:04 AM, Simon Nash wrote:

> ant elder wrote:
>> On Mon, Apr 4, 2011 at 2:14 PM, Simon Nash <na...@apache.org> wrote:
>>> Also in [1], I said that a new sample that doesn't yet meet the mandatory
>>> release requirements should go in unreleased/ initially.  AFAICT, the store
>>> sample does meet the mandatory release requirements, so I'm not sure why
>>> it was moved to unreleased/.
>>> 
>> Because without asking first there is no way of know if there is
>> consensus with everyone to include something in trunk. I give up on
>> this new approach to the samples, it is sucking away way to much time.
>> Please from now on lets go back to trunk/samples working just the same
>> as any other part of tuscany svn.
>>   ...ant
> I think the process should work the other way round, i.e., that if
> a sample is committed to trunk and it doesn't meet the mandatory
> requirements (which we can discuss and hopefully agree), then it should
> be moved to unreleased/ until it does meet the mandatory requirements.
> Is this a workable approach?
> 
>  Simon
> 

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Laws <si...@googlemail.com>]

I added in a few "running tuscany" samples to see if we can get those
right. Things of note:

- There are a small set now. We can complete the set if people are happy
- I've added the minimum function required. So, for example,  there is
no ant build/run script under the JSE sample. That would go under an
Ant sample
- I've converted READMEs to OO format as per the top level but
generated linked HTML instead of PDF. Looks OK but there is a
potential maintenance overhead in the linking. If we like OO we could
generate a template for the sample docs.
- Some only have READMEs in at the moment. Again that's OK by me and
it seems appropriate to try to be complete
- There are repeats here when compared to getting started. Again it
seems appropriate to have a complete set here
- I've put a binary test contribution in the running-tuscany directory
rather than relying on some other sample module. This may not work for
all the samples and we do need to code somewhere. Looking to see how
far we can get with it.

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Luciano Resende <lu...@gmail.com>]

On Mon, Apr 4, 2011 at 9:04 AM, Simon Nash <na...@apache.org> wrote:
> ant elder wrote:
>>
>> On Mon, Apr 4, 2011 at 2:14 PM, Simon Nash <na...@apache.org> wrote:
>>
>>> Also in [1], I said that a new sample that doesn't yet meet the mandatory
>>> release requirements should go in unreleased/ initially.  AFAICT, the
>>> store
>>> sample does meet the mandatory release requirements, so I'm not sure why
>>> it was moved to unreleased/.
>>>
>>
>> Because without asking first there is no way of know if there is
>> consensus with everyone to include something in trunk. I give up on
>> this new approach to the samples, it is sucking away way to much time.
>> Please from now on lets go back to trunk/samples working just the same
>> as any other part of tuscany svn.
>>
>>   ...ant
>>
>>
> I think the process should work the other way round, i.e., that if
> a sample is committed to trunk and it doesn't meet the mandatory
> requirements (which we can discuss and hopefully agree), then it should
> be moved to unreleased/ until it does meet the mandatory requirements.
> Is this a workable approach?
>
>  Simon
>
>

+1, and most like, if we have the requirements cleared agreed, it will
be more like : could you please fix the violating items 1, 3 and 5 for
sample X or move it to unreleased.


-- 
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Nash <na...@apache.org>]

ant elder wrote:
> On Mon, Apr 4, 2011 at 2:14 PM, Simon Nash <na...@apache.org> wrote:
> 
>> Also in [1], I said that a new sample that doesn't yet meet the mandatory
>> release requirements should go in unreleased/ initially.  AFAICT, the store
>> sample does meet the mandatory release requirements, so I'm not sure why
>> it was moved to unreleased/.
>>
> 
> Because without asking first there is no way of know if there is
> consensus with everyone to include something in trunk. I give up on
> this new approach to the samples, it is sucking away way to much time.
> Please from now on lets go back to trunk/samples working just the same
> as any other part of tuscany svn.
> 
>    ...ant
> 
> 
I think the process should work the other way round, i.e., that if
a sample is committed to trunk and it doesn't meet the mandatory
requirements (which we can discuss and hopefully agree), then it should
be moved to unreleased/ until it does meet the mandatory requirements.
Is this a workable approach?

   Simon

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@gmail.com>]

On Mon, Apr 4, 2011 at 2:14 PM, Simon Nash <na...@apache.org> wrote:

> Also in [1], I said that a new sample that doesn't yet meet the mandatory
> release requirements should go in unreleased/ initially.  AFAICT, the store
> sample does meet the mandatory release requirements, so I'm not sure why
> it was moved to unreleased/.
>

Because without asking first there is no way of know if there is
consensus with everyone to include something in trunk. I give up on
this new approach to the samples, it is sucking away way to much time.
Please from now on lets go back to trunk/samples working just the same
as any other part of tuscany svn.

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Nash <na...@apache.org>]

Luciano Resende wrote:
> On Sun, Apr 3, 2011 at 12:10 PM, ant elder <an...@apache.org> wrote:
>> Luciano, you still haven't really said what it is you would like to
>> see done to get a release you'd be ok with. What we decided to do was
>> move all the samples out of trunk start cleaning them up and move them
>> back with consensus, ie email asking what people think could be
>> changed or fixed and when everyone is happy then move them back. That
>> is all.
> 
> Sorry, members of the community expressed that would be good to have
> samples on a release, I worked on the sample I wanted to see in the
> release, made sure it was working from a binary distribution, and
> notified the community [1] My expectation was that, if there was any
> issues, suggestions, etc, people would mention that on the thread, and
> I'd work on it... but what I got was to have the samples moved out of
> trunk [2].
> 
> I really don't know what to do, or what to say... because all the good
> things about "Apache Way" seems to NOT be working in here.
> 
> 
> [1] http://tuscany.markmail.org/thread/dqnoslswasw2vofb
> [2] http://tuscany.markmail.org/thread/mhudyb2n5x62qmul
> 
> 
> 
In the previous discussion on samples I gave my view of what's needed for
a sample to be included in a release (see [1]).  I believe that the store
sample meets all of these requirements.  (Disclaimer: I haven't run this
sample to make sure that it works.)  If it does work, then I am +1 on
including it in the next 2.0-betaX release.

Also in [1], I said that a new sample that doesn't yet meet the mandatory
release requirements should go in unreleased/ initially.  AFAICT, the store
sample does meet the mandatory release requirements, so I'm not sure why
it was moved to unreleased/.

Regarding ant support, I said in [2] that some of the samples should have
ant scripts, though I didn't think this was mandatory for every sample.

   Simon

[1] http://www.mail-archive.com/dev@tuscany.apache.org/msg15567.html
[2] http://www.mail-archive.com/dev@tuscany.apache.org/msg15679.html

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Luciano Resende <lu...@gmail.com>]

On Sun, Apr 3, 2011 at 12:10 PM, ant elder <an...@apache.org> wrote:
> Luciano, you still haven't really said what it is you would like to
> see done to get a release you'd be ok with. What we decided to do was
> move all the samples out of trunk start cleaning them up and move them
> back with consensus, ie email asking what people think could be
> changed or fixed and when everyone is happy then move them back. That
> is all.

Sorry, members of the community expressed that would be good to have
samples on a release, I worked on the sample I wanted to see in the
release, made sure it was working from a binary distribution, and
notified the community [1] My expectation was that, if there was any
issues, suggestions, etc, people would mention that on the thread, and
I'd work on it... but what I got was to have the samples moved out of
trunk [2].

I really don't know what to do, or what to say... because all the good
things about "Apache Way" seems to NOT be working in here.


[1] http://tuscany.markmail.org/thread/dqnoslswasw2vofb
[2] http://tuscany.markmail.org/thread/mhudyb2n5x62qmul



-- 
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

Luciano, you still haven't really said what it is you would like to
see done to get a release you'd be ok with. What we decided to do was
move all the samples out of trunk start cleaning them up and move them
back with consensus, ie email asking what people think could be
changed or fixed and when everyone is happy then move them back. That
is all. There are no "rules" that samples must or must not do, but the
feeling was that we should try to get things a bit more consistent.
I've already tried to explain that to you and pointed you at the old
discussions, I'm sorry if you think I'm doing this wrong or something,
i think we did know at the time it was going to be hard when we
started this new approach, perhaps its time to give up with it. I've
asked some others to comment on this thread to see if that might help
make some progress.

   ...ant

On Sun, Apr 3, 2011 at 4:38 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Sun, Apr 3, 2011 at 12:32 AM, ant elder <an...@apache.org> wrote:
>> On Sun, Apr 3, 2011 at 5:52 AM, Luciano Resende <lu...@gmail.com> wrote:
>>> On Sat, Apr 2, 2011 at 1:59 PM, ant elder <an...@apache.org> wrote:
>>>>> I'd add the expectations and/or user experience when running the
>>>>> samples, as it seems that we are droping support for ant completely
>>>>> (which to me is ok, as I mostly use maven), but I'm not sure if users
>>>>> are ok with that.
>>>>>
>>>>
>>>> At least Mike and Simon L have said in this thread they prefer Ant
>>>> builds to Maven for the samples. Ant is harder because of all the
>>>> dependencies and where to find the dependencies. There has been things
>>>> suggested in this thread, and there are the previous attempts, and
>>>> we've all the manifest jars gen'd for each extension now in the binary
>>>> distribution, but it all seems a bit complicated and hard to find
>>>> something that looks very elegant so i decided not to worry about Ant
>>>> builds for now and focus on Maven (which is hard enough to find
>>>> something everyone likes on its own), if someone else wants to look at
>>>> Ant now that would be great by me.
>>>>
>>>
>>> I just want to raise the issue that, in real deployment scenarios,
>>> users will not use the tuscany/maven plugin. Also, what's the support
>>> for environments such as OSGi, etc ? That's why I think to demonstrate
>>> different ways to run the samples, which is aligned with the scenarios
>>> used by our users in real deployments.
>>>
>>
>> I'm still not quite getting what you are saying we should actually do.
>>
>> If we have a contribution or webapp sample we do have several ways of
>> running them, one of them is using the tuscany plugin, others are
>> things like using the scripts to start the Shell, or including the
>> Jetty or Tomcat plugin to start jetty/Tomcat, one of the
>> running-tuscany samples to start a Tuscany runtime etc, and we have
>> samples that show lots of different ways of doing things in the
>> learning-more and running-tuscany samples,
>>
>> But, the helloworld contribution samples dont do anything by
>> themselves without having something within the sample build to run it
>> in Tuscany, are you saying that you think the Tuscany plugin MUST NOT
>> be one of these ways? Eg I pointed you at the helloworld-contribution2
>> sample in unreleased as an example of not including any way to run it
>> - do you prefer approach? Or do you have some other approach to
>> suggest?
>>
>
> I was under the impression that the Tuscany plugin was going to be the
> ONLY way to run the samples. If that's not the case, then, why all the
> samples were pulled out ? And why store sample that is running ok from
> a distribution from both ant and maven is not "ready" to be in the
> sample folder ?
>
>
>>> Having said that, consistency and simplicity are always welcome.
>>>
>>>>> Also, we should clarify what we mean by consistent build, particular
>>>>> regarding "base + extension", if we are using the base pom, fine, if
>>>>> we are using the base jar, sorry, but I believe couple of us don't
>>>>> agree with mandating that. And, reviewing the getting-started sample,
>>>>> it seems that you are forcing to use the base jar.
>>>>>
>>>>
>>>> Firstly, nothing is being unilaterally mandated or forced to be used.
>>>> We've been discussing how to do the samples for months now, trying to
>>>> work out consensuses and compromises and I've been updating the
>>>> helloworld samples in the unreleased folder as we go and I've asked a
>>>> bunch of times for feedback and comments on the approach they use and
>>>> no one ever mentioned or complained about them using the base jar, so
>>>> thats how they are when moved back into trunk and the samples wiki
>>>> page was updated based on what they did.
>>>>
>>>> I don't really like using the base pom type dependency, unless there
>>>> are good reasons it seems better to me to provide a single jar for
>>>> groupings we know are useful than to have pom type dependencies. We've
>>>> talked about this before, eg one from me is:
>>>> http://apache.markmail.org/message/qttcn6ngmllptaq2. What don't you
>>>> like about the base jar?
>>>>
>>>
>>> I don't want to restart the same discussion again, [1] is one of those
>>> discussions, and as far as I remember, various members of the
>>> community wanted to go with soft-dependency via pom (thus us creating
>>> the features a long time ago
>>
>> The pom type features were created to build distributions not for
>> users to use as dependency groups, it was just an accidental
>> misunderstaning that they started getting used like that. You never
>> answer what it is you don't like about the base jar or address the
>> points I raise against the the pom type approach in
>> http://apache.markmail.org/message/qttcn6ngmllptaq2, but surely if
>> you're arguing that there are many different environments and
>> approaches to using Tuscany which we should be showing and supporting
>> in the samples then the base jar is one of the valid ways?
>>
>
> The only way I'd agree with a shadded jar usage, is if they are
> completely optional and more like an distribution option which I
> though you had started in the past [1]
>
> [1] https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/distribution/aggregations/
>
>>> , and if I remember correctly, Simon L
>>> creating the base-runtime pom recently), and you were the only one
>>> forcing the usage of the jar.
>>>
>>> [1] http://markmail.org/message/jkkuqmthnspns64q
>>>
>>>> So what shall we do about this, how can we find consensus on an approach?
>>>>
>>>
>>> See above, I really thought we had consensus on this case, but you
>>> keep trying to bring this up again, or we keep finding it when we
>>> spend tons of time investigating issues.
>>>
>>
>>
>>>> We could avoid it for the contribution samples by not including a test
>>>> that starts tuscany so they just need the sca-api dependency, eg as
>>>> was done in this sample -
>>>> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/helloworld-contribution2/
>>>>
>>>> We could use the individual module dependencies directly and perhaps
>>>> have another go at merging some of those together so there's not so
>>>> many.
>>>>
>>>> Perhaps just don't worry about having a consistent approach across the
>>>> samples and instead people just do what they like?
>>>>
>>>
>>>  I think we need to find the right balance here, although consistency
>>> is good, if the side effect of this is to not have any sample that
>>> demonstrates different deployment scenarios, this is also not good.
>>>
>>
>> Ok but what exactly are you suggesting we do now?
>>
>> I would like to do a release to get the latest code out but it sounds
>> like you wont help or vote for a release with the samples as they are.
>> What do we need to do so that we can do a release?
>>
>>    ...ant
>>
>
> It's my duty as a a committer and PMC member to review and approve the
> releases of the project. All of this discussions started because I was
> helping getting samples into trunk for the release and you moved them
> out of the trunk to the unreleased folder. Now, if you think I'm not
> helping, or that I'm not going to vote to something because I don't
> like it, sorry !!!
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Luciano Resende <lu...@gmail.com>]

On Sun, Apr 3, 2011 at 12:32 AM, ant elder <an...@apache.org> wrote:
> On Sun, Apr 3, 2011 at 5:52 AM, Luciano Resende <lu...@gmail.com> wrote:
>> On Sat, Apr 2, 2011 at 1:59 PM, ant elder <an...@apache.org> wrote:
>>>> I'd add the expectations and/or user experience when running the
>>>> samples, as it seems that we are droping support for ant completely
>>>> (which to me is ok, as I mostly use maven), but I'm not sure if users
>>>> are ok with that.
>>>>
>>>
>>> At least Mike and Simon L have said in this thread they prefer Ant
>>> builds to Maven for the samples. Ant is harder because of all the
>>> dependencies and where to find the dependencies. There has been things
>>> suggested in this thread, and there are the previous attempts, and
>>> we've all the manifest jars gen'd for each extension now in the binary
>>> distribution, but it all seems a bit complicated and hard to find
>>> something that looks very elegant so i decided not to worry about Ant
>>> builds for now and focus on Maven (which is hard enough to find
>>> something everyone likes on its own), if someone else wants to look at
>>> Ant now that would be great by me.
>>>
>>
>> I just want to raise the issue that, in real deployment scenarios,
>> users will not use the tuscany/maven plugin. Also, what's the support
>> for environments such as OSGi, etc ? That's why I think to demonstrate
>> different ways to run the samples, which is aligned with the scenarios
>> used by our users in real deployments.
>>
>
> I'm still not quite getting what you are saying we should actually do.
>
> If we have a contribution or webapp sample we do have several ways of
> running them, one of them is using the tuscany plugin, others are
> things like using the scripts to start the Shell, or including the
> Jetty or Tomcat plugin to start jetty/Tomcat, one of the
> running-tuscany samples to start a Tuscany runtime etc, and we have
> samples that show lots of different ways of doing things in the
> learning-more and running-tuscany samples,
>
> But, the helloworld contribution samples dont do anything by
> themselves without having something within the sample build to run it
> in Tuscany, are you saying that you think the Tuscany plugin MUST NOT
> be one of these ways? Eg I pointed you at the helloworld-contribution2
> sample in unreleased as an example of not including any way to run it
> - do you prefer approach? Or do you have some other approach to
> suggest?
>

I was under the impression that the Tuscany plugin was going to be the
ONLY way to run the samples. If that's not the case, then, why all the
samples were pulled out ? And why store sample that is running ok from
a distribution from both ant and maven is not "ready" to be in the
sample folder ?


>> Having said that, consistency and simplicity are always welcome.
>>
>>>> Also, we should clarify what we mean by consistent build, particular
>>>> regarding "base + extension", if we are using the base pom, fine, if
>>>> we are using the base jar, sorry, but I believe couple of us don't
>>>> agree with mandating that. And, reviewing the getting-started sample,
>>>> it seems that you are forcing to use the base jar.
>>>>
>>>
>>> Firstly, nothing is being unilaterally mandated or forced to be used.
>>> We've been discussing how to do the samples for months now, trying to
>>> work out consensuses and compromises and I've been updating the
>>> helloworld samples in the unreleased folder as we go and I've asked a
>>> bunch of times for feedback and comments on the approach they use and
>>> no one ever mentioned or complained about them using the base jar, so
>>> thats how they are when moved back into trunk and the samples wiki
>>> page was updated based on what they did.
>>>
>>> I don't really like using the base pom type dependency, unless there
>>> are good reasons it seems better to me to provide a single jar for
>>> groupings we know are useful than to have pom type dependencies. We've
>>> talked about this before, eg one from me is:
>>> http://apache.markmail.org/message/qttcn6ngmllptaq2. What don't you
>>> like about the base jar?
>>>
>>
>> I don't want to restart the same discussion again, [1] is one of those
>> discussions, and as far as I remember, various members of the
>> community wanted to go with soft-dependency via pom (thus us creating
>> the features a long time ago
>
> The pom type features were created to build distributions not for
> users to use as dependency groups, it was just an accidental
> misunderstaning that they started getting used like that. You never
> answer what it is you don't like about the base jar or address the
> points I raise against the the pom type approach in
> http://apache.markmail.org/message/qttcn6ngmllptaq2, but surely if
> you're arguing that there are many different environments and
> approaches to using Tuscany which we should be showing and supporting
> in the samples then the base jar is one of the valid ways?
>

The only way I'd agree with a shadded jar usage, is if they are
completely optional and more like an distribution option which I
though you had started in the past [1]

[1] https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/distribution/aggregations/

>> , and if I remember correctly, Simon L
>> creating the base-runtime pom recently), and you were the only one
>> forcing the usage of the jar.
>>
>> [1] http://markmail.org/message/jkkuqmthnspns64q
>>
>>> So what shall we do about this, how can we find consensus on an approach?
>>>
>>
>> See above, I really thought we had consensus on this case, but you
>> keep trying to bring this up again, or we keep finding it when we
>> spend tons of time investigating issues.
>>
>
>
>>> We could avoid it for the contribution samples by not including a test
>>> that starts tuscany so they just need the sca-api dependency, eg as
>>> was done in this sample -
>>> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/helloworld-contribution2/
>>>
>>> We could use the individual module dependencies directly and perhaps
>>> have another go at merging some of those together so there's not so
>>> many.
>>>
>>> Perhaps just don't worry about having a consistent approach across the
>>> samples and instead people just do what they like?
>>>
>>
>>  I think we need to find the right balance here, although consistency
>> is good, if the side effect of this is to not have any sample that
>> demonstrates different deployment scenarios, this is also not good.
>>
>
> Ok but what exactly are you suggesting we do now?
>
> I would like to do a release to get the latest code out but it sounds
> like you wont help or vote for a release with the samples as they are.
> What do we need to do so that we can do a release?
>
>    ...ant
>

It's my duty as a a committer and PMC member to review and approve the
releases of the project. All of this discussions started because I was
helping getting samples into trunk for the release and you moved them
out of the trunk to the unreleased folder. Now, if you think I'm not
helping, or that I'm not going to vote to something because I don't
like it, sorry !!!


-- 
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Sun, Apr 3, 2011 at 5:52 AM, Luciano Resende <lu...@gmail.com> wrote:
> On Sat, Apr 2, 2011 at 1:59 PM, ant elder <an...@apache.org> wrote:
>>> I'd add the expectations and/or user experience when running the
>>> samples, as it seems that we are droping support for ant completely
>>> (which to me is ok, as I mostly use maven), but I'm not sure if users
>>> are ok with that.
>>>
>>
>> At least Mike and Simon L have said in this thread they prefer Ant
>> builds to Maven for the samples. Ant is harder because of all the
>> dependencies and where to find the dependencies. There has been things
>> suggested in this thread, and there are the previous attempts, and
>> we've all the manifest jars gen'd for each extension now in the binary
>> distribution, but it all seems a bit complicated and hard to find
>> something that looks very elegant so i decided not to worry about Ant
>> builds for now and focus on Maven (which is hard enough to find
>> something everyone likes on its own), if someone else wants to look at
>> Ant now that would be great by me.
>>
>
> I just want to raise the issue that, in real deployment scenarios,
> users will not use the tuscany/maven plugin. Also, what's the support
> for environments such as OSGi, etc ? That's why I think to demonstrate
> different ways to run the samples, which is aligned with the scenarios
> used by our users in real deployments.
>

I'm still not quite getting what you are saying we should actually do.

If we have a contribution or webapp sample we do have several ways of
running them, one of them is using the tuscany plugin, others are
things like using the scripts to start the Shell, or including the
Jetty or Tomcat plugin to start jetty/Tomcat, one of the
running-tuscany samples to start a Tuscany runtime etc, and we have
samples that show lots of different ways of doing things in the
learning-more and running-tuscany samples,

But, the helloworld contribution samples dont do anything by
themselves without having something within the sample build to run it
in Tuscany, are you saying that you think the Tuscany plugin MUST NOT
be one of these ways? Eg I pointed you at the helloworld-contribution2
sample in unreleased as an example of not including any way to run it
- do you prefer approach? Or do you have some other approach to
suggest?

> Having said that, consistency and simplicity are always welcome.
>
>>> Also, we should clarify what we mean by consistent build, particular
>>> regarding "base + extension", if we are using the base pom, fine, if
>>> we are using the base jar, sorry, but I believe couple of us don't
>>> agree with mandating that. And, reviewing the getting-started sample,
>>> it seems that you are forcing to use the base jar.
>>>
>>
>> Firstly, nothing is being unilaterally mandated or forced to be used.
>> We've been discussing how to do the samples for months now, trying to
>> work out consensuses and compromises and I've been updating the
>> helloworld samples in the unreleased folder as we go and I've asked a
>> bunch of times for feedback and comments on the approach they use and
>> no one ever mentioned or complained about them using the base jar, so
>> thats how they are when moved back into trunk and the samples wiki
>> page was updated based on what they did.
>>
>> I don't really like using the base pom type dependency, unless there
>> are good reasons it seems better to me to provide a single jar for
>> groupings we know are useful than to have pom type dependencies. We've
>> talked about this before, eg one from me is:
>> http://apache.markmail.org/message/qttcn6ngmllptaq2. What don't you
>> like about the base jar?
>>
>
> I don't want to restart the same discussion again, [1] is one of those
> discussions, and as far as I remember, various members of the
> community wanted to go with soft-dependency via pom (thus us creating
> the features a long time ago

The pom type features were created to build distributions not for
users to use as dependency groups, it was just an accidental
misunderstaning that they started getting used like that. You never
answer what it is you don't like about the base jar or address the
points I raise against the the pom type approach in
http://apache.markmail.org/message/qttcn6ngmllptaq2, but surely if
you're arguing that there are many different environments and
approaches to using Tuscany which we should be showing and supporting
in the samples then the base jar is one of the valid ways?

> , and if I remember correctly, Simon L
> creating the base-runtime pom recently), and you were the only one
> forcing the usage of the jar.
>
> [1] http://markmail.org/message/jkkuqmthnspns64q
>
>> So what shall we do about this, how can we find consensus on an approach?
>>
>
> See above, I really thought we had consensus on this case, but you
> keep trying to bring this up again, or we keep finding it when we
> spend tons of time investigating issues.
>


>> We could avoid it for the contribution samples by not including a test
>> that starts tuscany so they just need the sca-api dependency, eg as
>> was done in this sample -
>> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/helloworld-contribution2/
>>
>> We could use the individual module dependencies directly and perhaps
>> have another go at merging some of those together so there's not so
>> many.
>>
>> Perhaps just don't worry about having a consistent approach across the
>> samples and instead people just do what they like?
>>
>
>  I think we need to find the right balance here, although consistency
> is good, if the side effect of this is to not have any sample that
> demonstrates different deployment scenarios, this is also not good.
>

Ok but what exactly are you suggesting we do now?

I would like to do a release to get the latest code out but it sounds
like you wont help or vote for a release with the samples as they are.
What do we need to do so that we can do a release?

    ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Luciano Resende <lu...@gmail.com>]

On Sat, Apr 2, 2011 at 1:59 PM, ant elder <an...@apache.org> wrote:
>> I'd add the expectations and/or user experience when running the
>> samples, as it seems that we are droping support for ant completely
>> (which to me is ok, as I mostly use maven), but I'm not sure if users
>> are ok with that.
>>
>
> At least Mike and Simon L have said in this thread they prefer Ant
> builds to Maven for the samples. Ant is harder because of all the
> dependencies and where to find the dependencies. There has been things
> suggested in this thread, and there are the previous attempts, and
> we've all the manifest jars gen'd for each extension now in the binary
> distribution, but it all seems a bit complicated and hard to find
> something that looks very elegant so i decided not to worry about Ant
> builds for now and focus on Maven (which is hard enough to find
> something everyone likes on its own), if someone else wants to look at
> Ant now that would be great by me.
>

I just want to raise the issue that, in real deployment scenarios,
users will not use the tuscany/maven plugin. Also, what's the support
for environments such as OSGi, etc ? That's why I think to demonstrate
different ways to run the samples, which is aligned with the scenarios
used by our users in real deployments.

Having said that, consistency and simplicity are always welcome.

>> Also, we should clarify what we mean by consistent build, particular
>> regarding "base + extension", if we are using the base pom, fine, if
>> we are using the base jar, sorry, but I believe couple of us don't
>> agree with mandating that. And, reviewing the getting-started sample,
>> it seems that you are forcing to use the base jar.
>>
>
> Firstly, nothing is being unilaterally mandated or forced to be used.
> We've been discussing how to do the samples for months now, trying to
> work out consensuses and compromises and I've been updating the
> helloworld samples in the unreleased folder as we go and I've asked a
> bunch of times for feedback and comments on the approach they use and
> no one ever mentioned or complained about them using the base jar, so
> thats how they are when moved back into trunk and the samples wiki
> page was updated based on what they did.
>
> I don't really like using the base pom type dependency, unless there
> are good reasons it seems better to me to provide a single jar for
> groupings we know are useful than to have pom type dependencies. We've
> talked about this before, eg one from me is:
> http://apache.markmail.org/message/qttcn6ngmllptaq2. What don't you
> like about the base jar?
>

I don't want to restart the same discussion again, [1] is one of those
discussions, and as far as I remember, various members of the
community wanted to go with soft-dependency via pom (thus us creating
the features a long time ago, and if I remember correctly, Simon L
creating the base-runtime pom recently), and you were the only one
forcing the usage of the jar.

[1] http://markmail.org/message/jkkuqmthnspns64q

> So what shall we do about this, how can we find consensus on an approach?
>

See above, I really thought we had consensus on this case, but you
keep trying to bring this up again, or we keep finding it when we
spend tons of time investigating issues.

> We could avoid it for the contribution samples by not including a test
> that starts tuscany so they just need the sca-api dependency, eg as
> was done in this sample -
> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/helloworld-contribution2/
>
> We could use the individual module dependencies directly and perhaps
> have another go at merging some of those together so there's not so
> many.
>
> Perhaps just don't worry about having a consistent approach across the
> samples and instead people just do what they like?
>

 I think we need to find the right balance here, although consistency
is good, if the side effect of this is to not have any sample that
demonstrates different deployment scenarios, this is also not good.

> What else, any suggestions anyone?
>
>   ...ant
>



-- 
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Raymond Feng <en...@gmail.com>]

Hi, Luciano.

Thank you for the clarification. Yes, that's what I meant to say. 

In the real world, we use Tuscany in many different environments, such as command line, Eclipse, JUnit, OSGi, Web applications (application-scoped or servlet scoped). Having the samples to represent some of the typical usages is better than a "fixed" way. As we can see from the discussions, developers find their needs to launch Tuscany in different ways.

Thanks,
Raymond
________________________________________________________________ 
Raymond Feng
rfeng@apache.org
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
________________________________________________________________

On Apr 2, 2011, at 10:12 PM, Luciano Resende wrote:

> On Sat, Apr 2, 2011 at 3:12 PM, ant elder <an...@gmail.com> wrote:
>> On Sat, Apr 2, 2011 at 10:29 PM, Raymond Feng <en...@gmail.com> wrote:
>>> IMO, we shouldn't even try to use one "consistent" way to launch Tuscany in the samples. I don't like the magic plugin approach. The whole idea of Tuscany/SCA is to adapt to whatever technology/container people use instead of reinventing the wheels. Think about Spring, there is no mandatory way to use it.
>>> 
>> 
>> Last time i looked Spring did have a single consistent set of jars to
>> use, and no pom type ones. Surely it will be easier for our users if
>> there are a single set of jars we document that they should use?
>> 
>>   ...ant
>> 
> 
> I believe Raymond's remarks were not related to a single consistent
> set of jars or pom, but that Spring would allow you to launch Spring
> based applications in multiple ways based on ways that users are using
> these apps in real deployments, and that it does not provide a spring
> specific way to run these applications.
> 
> -- 
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Luciano Resende <lu...@gmail.com>]

On Sat, Apr 2, 2011 at 3:12 PM, ant elder <an...@gmail.com> wrote:
> On Sat, Apr 2, 2011 at 10:29 PM, Raymond Feng <en...@gmail.com> wrote:
>> IMO, we shouldn't even try to use one "consistent" way to launch Tuscany in the samples. I don't like the magic plugin approach. The whole idea of Tuscany/SCA is to adapt to whatever technology/container people use instead of reinventing the wheels. Think about Spring, there is no mandatory way to use it.
>>
>
> Last time i looked Spring did have a single consistent set of jars to
> use, and no pom type ones. Surely it will be easier for our users if
> there are a single set of jars we document that they should use?
>
>   ...ant
>

I believe Raymond's remarks were not related to a single consistent
set of jars or pom, but that Spring would allow you to launch Spring
based applications in multiple ways based on ways that users are using
these apps in real deployments, and that it does not provide a spring
specific way to run these applications.

-- 
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@gmail.com>]

On Sat, Apr 2, 2011 at 10:29 PM, Raymond Feng <en...@gmail.com> wrote:
> IMO, we shouldn't even try to use one "consistent" way to launch Tuscany in the samples. I don't like the magic plugin approach. The whole idea of Tuscany/SCA is to adapt to whatever technology/container people use instead of reinventing the wheels. Think about Spring, there is no mandatory way to use it.
>

Last time i looked Spring did have a single consistent set of jars to
use, and no pom type ones. Surely it will be easier for our users if
there are a single set of jars we document that they should use?

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Raymond Feng <en...@gmail.com>]

IMO, we shouldn't even try to use one "consistent" way to launch Tuscany in the samples. I don't like the magic plugin approach. The whole idea of Tuscany/SCA is to adapt to whatever technology/container people use instead of reinventing the wheels. Think about Spring, there is no mandatory way to use it. 

Sent from my iPad

On Apr 2, 2011, at 1:59 PM, ant elder <an...@apache.org> wrote:

> On Fri, Apr 1, 2011 at 5:57 PM, Luciano Resende <lu...@gmail.com> wrote:
>> On Fri, Apr 1, 2011 at 5:32 AM, ant elder <an...@apache.org> wrote:
>>>> 
>>>> Replying to that now quite old email...
>>>> 
>>>> As you asked about this i had a go at adding support to the Tuscany
>>>> plugin to support that and there is now some initial code that seems
>>>> to work. So if you add the pom.xml of a webapp project :
>>>> 
>>>>         <plugin>
>>>>            <groupId>org.apache.tuscany.maven.plugins</groupId>
>>>>            <artifactId>maven-tuscany-plugin</artifactId>
>>>>            <version>${tuscany.version}</version>
>>>>         </plugin>
>>>> 
>>>> then when doing "mvn tuscany:run" it will see that the packaging type
>>>> is war and launch an embeded Tomcat to run the webapp project.
>>>> 
>>>> In a similar vein, i've also added support for having the plugin run a
>>>> classes main method instead of launching Tuscany, so if you have:
>>>> 
>>>>         <plugin>
>>>>            <groupId>org.apache.tuscany.maven.plugins</groupId>
>>>>            <artifactId>maven-tuscany-plugin</artifactId>
>>>>            <version>${tuscany.version}</version>
>>>>            <configuration>
>>>>              <mainClass>sample.HelloworldSCAClient</mainClass>
>>>>            </configuration>
>>>>         </plugin>
>>>> 
>>>> then when doing "mvn tuscany:run" the main method of that class gets called.
>>>> 
>>>> So using those if we add the tuscany plugin definition to the samples
>>>> then you'll be able to run any sample by doing just "mvn tuscany:run"
>>>> instead of having different ways for different samples depending on
>>>> what type of sample it is.
>>>> 
>>>>   ...ant
>>>> 
>>> 
>>> I've updated all the samples in unreleased to demonstrate this, if
>>> we're happy with the approach i'll add it to the samples in trunk.
>>> 
>>> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/getting-started/
>>> 
>>>   ...ant
>>> 
>> 
>> It would be great if we could summarize the requirements we have for
>> the samples on the page Florian created [1].
> 
> There is some stuff there already and i expect we'll add more as we
> work things out. Everyone has access to update the page so ...
> 
>> The information provided
>> above as how to instrument the sample is also very good to be on that
>> page,
> 
> Sure ok i'll add that if we use it, i am waiting to see if there are
> any comments for or against - "if we're happy with the approach i'll
> add it to the samples"
> 
>> I'd add the expectations and/or user experience when running the
>> samples, as it seems that we are droping support for ant completely
>> (which to me is ok, as I mostly use maven), but I'm not sure if users
>> are ok with that.
>> 
> 
> At least Mike and Simon L have said in this thread they prefer Ant
> builds to Maven for the samples. Ant is harder because of all the
> dependencies and where to find the dependencies. There has been things
> suggested in this thread, and there are the previous attempts, and
> we've all the manifest jars gen'd for each extension now in the binary
> distribution, but it all seems a bit complicated and hard to find
> something that looks very elegant so i decided not to worry about Ant
> builds for now and focus on Maven (which is hard enough to find
> something everyone likes on its own), if someone else wants to look at
> Ant now that would be great by me.
> 
>> Also, we should clarify what we mean by consistent build, particular
>> regarding "base + extension", if we are using the base pom, fine, if
>> we are using the base jar, sorry, but I believe couple of us don't
>> agree with mandating that. And, reviewing the getting-started sample,
>> it seems that you are forcing to use the base jar.
>> 
> 
> Firstly, nothing is being unilaterally mandated or forced to be used.
> We've been discussing how to do the samples for months now, trying to
> work out consensuses and compromises and I've been updating the
> helloworld samples in the unreleased folder as we go and I've asked a
> bunch of times for feedback and comments on the approach they use and
> no one ever mentioned or complained about them using the base jar, so
> thats how they are when moved back into trunk and the samples wiki
> page was updated based on what they did.
> 
> I don't really like using the base pom type dependency, unless there
> are good reasons it seems better to me to provide a single jar for
> groupings we know are useful than to have pom type dependencies. We've
> talked about this before, eg one from me is:
> http://apache.markmail.org/message/qttcn6ngmllptaq2. What don't you
> like about the base jar?
> 
> So what shall we do about this, how can we find consensus on an approach?
> 
> We could avoid it for the contribution samples by not including a test
> that starts tuscany so they just need the sca-api dependency, eg as
> was done in this sample -
> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/helloworld-contribution2/
> 
> We could use the individual module dependencies directly and perhaps
> have another go at merging some of those together so there's not so
> many.
> 
> Perhaps just don't worry about having a consistent approach across the
> samples and instead people just do what they like?
> 
> What else, any suggestions anyone?
> 
>   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Fri, Apr 1, 2011 at 5:57 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Fri, Apr 1, 2011 at 5:32 AM, ant elder <an...@apache.org> wrote:
>>>
>>> Replying to that now quite old email...
>>>
>>> As you asked about this i had a go at adding support to the Tuscany
>>> plugin to support that and there is now some initial code that seems
>>> to work. So if you add the pom.xml of a webapp project :
>>>
>>>         <plugin>
>>>            <groupId>org.apache.tuscany.maven.plugins</groupId>
>>>            <artifactId>maven-tuscany-plugin</artifactId>
>>>            <version>${tuscany.version}</version>
>>>         </plugin>
>>>
>>> then when doing "mvn tuscany:run" it will see that the packaging type
>>> is war and launch an embeded Tomcat to run the webapp project.
>>>
>>> In a similar vein, i've also added support for having the plugin run a
>>> classes main method instead of launching Tuscany, so if you have:
>>>
>>>         <plugin>
>>>            <groupId>org.apache.tuscany.maven.plugins</groupId>
>>>            <artifactId>maven-tuscany-plugin</artifactId>
>>>            <version>${tuscany.version}</version>
>>>            <configuration>
>>>              <mainClass>sample.HelloworldSCAClient</mainClass>
>>>            </configuration>
>>>         </plugin>
>>>
>>> then when doing "mvn tuscany:run" the main method of that class gets called.
>>>
>>> So using those if we add the tuscany plugin definition to the samples
>>> then you'll be able to run any sample by doing just "mvn tuscany:run"
>>> instead of having different ways for different samples depending on
>>> what type of sample it is.
>>>
>>>   ...ant
>>>
>>
>> I've updated all the samples in unreleased to demonstrate this, if
>> we're happy with the approach i'll add it to the samples in trunk.
>>
>> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/getting-started/
>>
>>   ...ant
>>
>
> It would be great if we could summarize the requirements we have for
> the samples on the page Florian created [1].

There is some stuff there already and i expect we'll add more as we
work things out. Everyone has access to update the page so ...

> The information provided
> above as how to instrument the sample is also very good to be on that
> page,

Sure ok i'll add that if we use it, i am waiting to see if there are
any comments for or against - "if we're happy with the approach i'll
add it to the samples"

> I'd add the expectations and/or user experience when running the
> samples, as it seems that we are droping support for ant completely
> (which to me is ok, as I mostly use maven), but I'm not sure if users
> are ok with that.
>

At least Mike and Simon L have said in this thread they prefer Ant
builds to Maven for the samples. Ant is harder because of all the
dependencies and where to find the dependencies. There has been things
suggested in this thread, and there are the previous attempts, and
we've all the manifest jars gen'd for each extension now in the binary
distribution, but it all seems a bit complicated and hard to find
something that looks very elegant so i decided not to worry about Ant
builds for now and focus on Maven (which is hard enough to find
something everyone likes on its own), if someone else wants to look at
Ant now that would be great by me.

> Also, we should clarify what we mean by consistent build, particular
> regarding "base + extension", if we are using the base pom, fine, if
> we are using the base jar, sorry, but I believe couple of us don't
> agree with mandating that. And, reviewing the getting-started sample,
> it seems that you are forcing to use the base jar.
>

Firstly, nothing is being unilaterally mandated or forced to be used.
We've been discussing how to do the samples for months now, trying to
work out consensuses and compromises and I've been updating the
helloworld samples in the unreleased folder as we go and I've asked a
bunch of times for feedback and comments on the approach they use and
no one ever mentioned or complained about them using the base jar, so
thats how they are when moved back into trunk and the samples wiki
page was updated based on what they did.

I don't really like using the base pom type dependency, unless there
are good reasons it seems better to me to provide a single jar for
groupings we know are useful than to have pom type dependencies. We've
talked about this before, eg one from me is:
http://apache.markmail.org/message/qttcn6ngmllptaq2. What don't you
like about the base jar?

So what shall we do about this, how can we find consensus on an approach?

We could avoid it for the contribution samples by not including a test
that starts tuscany so they just need the sca-api dependency, eg as
was done in this sample -
https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/helloworld-contribution2/

We could use the individual module dependencies directly and perhaps
have another go at merging some of those together so there's not so
many.

Perhaps just don't worry about having a consistent approach across the
samples and instead people just do what they like?

What else, any suggestions anyone?

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Luciano Resende <lu...@gmail.com>]

On Fri, Apr 1, 2011 at 5:32 AM, ant elder <an...@apache.org> wrote:
>>
>> Replying to that now quite old email...
>>
>> As you asked about this i had a go at adding support to the Tuscany
>> plugin to support that and there is now some initial code that seems
>> to work. So if you add the pom.xml of a webapp project :
>>
>>         <plugin>
>>            <groupId>org.apache.tuscany.maven.plugins</groupId>
>>            <artifactId>maven-tuscany-plugin</artifactId>
>>            <version>${tuscany.version}</version>
>>         </plugin>
>>
>> then when doing "mvn tuscany:run" it will see that the packaging type
>> is war and launch an embeded Tomcat to run the webapp project.
>>
>> In a similar vein, i've also added support for having the plugin run a
>> classes main method instead of launching Tuscany, so if you have:
>>
>>         <plugin>
>>            <groupId>org.apache.tuscany.maven.plugins</groupId>
>>            <artifactId>maven-tuscany-plugin</artifactId>
>>            <version>${tuscany.version}</version>
>>            <configuration>
>>              <mainClass>sample.HelloworldSCAClient</mainClass>
>>            </configuration>
>>         </plugin>
>>
>> then when doing "mvn tuscany:run" the main method of that class gets called.
>>
>> So using those if we add the tuscany plugin definition to the samples
>> then you'll be able to run any sample by doing just "mvn tuscany:run"
>> instead of having different ways for different samples depending on
>> what type of sample it is.
>>
>>   ...ant
>>
>
> I've updated all the samples in unreleased to demonstrate this, if
> we're happy with the approach i'll add it to the samples in trunk.
>
> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/getting-started/
>
>   ...ant
>

It would be great if we could summarize the requirements we have for
the samples on the page Florian created [1]. The information provided
above as how to instrument the sample is also very good to be on that
page, I'd add the expectations and/or user experience when running the
samples, as it seems that we are droping support for ant completely
(which to me is ok, as I mostly use maven), but I'm not sure if users
are ok with that.

Also, we should clarify what we mean by consistent build, particular
regarding "base + extension", if we are using the base pom, fine, if
we are using the base jar, sorry, but I believe couple of us don't
agree with mandating that. And, reviewing the getting-started sample,
it seems that you are forcing to use the base jar.

[1] https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Samples+Requirements

-- 
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Fri, Apr 1, 2011 at 10:00 AM, ant elder <an...@apache.org> wrote:
> On Wed, Feb 9, 2011 at 9:16 AM, ant elder <an...@apache.org> wrote:
>> On Mon, Feb 7, 2011 at 8:57 PM, Florian Moga <mo...@gmail.com> wrote:
>>> How does the shell operate with webapps?
>>
>> Presently it doesn't, for the webapp samples you have to run them in
>> some server, so either deploy them to your appserver or some of them
>> have the Jetty or Tomcat plugin in their pom.xml so you can run them
>> with "mvn jetty:run".
>>
>>   ...ant
>>
>
> Replying to that now quite old email...
>
> As you asked about this i had a go at adding support to the Tuscany
> plugin to support that and there is now some initial code that seems
> to work. So if you add the pom.xml of a webapp project :
>
>         <plugin>
>            <groupId>org.apache.tuscany.maven.plugins</groupId>
>            <artifactId>maven-tuscany-plugin</artifactId>
>            <version>${tuscany.version}</version>
>         </plugin>
>
> then when doing "mvn tuscany:run" it will see that the packaging type
> is war and launch an embeded Tomcat to run the webapp project.
>
> In a similar vein, i've also added support for having the plugin run a
> classes main method instead of launching Tuscany, so if you have:
>
>         <plugin>
>            <groupId>org.apache.tuscany.maven.plugins</groupId>
>            <artifactId>maven-tuscany-plugin</artifactId>
>            <version>${tuscany.version}</version>
>            <configuration>
>              <mainClass>sample.HelloworldSCAClient</mainClass>
>            </configuration>
>         </plugin>
>
> then when doing "mvn tuscany:run" the main method of that class gets called.
>
> So using those if we add the tuscany plugin definition to the samples
> then you'll be able to run any sample by doing just "mvn tuscany:run"
> instead of having different ways for different samples depending on
> what type of sample it is.
>
>   ...ant
>

I've updated all the samples in unreleased to demonstrate this, if
we're happy with the approach i'll add it to the samples in trunk.

https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/getting-started/

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Wed, Feb 9, 2011 at 9:16 AM, ant elder <an...@apache.org> wrote:
> On Mon, Feb 7, 2011 at 8:57 PM, Florian Moga <mo...@gmail.com> wrote:
>> How does the shell operate with webapps?
>
> Presently it doesn't, for the webapp samples you have to run them in
> some server, so either deploy them to your appserver or some of them
> have the Jetty or Tomcat plugin in their pom.xml so you can run them
> with "mvn jetty:run".
>
>   ...ant
>

Replying to that now quite old email...

As you asked about this i had a go at adding support to the Tuscany
plugin to support that and there is now some initial code that seems
to work. So if you add the pom.xml of a webapp project :

         <plugin>
            <groupId>org.apache.tuscany.maven.plugins</groupId>
            <artifactId>maven-tuscany-plugin</artifactId>
            <version>${tuscany.version}</version>
         </plugin>

then when doing "mvn tuscany:run" it will see that the packaging type
is war and launch an embeded Tomcat to run the webapp project.

In a similar vein, i've also added support for having the plugin run a
classes main method instead of launching Tuscany, so if you have:

         <plugin>
            <groupId>org.apache.tuscany.maven.plugins</groupId>
            <artifactId>maven-tuscany-plugin</artifactId>
            <version>${tuscany.version}</version>
            <configuration>
              <mainClass>sample.HelloworldSCAClient</mainClass>
            </configuration>
         </plugin>

then when doing "mvn tuscany:run" the main method of that class gets called.

So using those if we add the tuscany plugin definition to the samples
then you'll be able to run any sample by doing just "mvn tuscany:run"
instead of having different ways for different samples depending on
what type of sample it is.

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Mon, Feb 7, 2011 at 8:57 PM, Florian Moga <mo...@gmail.com> wrote:
> How does the shell operate with webapps?

Presently it doesn't, for the webapp samples you have to run them in
some server, so either deploy them to your appserver or some of them
have the Jetty or Tomcat plugin in their pom.xml so you can run them
with "mvn jetty:run".

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Florian Moga <mo...@gmail.com>]

How does the shell operate with webapps? I've tried loading
helloworld-webapp with mvn tuscany:run and I got a ClassNotFoundException on
a jetty related class. I've added jetty dependencies to the shell module and
now i'm getting:

Feb 7, 2011 8:33:48 PM
org.apache.tuscany.sca.core.runtime.impl.EndpointReferenceBinderImpl []
(ComponentReferenceTargetNotFound)
WARNING: Component reference target not found at deployment time, it might
be a remote service elsewhere in the SCA Domain so well try and resolve it
again at runtime: {1}
2011-02-07 20:33:48.163::INFO:  Logging to STDERR via
org.mortbay.log.StdErrLog

Embedded error: org.apache.tuscany.sca.runtime.ActivationException:
java.lang.UnsupportedOperationException

Could you give me some tips on what to do next?


On Mon, Feb 7, 2011 at 10:43 PM, Florian Moga <mo...@gmail.com> wrote:

> I gave it a try and it found the same problem. It looks like it is not
> expected that the junit jar to be specified amongst dependencies but in the
> $ANT_HOME/lib folder... I've added the build.test.classpath to the
> test-junit-present target and tests are working now.
>
>   <target name="test-junit-present">
>     <available classname="junit.framework.Test" property="junit.present">
> <classpath refid="build.test.classpath"/>
>     </available>
>   </target>
>
> After that, at the package target I'm getting "maven-build.xml:250:
> Attributes must have name and value" and I cannot find what it's all about.
>
>
> On Mon, Feb 7, 2011 at 9:13 PM, ant elder <an...@apache.org> wrote:
>
>> On Sun, Feb 6, 2011 at 12:50 PM, Florian MOGA <mo...@gmail.com> wrote:
>> > I've just checked out "mvn ant:ant" and seems to do a decent job in
>> > generating an ant build file.
>>
>> I didn't know about "mvn ant:ant" that does look good. I haven't quite
>> got it to work properly yet though, if i run "mvn ant:ant" in
>> getting-started/helloworld-contribution it all seems to work but then
>> when running it fails to run the unit tests saying junit isn't
>> available, which is odd as it seems to download junit ok and looks
>> like it is where it says its looking. Does that work for anyone else?
>>
>>   ...ant
>>
>
>

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Nash <na...@apache.org>]

ant elder wrote:
> On Fri, Feb 11, 2011 at 9:24 AM, Simon Nash <na...@apache.org> wrote:
>> ant elder wrote:
>>> On Thu, Feb 10, 2011 at 10:36 AM, Florian Moga <mo...@gmail.com> wrote:
>>>
>>>> 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?
>>>>
>>> I've been thinking the same thing lately, especially now that you
>>> pointed out that we can do "mvn ant:ant" to have Ant scripts
>>> automatically generated. Instead of Ant builds for each sample there
>>> could just be some doc in the top level samples folder or README that
>>> describes how to use "mvn ant:ant".
>>>
>>> The build scripts generated with mvn ant:ant download all the
>>> dependencies from the Maven repositories, that does mean that not much
>>> would be actually using all the jars from the Tuscany binary
>>> distribution so we might want to consider what all thats really for.
>>>
>>>   ...ant
>>>
>>>
>> Actually I would wonder what is the point of using maven to generate
>> an ant script that does exactly the same as the maven build.
>>
>> In 1.x the ant scripts were provided as an alternative to maven that
>> use local artifacts from the binary distro instead of depending on
>> remote repositories.  Another purpose was to make it very clear and
>> explicit what steps are involved "under the covers" to build and run
>> Tuscany applications.  This information is useful to people who want
>> to develop solutions that embed Tuscany.
>>
>>  Simon
>>
>>
> 
> In 1.x at least some of the Ant scripts are/were just generated from
> the maven build but using the Tuscany plugin instead of the Ant plugin
> aren't they, so its not so different?
> 
Many of these are generated, but they use local jars rather than
downloading them from maven repositories, and the Ant scripts are
included in the binary distro so there's no need for users to have
maven to create them.  In some cases only the list of dependencies
is generated as build-dependency.xml, and this is included by a
hand-written build.xml file.

> I think we need to agree what the purpose of them is, what it is that
> they're demonstrating, and then decide if the best way to show that is
> a separate sample(s), or to include both Maven and Ant in every
> sample, I'm wondering if separate might be better.
> 
I think that's a good suggestion.  For a group of samples where the
building/running logistics are similar, we could just provide one
Ant script.  For samples where the logistics are substantially different,
a separate Ant script could be provided.  This reduces the considerable
burden of providing a working tested Ant script for every sample.

> One think is that the 2.x distribution is a bit unusual with the way
> it stores the jars in both top and subdirectories, and there are now
> all the generated manifest jars, and the various aggregated jars. I
> can't imagine anyone would have their own jars in this sort of mix so
> i wonder how useful the hand written Ant builds which use them really
> would be.
> 
>    ...ant
> 
> 
Isn't that quite a problem for the embedded scenario?  Developing an
application that embeds Tuscany isn't particularly easy even with the
simpler 1.x structure.  What would we recommend to someone who wants
to develop a Tuscany application using 2.x that embeds/redistributes
the Tuscany runtime?

   Simon

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Florian Moga <mo...@gmail.com>]

I understand your concerns related to the documentation we ship. In this
case I'm thinking how a README file should look like? First thing that pops
into my mind is that all READMEs should have a consistent feel and probably
include the same topics like:
  - running the sample
  - short presentation of the technologies involved
  - short presentation of the composite
  - more advanced SCA terminology and concepts explained (which are used in
the sample)

Please add other topics which you feel they need to be part of it.

As an alternative, I was thinking about a problem/solution format but I
don't think we can apply that to all our samples...

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Tue, Mar 15, 2011 at 2:22 PM, ant elder <an...@apache.org> wrote:
> On Tue, Mar 15, 2011 at 1:33 PM, Simon Laws <si...@googlemail.com> wrote:
>>>>
>>>> Doesn't that just mean that we need to separate the binary samples
>>>> distribution from the binary runtime distribution that users use to
>>>> run them.
>>>>
>>>
>>> We did talk about having a sample distribution earlier in the thread.
>>> I guess whether or not we do ever release a separate sample
>>> distribution for now we can keep and develop all the samples in a
>>> sample folder in trunk and perhaps add a build to create a sample
>>> distribution under the trunk distribution folder to see what it might
>>> look like.
>>>
>>>   ...ant
>>>
>>
>> Sounds OK to me. Where are we with samples? I've lost track and
>> reading back through this long thread it's difficult to tell if we
>> concluded anything. Are the jars in the binary distro required for
>> running samples for example.
>>
>
> I don't think we've had many clear conclusions yet.
>
> I'm happy with the current helloworld-contribution sample [1], and i
> quite like the possibilities of samples distribution, there's a built
> distribution showing the type of thing that could look like at [2].
>
> Both of those currently only have Maven builds. If Ant builds are
> really needed they could be generated with "mvn ant:ant" which creates
> builds that download dependencies from the maven repo, or they could
> be done some other way, perhaps a separate Ant distribution.
>
> The more we talk about this the less i like the one big all
> distribution that tries to work for everything. It seems to make
> everything really complicated and odd so i'm starting to think its
> better to seperate things out so they can be done in the most
> appropriate way.
>
>   ...ant
>
> [1] https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/helloworld-contribution/
> [2] https://repository.apache.org/content/repositories/snapshots/org/apache/tuscany/sca/distributions/tuscany-samples/2.0-SNAPSHOT/
>

Any comments?

Its been over a month since we tried this experiment of moving all the
samples out of trunk to be fixed up, is this approach working? Would
it help if we set a deadline of say one more week to come up with some
conclusions?

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Tue, Mar 15, 2011 at 1:33 PM, Simon Laws <si...@googlemail.com> wrote:
>>>
>>> Doesn't that just mean that we need to separate the binary samples
>>> distribution from the binary runtime distribution that users use to
>>> run them.
>>>
>>
>> We did talk about having a sample distribution earlier in the thread.
>> I guess whether or not we do ever release a separate sample
>> distribution for now we can keep and develop all the samples in a
>> sample folder in trunk and perhaps add a build to create a sample
>> distribution under the trunk distribution folder to see what it might
>> look like.
>>
>>   ...ant
>>
>
> Sounds OK to me. Where are we with samples? I've lost track and
> reading back through this long thread it's difficult to tell if we
> concluded anything. Are the jars in the binary distro required for
> running samples for example.
>

I don't think we've had many clear conclusions yet.

I'm happy with the current helloworld-contribution sample [1], and i
quite like the possibilities of samples distribution, there's a built
distribution showing the type of thing that could look like at [2].

Both of those currently only have Maven builds. If Ant builds are
really needed they could be generated with "mvn ant:ant" which creates
builds that download dependencies from the maven repo, or they could
be done some other way, perhaps a separate Ant distribution.

The more we talk about this the less i like the one big all
distribution that tries to work for everything. It seems to make
everything really complicated and odd so i'm starting to think its
better to seperate things out so they can be done in the most
appropriate way.

   ...ant

[1] https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/helloworld-contribution/
[2] https://repository.apache.org/content/repositories/snapshots/org/apache/tuscany/sca/distributions/tuscany-samples/2.0-SNAPSHOT/

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Laws <si...@googlemail.com>]

>>
>> Doesn't that just mean that we need to separate the binary samples
>> distribution from the binary runtime distribution that users use to
>> run them.
>>
>
> We did talk about having a sample distribution earlier in the thread.
> I guess whether or not we do ever release a separate sample
> distribution for now we can keep and develop all the samples in a
> sample folder in trunk and perhaps add a build to create a sample
> distribution under the trunk distribution folder to see what it might
> look like.
>
>   ...ant
>

Sounds OK to me. Where are we with samples? I've lost track and
reading back through this long thread it's difficult to tell if we
concluded anything. Are the jars in the binary distro required for
running samples for example.

As an aside I got back to the OSGi issue I mentioned previously and
have some code that generates OBR repository.xml files based on the
contents of which-jars (the list of jar files for a feature) [1]. The
way I've done it at the moment isn't very satisfactory as it involves
firing up an OSGi environment just to get at the repo generation code
from Aries. However it means I can install all the Tuscany jars into
the OBR which can then be used to load bundles on demand. Due to the
wealth of (sometimes unreleased) dependencies I haven't integrated
into the all distribution yet. I'd like to prove to myself that it is
actually going to work properly for us before doing that. But I've got
far enough to allay my concerns about doing selective deployment to
OSGi. It doesn't though tell me much about sample structure or
distributions I'm afraid.

Regards

Simon


[1] http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/distribution/osgi/
-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Thu, Mar 3, 2011 at 4:04 PM, Simon Laws <si...@googlemail.com> wrote:

> On Thu, Mar 3, 2011 at 3:43 PM, ant elder <an...@gmail.com> wrote:
>> On Thu, Mar 3, 2011 at 12:23 PM, Simon Nash <na...@apache.org> wrote:
>>
>>>>>>>>>> I meant to add, if working offline using local artifacts is
>>>>>>>>>> useful/important then i wonder if that should also be possible with
>>>>>>>>>> the Maven builds in the binary distribution. It might be nice if
>>>>>>>>>> both
>>>>>>>>>> the Ant and Maven builds could both work offline using the
>>>>>>>>>> distribution artifacts, which would probably mean having the jars in
>>>>>>>>>> the hierarchical directory structure that maven uses and having the
>>>>>>>>>> Tuscany standalone runtimes work with that. At least that would then
>>>>>>>>>> have the jars in a fairly common and understandable structure.
>>>>>>>>>>
>>>>>>>>>>  ...ant
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> From this I presume you mean having these jars under the Tuscany
>>>>>>>>> installation directory rather than in the user's local maven repo.
>>>>>>>>>
>>>>>>>>> This seems like a good idea as it's first step to creating a more
>>>>>>>>> embeddable Tuscany runtime installation.
>>>>>>>>>
>>>>>>>>>  Simon
>>>>>>>>>
>>>>>>>> Does anyone know how to do that? It sounds like something someone else
>>>>>>>> must have wanted to do before, i guess with the assmbly plugin you
>>>>>>>> must be able to find the local repo and include that in a
>>>>>>>> distribution?
>>>>>>>>
>>>>>>>>  ...ant
>>>>>>>>
>>>>>>>>
>>>>>>> I think the main problem comes when the user wants to use maven to load
>>>>>>> jars from some place on the file system other than the local maven
>>>>>>> repo.
>>>>>>> I spent a bit of time a few months ago looking for a way to do that,
>>>>>>> but I didn't find one.
>>>>>>>
>>>>>>>  Simon
>>>>>>>
>>>>>>>
>>>>>> I've now spent a bit of time trying to do this too without much
>>>>>> success with any automated way. You'd think you should be able to use
>>>>>> the assembly plugin and copy files from somewhere like
>>>>>> ${maven.repo.local} but it doesn't seem to work. Does anyone have any
>>>>>> other ideas ?
>>>>>>
>>>>>>  ...ant
>>>>>>
>>>>> What was the process you were hoping to follow Ant? It sounds like:
>>>>>
>>>>> 1/ build the Tuscany source to popular .m2/respository
>>>>> 2/ create a distribution which packages .m2/resposityr maintaining the
>>>>> same structure
>>>>> 3/ install the distribution with the packages respository intact
>>>>> 4/ run mvn but point it at the repository installed from the distribution
>>>>>
>>>>> is that close?
>>>>>
>>>>
>>>> Yep.
>>>>
>>>> There is also a way using the <repository> element in the assembly
>>>> descriptor
>>>> http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_repository,
>>>> but that doesn't seem to include any plugins.
>>>>
>>>>   ...ant
>>>>
>>>>
>>> A repository that was used to build Tuscany would contain many other things
>>> needed to build Tuscany that aren't part of Tuscany itself.  I presume these
>>> would be removed before we make the distribution.
>>>
>>
>> I think that comes back to the question of why we'd want do this and
>> what the distribution is for?
>>
>> If the intention is that the distribution is self contained so the
>> user can use it without downloading anything else then what does it
>> mean for Maven users? Eg they could use things like clean  install
>> package eclipse:eclipse dependencies:list-dependencies ant:ant and
>> many more, so to work ofline we'd need to include all those plugins.
>> That starts to look a bit unwieldy and defeats the point of that part
>> of Maven,
>>
>> I'm now thinking Maven users are fine with downloading things as
>> required, so really the distribution for them doesn't need any
>> binaries at all, including the Tuscany jars, as they can all be
>> downloaded. If the  Ant build for the samples use the build script
>> created from mvn ant:ant which also downloads the jars dynamically
>> then that distro could work ok for both Maven and Ant users.
>>
>>   ...ant
>>
>
> Doesn't that just mean that we need to separate the binary samples
> distribution from the binary runtime distribution that users use to
> run them.
>

We did talk about having a sample distribution earlier in the thread.
I guess whether or not we do ever release a separate sample
distribution for now we can keep and develop all the samples in a
sample folder in trunk and perhaps add a build to create a sample
distribution under the trunk distribution folder to see what it might
look like.

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Laws <si...@googlemail.com>]

On Thu, Mar 3, 2011 at 3:43 PM, ant elder <an...@gmail.com> wrote:
> On Thu, Mar 3, 2011 at 12:23 PM, Simon Nash <na...@apache.org> wrote:
>
>>>>>>>>> I meant to add, if working offline using local artifacts is
>>>>>>>>> useful/important then i wonder if that should also be possible with
>>>>>>>>> the Maven builds in the binary distribution. It might be nice if
>>>>>>>>> both
>>>>>>>>> the Ant and Maven builds could both work offline using the
>>>>>>>>> distribution artifacts, which would probably mean having the jars in
>>>>>>>>> the hierarchical directory structure that maven uses and having the
>>>>>>>>> Tuscany standalone runtimes work with that. At least that would then
>>>>>>>>> have the jars in a fairly common and understandable structure.
>>>>>>>>>
>>>>>>>>>  ...ant
>>>>>>>>>
>>>>>>>>>
>>>>>>>> From this I presume you mean having these jars under the Tuscany
>>>>>>>> installation directory rather than in the user's local maven repo.
>>>>>>>>
>>>>>>>> This seems like a good idea as it's first step to creating a more
>>>>>>>> embeddable Tuscany runtime installation.
>>>>>>>>
>>>>>>>>  Simon
>>>>>>>>
>>>>>>> Does anyone know how to do that? It sounds like something someone else
>>>>>>> must have wanted to do before, i guess with the assmbly plugin you
>>>>>>> must be able to find the local repo and include that in a
>>>>>>> distribution?
>>>>>>>
>>>>>>>  ...ant
>>>>>>>
>>>>>>>
>>>>>> I think the main problem comes when the user wants to use maven to load
>>>>>> jars from some place on the file system other than the local maven
>>>>>> repo.
>>>>>> I spent a bit of time a few months ago looking for a way to do that,
>>>>>> but I didn't find one.
>>>>>>
>>>>>>  Simon
>>>>>>
>>>>>>
>>>>> I've now spent a bit of time trying to do this too without much
>>>>> success with any automated way. You'd think you should be able to use
>>>>> the assembly plugin and copy files from somewhere like
>>>>> ${maven.repo.local} but it doesn't seem to work. Does anyone have any
>>>>> other ideas ?
>>>>>
>>>>>  ...ant
>>>>>
>>>> What was the process you were hoping to follow Ant? It sounds like:
>>>>
>>>> 1/ build the Tuscany source to popular .m2/respository
>>>> 2/ create a distribution which packages .m2/resposityr maintaining the
>>>> same structure
>>>> 3/ install the distribution with the packages respository intact
>>>> 4/ run mvn but point it at the repository installed from the distribution
>>>>
>>>> is that close?
>>>>
>>>
>>> Yep.
>>>
>>> There is also a way using the <repository> element in the assembly
>>> descriptor
>>> http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_repository,
>>> but that doesn't seem to include any plugins.
>>>
>>>   ...ant
>>>
>>>
>> A repository that was used to build Tuscany would contain many other things
>> needed to build Tuscany that aren't part of Tuscany itself.  I presume these
>> would be removed before we make the distribution.
>>
>
> I think that comes back to the question of why we'd want do this and
> what the distribution is for?
>
> If the intention is that the distribution is self contained so the
> user can use it without downloading anything else then what does it
> mean for Maven users? Eg they could use things like clean  install
> package eclipse:eclipse dependencies:list-dependencies ant:ant and
> many more, so to work ofline we'd need to include all those plugins.
> That starts to look a bit unwieldy and defeats the point of that part
> of Maven,
>
> I'm now thinking Maven users are fine with downloading things as
> required, so really the distribution for them doesn't need any
> binaries at all, including the Tuscany jars, as they can all be
> downloaded. If the  Ant build for the samples use the build script
> created from mvn ant:ant which also downloads the jars dynamically
> then that distro could work ok for both Maven and Ant users.
>
>   ...ant
>

Doesn't that just mean that we need to separate the binary samples
distribution from the binary runtime distribution that users use to
run them.

If they want to use maven to run samples (personally I don't want to
do that but I accept that it is possible) then they just use maven
without also downloading the binary runtime as maven does it for them.
More likely they want to use Maven to compile/package their own
contributions and again maven does all of the downloading for them.

If they want to run samples with other tools, such as ant, eclipse or
within an OSGi environment then we have a choice. We could make the
use of Maven (or the Maven infrastructure) mandatory or we could
provide a separate binary runtime download. This is plausible for ant
(although maybe surprising to the ant user) and Eclipse bu OSGi
concerns me. This concern is because we re-purpose some of our third
party dependencies to work in the OSGi environment. The Maven repos
don't know anything about these doctored jars/bundles. Now I don't
know whether this is still the case that we need these doctored jars
but I do see a lot  of generated bundles still in the binary distro.
So while this seems like a packaging question it's also a strategy
question in as much that it affects our ability to run OSGi.

I'm less keen on the idea of packaging a Maven repo in a distro as
this doesn't fit in with the Maven model very well.

I have been/am spending time looking at how to configure base +
extensions in OSGi as this is one of the loose ends we have with this
approach. This may inform the distribution question also. I don't have
anything useful to report yet though.

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@gmail.com>]

On Thu, Mar 3, 2011 at 12:23 PM, Simon Nash <na...@apache.org> wrote:

>>>>>>>> I meant to add, if working offline using local artifacts is
>>>>>>>> useful/important then i wonder if that should also be possible with
>>>>>>>> the Maven builds in the binary distribution. It might be nice if
>>>>>>>> both
>>>>>>>> the Ant and Maven builds could both work offline using the
>>>>>>>> distribution artifacts, which would probably mean having the jars in
>>>>>>>> the hierarchical directory structure that maven uses and having the
>>>>>>>> Tuscany standalone runtimes work with that. At least that would then
>>>>>>>> have the jars in a fairly common and understandable structure.
>>>>>>>>
>>>>>>>>  ...ant
>>>>>>>>
>>>>>>>>
>>>>>>> From this I presume you mean having these jars under the Tuscany
>>>>>>> installation directory rather than in the user's local maven repo.
>>>>>>>
>>>>>>> This seems like a good idea as it's first step to creating a more
>>>>>>> embeddable Tuscany runtime installation.
>>>>>>>
>>>>>>>  Simon
>>>>>>>
>>>>>> Does anyone know how to do that? It sounds like something someone else
>>>>>> must have wanted to do before, i guess with the assmbly plugin you
>>>>>> must be able to find the local repo and include that in a
>>>>>> distribution?
>>>>>>
>>>>>>  ...ant
>>>>>>
>>>>>>
>>>>> I think the main problem comes when the user wants to use maven to load
>>>>> jars from some place on the file system other than the local maven
>>>>> repo.
>>>>> I spent a bit of time a few months ago looking for a way to do that,
>>>>> but I didn't find one.
>>>>>
>>>>>  Simon
>>>>>
>>>>>
>>>> I've now spent a bit of time trying to do this too without much
>>>> success with any automated way. You'd think you should be able to use
>>>> the assembly plugin and copy files from somewhere like
>>>> ${maven.repo.local} but it doesn't seem to work. Does anyone have any
>>>> other ideas ?
>>>>
>>>>  ...ant
>>>>
>>> What was the process you were hoping to follow Ant? It sounds like:
>>>
>>> 1/ build the Tuscany source to popular .m2/respository
>>> 2/ create a distribution which packages .m2/resposityr maintaining the
>>> same structure
>>> 3/ install the distribution with the packages respository intact
>>> 4/ run mvn but point it at the repository installed from the distribution
>>>
>>> is that close?
>>>
>>
>> Yep.
>>
>> There is also a way using the <repository> element in the assembly
>> descriptor
>> http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_repository,
>> but that doesn't seem to include any plugins.
>>
>>   ...ant
>>
>>
> A repository that was used to build Tuscany would contain many other things
> needed to build Tuscany that aren't part of Tuscany itself.  I presume these
> would be removed before we make the distribution.
>

I think that comes back to the question of why we'd want do this and
what the distribution is for?

If the intention is that the distribution is self contained so the
user can use it without downloading anything else then what does it
mean for Maven users? Eg they could use things like clean  install
package eclipse:eclipse dependencies:list-dependencies ant:ant and
many more, so to work ofline we'd need to include all those plugins.
That starts to look a bit unwieldy and defeats the point of that part
of Maven,

I'm now thinking Maven users are fine with downloading things as
required, so really the distribution for them doesn't need any
binaries at all, including the Tuscany jars, as they can all be
downloaded. If the  Ant build for the samples use the build script
created from mvn ant:ant which also downloads the jars dynamically
then that distro could work ok for both Maven and Ant users.

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Nash <na...@apache.org>]

ant elder wrote:
> On Wed, Mar 2, 2011 at 2:28 PM, Simon Laws <si...@googlemail.com> wrote:
>> On Tue, Mar 1, 2011 at 4:12 PM, ant elder <an...@gmail.com> wrote:
>>> On Wed, Feb 16, 2011 at 10:04 AM, Simon Nash <na...@apache.org> wrote:
>>>> ant elder wrote:
>>>>> On Fri, Feb 11, 2011 at 11:57 AM, Simon Nash <na...@apache.org> wrote:
>>>>>> ant elder wrote:
>>>>>>> On Fri, Feb 11, 2011 at 10:17 AM, ant elder <an...@gmail.com> wrote:
>>>>>>>> On Fri, Feb 11, 2011 at 9:24 AM, Simon Nash <na...@apache.org> wrote:
>>>>>>>>> Actually I would wonder what is the point of using maven to generate
>>>>>>>>> an ant script that does exactly the same as the maven build.
>>>>>>>>>
>>>>>>>>> In 1.x the ant scripts were provided as an alternative to maven that
>>>>>>>>> use local artifacts from the binary distro instead of depending on
>>>>>>>>> remote repositories.
>>>>>>> I meant to add, if working offline using local artifacts is
>>>>>>> useful/important then i wonder if that should also be possible with
>>>>>>> the Maven builds in the binary distribution. It might be nice if both
>>>>>>> the Ant and Maven builds could both work offline using the
>>>>>>> distribution artifacts, which would probably mean having the jars in
>>>>>>> the hierarchical directory structure that maven uses and having the
>>>>>>> Tuscany standalone runtimes work with that. At least that would then
>>>>>>> have the jars in a fairly common and understandable structure.
>>>>>>>
>>>>>>>  ...ant
>>>>>>>
>>>>>>>
>>>>>> From this I presume you mean having these jars under the Tuscany
>>>>>> installation directory rather than in the user's local maven repo.
>>>>>>
>>>>>> This seems like a good idea as it's first step to creating a more
>>>>>> embeddable Tuscany runtime installation.
>>>>>>
>>>>>>  Simon
>>>>>>
>>>>> Does anyone know how to do that? It sounds like something someone else
>>>>> must have wanted to do before, i guess with the assmbly plugin you
>>>>> must be able to find the local repo and include that in a
>>>>> distribution?
>>>>>
>>>>>   ...ant
>>>>>
>>>>>
>>>> I think the main problem comes when the user wants to use maven to load
>>>> jars from some place on the file system other than the local maven repo.
>>>> I spent a bit of time a few months ago looking for a way to do that,
>>>> but I didn't find one.
>>>>
>>>>  Simon
>>>>
>>>>
>>> I've now spent a bit of time trying to do this too without much
>>> success with any automated way. You'd think you should be able to use
>>> the assembly plugin and copy files from somewhere like
>>> ${maven.repo.local} but it doesn't seem to work. Does anyone have any
>>> other ideas ?
>>>
>>>   ...ant
>>>
>> What was the process you were hoping to follow Ant? It sounds like:
>>
>> 1/ build the Tuscany source to popular .m2/respository
>> 2/ create a distribution which packages .m2/resposityr maintaining the
>> same structure
>> 3/ install the distribution with the packages respository intact
>> 4/ run mvn but point it at the repository installed from the distribution
>>
>> is that close?
>>
> 
> Yep.
> 
> There is also a way using the <repository> element in the assembly
> descriptor http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_repository,
> but that doesn't seem to include any plugins.
> 
>    ...ant
> 
> 
A repository that was used to build Tuscany would contain many other things
needed to build Tuscany that aren't part of Tuscany itself.  I presume these
would be removed before we make the distribution.

   Simon

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Wed, Mar 2, 2011 at 2:28 PM, Simon Laws <si...@googlemail.com> wrote:
> On Tue, Mar 1, 2011 at 4:12 PM, ant elder <an...@gmail.com> wrote:
>> On Wed, Feb 16, 2011 at 10:04 AM, Simon Nash <na...@apache.org> wrote:
>>> ant elder wrote:
>>>>
>>>> On Fri, Feb 11, 2011 at 11:57 AM, Simon Nash <na...@apache.org> wrote:
>>>>>
>>>>> ant elder wrote:
>>>>>>
>>>>>> On Fri, Feb 11, 2011 at 10:17 AM, ant elder <an...@gmail.com> wrote:
>>>>>>>
>>>>>>> On Fri, Feb 11, 2011 at 9:24 AM, Simon Nash <na...@apache.org> wrote:
>>>>>>>>
>>>>>>>> Actually I would wonder what is the point of using maven to generate
>>>>>>>> an ant script that does exactly the same as the maven build.
>>>>>>>>
>>>>>>>> In 1.x the ant scripts were provided as an alternative to maven that
>>>>>>>> use local artifacts from the binary distro instead of depending on
>>>>>>>> remote repositories.
>>>>>>
>>>>>> I meant to add, if working offline using local artifacts is
>>>>>> useful/important then i wonder if that should also be possible with
>>>>>> the Maven builds in the binary distribution. It might be nice if both
>>>>>> the Ant and Maven builds could both work offline using the
>>>>>> distribution artifacts, which would probably mean having the jars in
>>>>>> the hierarchical directory structure that maven uses and having the
>>>>>> Tuscany standalone runtimes work with that. At least that would then
>>>>>> have the jars in a fairly common and understandable structure.
>>>>>>
>>>>>>  ...ant
>>>>>>
>>>>>>
>>>>> From this I presume you mean having these jars under the Tuscany
>>>>> installation directory rather than in the user's local maven repo.
>>>>>
>>>>> This seems like a good idea as it's first step to creating a more
>>>>> embeddable Tuscany runtime installation.
>>>>>
>>>>>  Simon
>>>>>
>>>>
>>>> Does anyone know how to do that? It sounds like something someone else
>>>> must have wanted to do before, i guess with the assmbly plugin you
>>>> must be able to find the local repo and include that in a
>>>> distribution?
>>>>
>>>>   ...ant
>>>>
>>>>
>>> I think the main problem comes when the user wants to use maven to load
>>> jars from some place on the file system other than the local maven repo.
>>> I spent a bit of time a few months ago looking for a way to do that,
>>> but I didn't find one.
>>>
>>>  Simon
>>>
>>>
>>
>> I've now spent a bit of time trying to do this too without much
>> success with any automated way. You'd think you should be able to use
>> the assembly plugin and copy files from somewhere like
>> ${maven.repo.local} but it doesn't seem to work. Does anyone have any
>> other ideas ?
>>
>>   ...ant
>>
>
> What was the process you were hoping to follow Ant? It sounds like:
>
> 1/ build the Tuscany source to popular .m2/respository
> 2/ create a distribution which packages .m2/resposityr maintaining the
> same structure
> 3/ install the distribution with the packages respository intact
> 4/ run mvn but point it at the repository installed from the distribution
>
> is that close?
>

Yep.

There is also a way using the <repository> element in the assembly
descriptor http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_repository,
but that doesn't seem to include any plugins.

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Laws <si...@googlemail.com>]

On Tue, Mar 1, 2011 at 4:12 PM, ant elder <an...@gmail.com> wrote:
> On Wed, Feb 16, 2011 at 10:04 AM, Simon Nash <na...@apache.org> wrote:
>> ant elder wrote:
>>>
>>> On Fri, Feb 11, 2011 at 11:57 AM, Simon Nash <na...@apache.org> wrote:
>>>>
>>>> ant elder wrote:
>>>>>
>>>>> On Fri, Feb 11, 2011 at 10:17 AM, ant elder <an...@gmail.com> wrote:
>>>>>>
>>>>>> On Fri, Feb 11, 2011 at 9:24 AM, Simon Nash <na...@apache.org> wrote:
>>>>>>>
>>>>>>> Actually I would wonder what is the point of using maven to generate
>>>>>>> an ant script that does exactly the same as the maven build.
>>>>>>>
>>>>>>> In 1.x the ant scripts were provided as an alternative to maven that
>>>>>>> use local artifacts from the binary distro instead of depending on
>>>>>>> remote repositories.
>>>>>
>>>>> I meant to add, if working offline using local artifacts is
>>>>> useful/important then i wonder if that should also be possible with
>>>>> the Maven builds in the binary distribution. It might be nice if both
>>>>> the Ant and Maven builds could both work offline using the
>>>>> distribution artifacts, which would probably mean having the jars in
>>>>> the hierarchical directory structure that maven uses and having the
>>>>> Tuscany standalone runtimes work with that. At least that would then
>>>>> have the jars in a fairly common and understandable structure.
>>>>>
>>>>>  ...ant
>>>>>
>>>>>
>>>> From this I presume you mean having these jars under the Tuscany
>>>> installation directory rather than in the user's local maven repo.
>>>>
>>>> This seems like a good idea as it's first step to creating a more
>>>> embeddable Tuscany runtime installation.
>>>>
>>>>  Simon
>>>>
>>>
>>> Does anyone know how to do that? It sounds like something someone else
>>> must have wanted to do before, i guess with the assmbly plugin you
>>> must be able to find the local repo and include that in a
>>> distribution?
>>>
>>>   ...ant
>>>
>>>
>> I think the main problem comes when the user wants to use maven to load
>> jars from some place on the file system other than the local maven repo.
>> I spent a bit of time a few months ago looking for a way to do that,
>> but I didn't find one.
>>
>>  Simon
>>
>>
>
> I've now spent a bit of time trying to do this too without much
> success with any automated way. You'd think you should be able to use
> the assembly plugin and copy files from somewhere like
> ${maven.repo.local} but it doesn't seem to work. Does anyone have any
> other ideas ?
>
>   ...ant
>

What was the process you were hoping to follow Ant? It sounds like:

1/ build the Tuscany source to popular .m2/respository
2/ create a distribution which packages .m2/resposityr maintaining the
same structure
3/ install the distribution with the packages respository intact
4/ run mvn but point it at the repository installed from the distribution

is that close?

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@gmail.com>]

On Wed, Feb 16, 2011 at 10:04 AM, Simon Nash <na...@apache.org> wrote:
> ant elder wrote:
>>
>> On Fri, Feb 11, 2011 at 11:57 AM, Simon Nash <na...@apache.org> wrote:
>>>
>>> ant elder wrote:
>>>>
>>>> On Fri, Feb 11, 2011 at 10:17 AM, ant elder <an...@gmail.com> wrote:
>>>>>
>>>>> On Fri, Feb 11, 2011 at 9:24 AM, Simon Nash <na...@apache.org> wrote:
>>>>>>
>>>>>> Actually I would wonder what is the point of using maven to generate
>>>>>> an ant script that does exactly the same as the maven build.
>>>>>>
>>>>>> In 1.x the ant scripts were provided as an alternative to maven that
>>>>>> use local artifacts from the binary distro instead of depending on
>>>>>> remote repositories.
>>>>
>>>> I meant to add, if working offline using local artifacts is
>>>> useful/important then i wonder if that should also be possible with
>>>> the Maven builds in the binary distribution. It might be nice if both
>>>> the Ant and Maven builds could both work offline using the
>>>> distribution artifacts, which would probably mean having the jars in
>>>> the hierarchical directory structure that maven uses and having the
>>>> Tuscany standalone runtimes work with that. At least that would then
>>>> have the jars in a fairly common and understandable structure.
>>>>
>>>>  ...ant
>>>>
>>>>
>>> From this I presume you mean having these jars under the Tuscany
>>> installation directory rather than in the user's local maven repo.
>>>
>>> This seems like a good idea as it's first step to creating a more
>>> embeddable Tuscany runtime installation.
>>>
>>>  Simon
>>>
>>
>> Does anyone know how to do that? It sounds like something someone else
>> must have wanted to do before, i guess with the assmbly plugin you
>> must be able to find the local repo and include that in a
>> distribution?
>>
>>   ...ant
>>
>>
> I think the main problem comes when the user wants to use maven to load
> jars from some place on the file system other than the local maven repo.
> I spent a bit of time a few months ago looking for a way to do that,
> but I didn't find one.
>
>  Simon
>
>

I've now spent a bit of time trying to do this too without much
success with any automated way. You'd think you should be able to use
the assembly plugin and copy files from somewhere like
${maven.repo.local} but it doesn't seem to work. Does anyone have any
other ideas ?

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Nash <na...@apache.org>]

ant elder wrote:
> On Fri, Feb 11, 2011 at 11:57 AM, Simon Nash <na...@apache.org> wrote:
>> ant elder wrote:
>>> On Fri, Feb 11, 2011 at 10:17 AM, ant elder <an...@gmail.com> wrote:
>>>> On Fri, Feb 11, 2011 at 9:24 AM, Simon Nash <na...@apache.org> wrote:
>>>>> Actually I would wonder what is the point of using maven to generate
>>>>> an ant script that does exactly the same as the maven build.
>>>>>
>>>>> In 1.x the ant scripts were provided as an alternative to maven that
>>>>> use local artifacts from the binary distro instead of depending on
>>>>> remote repositories.
>>> I meant to add, if working offline using local artifacts is
>>> useful/important then i wonder if that should also be possible with
>>> the Maven builds in the binary distribution. It might be nice if both
>>> the Ant and Maven builds could both work offline using the
>>> distribution artifacts, which would probably mean having the jars in
>>> the hierarchical directory structure that maven uses and having the
>>> Tuscany standalone runtimes work with that. At least that would then
>>> have the jars in a fairly common and understandable structure.
>>>
>>>   ...ant
>>>
>>>
>> From this I presume you mean having these jars under the Tuscany
>> installation directory rather than in the user's local maven repo.
>>
>> This seems like a good idea as it's first step to creating a more
>> embeddable Tuscany runtime installation.
>>
>>  Simon
>>
> 
> Does anyone know how to do that? It sounds like something someone else
> must have wanted to do before, i guess with the assmbly plugin you
> must be able to find the local repo and include that in a
> distribution?
> 
>    ...ant
> 
> 
I think the main problem comes when the user wants to use maven to load
jars from some place on the file system other than the local maven repo.
I spent a bit of time a few months ago looking for a way to do that,
but I didn't find one.

   Simon

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@gmail.com>]

On Fri, Feb 11, 2011 at 11:57 AM, Simon Nash <na...@apache.org> wrote:
> ant elder wrote:
>>
>> On Fri, Feb 11, 2011 at 10:17 AM, ant elder <an...@gmail.com> wrote:
>>>
>>> On Fri, Feb 11, 2011 at 9:24 AM, Simon Nash <na...@apache.org> wrote:
>>
>>>> Actually I would wonder what is the point of using maven to generate
>>>> an ant script that does exactly the same as the maven build.
>>>>
>>>> In 1.x the ant scripts were provided as an alternative to maven that
>>>> use local artifacts from the binary distro instead of depending on
>>>> remote repositories.
>>
>> I meant to add, if working offline using local artifacts is
>> useful/important then i wonder if that should also be possible with
>> the Maven builds in the binary distribution. It might be nice if both
>> the Ant and Maven builds could both work offline using the
>> distribution artifacts, which would probably mean having the jars in
>> the hierarchical directory structure that maven uses and having the
>> Tuscany standalone runtimes work with that. At least that would then
>> have the jars in a fairly common and understandable structure.
>>
>>   ...ant
>>
>>
> From this I presume you mean having these jars under the Tuscany
> installation directory rather than in the user's local maven repo.
>
> This seems like a good idea as it's first step to creating a more
> embeddable Tuscany runtime installation.
>
>  Simon
>

Does anyone know how to do that? It sounds like something someone else
must have wanted to do before, i guess with the assmbly plugin you
must be able to find the local repo and include that in a
distribution?

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Nash <na...@apache.org>]

ant elder wrote:
> On Fri, Feb 11, 2011 at 10:17 AM, ant elder <an...@gmail.com> wrote:
>> On Fri, Feb 11, 2011 at 9:24 AM, Simon Nash <na...@apache.org> wrote:
> 
>>> Actually I would wonder what is the point of using maven to generate
>>> an ant script that does exactly the same as the maven build.
>>>
>>> In 1.x the ant scripts were provided as an alternative to maven that
>>> use local artifacts from the binary distro instead of depending on
>>> remote repositories.
> 
> I meant to add, if working offline using local artifacts is
> useful/important then i wonder if that should also be possible with
> the Maven builds in the binary distribution. It might be nice if both
> the Ant and Maven builds could both work offline using the
> distribution artifacts, which would probably mean having the jars in
> the hierarchical directory structure that maven uses and having the
> Tuscany standalone runtimes work with that. At least that would then
> have the jars in a fairly common and understandable structure.
> 
>    ...ant
> 
> 
 From this I presume you mean having these jars under the Tuscany
installation directory rather than in the user's local maven repo.

This seems like a good idea as it's first step to creating a more
embeddable Tuscany runtime installation.

   Simon

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@gmail.com>]

On Fri, Feb 11, 2011 at 10:17 AM, ant elder <an...@gmail.com> wrote:
> On Fri, Feb 11, 2011 at 9:24 AM, Simon Nash <na...@apache.org> wrote:

>> Actually I would wonder what is the point of using maven to generate
>> an ant script that does exactly the same as the maven build.
>>
>> In 1.x the ant scripts were provided as an alternative to maven that
>> use local artifacts from the binary distro instead of depending on
>> remote repositories.

I meant to add, if working offline using local artifacts is
useful/important then i wonder if that should also be possible with
the Maven builds in the binary distribution. It might be nice if both
the Ant and Maven builds could both work offline using the
distribution artifacts, which would probably mean having the jars in
the hierarchical directory structure that maven uses and having the
Tuscany standalone runtimes work with that. At least that would then
have the jars in a fairly common and understandable structure.

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@gmail.com>]

On Fri, Feb 11, 2011 at 9:24 AM, Simon Nash <na...@apache.org> wrote:
> ant elder wrote:
>>
>> On Thu, Feb 10, 2011 at 10:36 AM, Florian Moga <mo...@gmail.com> wrote:
>>
>>> 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?
>>>
>>
>> I've been thinking the same thing lately, especially now that you
>> pointed out that we can do "mvn ant:ant" to have Ant scripts
>> automatically generated. Instead of Ant builds for each sample there
>> could just be some doc in the top level samples folder or README that
>> describes how to use "mvn ant:ant".
>>
>> The build scripts generated with mvn ant:ant download all the
>> dependencies from the Maven repositories, that does mean that not much
>> would be actually using all the jars from the Tuscany binary
>> distribution so we might want to consider what all thats really for.
>>
>>   ...ant
>>
>>
> Actually I would wonder what is the point of using maven to generate
> an ant script that does exactly the same as the maven build.
>
> In 1.x the ant scripts were provided as an alternative to maven that
> use local artifacts from the binary distro instead of depending on
> remote repositories.  Another purpose was to make it very clear and
> explicit what steps are involved "under the covers" to build and run
> Tuscany applications.  This information is useful to people who want
> to develop solutions that embed Tuscany.
>
>  Simon
>
>

In 1.x at least some of the Ant scripts are/were just generated from
the maven build but using the Tuscany plugin instead of the Ant plugin
aren't they, so its not so different?

I think we need to agree what the purpose of them is, what it is that
they're demonstrating, and then decide if the best way to show that is
a separate sample(s), or to include both Maven and Ant in every
sample, I'm wondering if separate might be better.

One think is that the 2.x distribution is a bit unusual with the way
it stores the jars in both top and subdirectories, and there are now
all the generated manifest jars, and the various aggregated jars. I
can't imagine anyone would have their own jars in this sort of mix so
i wonder how useful the hand written Ant builds which use them really
would be.

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Nash <na...@apache.org>]

ant elder wrote:
> On Thu, Feb 10, 2011 at 10:36 AM, Florian Moga <mo...@gmail.com> wrote:
> 
>> 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?
>>
> 
> I've been thinking the same thing lately, especially now that you
> pointed out that we can do "mvn ant:ant" to have Ant scripts
> automatically generated. Instead of Ant builds for each sample there
> could just be some doc in the top level samples folder or README that
> describes how to use "mvn ant:ant".
> 
> The build scripts generated with mvn ant:ant download all the
> dependencies from the Maven repositories, that does mean that not much
> would be actually using all the jars from the Tuscany binary
> distribution so we might want to consider what all thats really for.
> 
>    ...ant
> 
> 
Actually I would wonder what is the point of using maven to generate
an ant script that does exactly the same as the maven build.

In 1.x the ant scripts were provided as an alternative to maven that
use local artifacts from the binary distro instead of depending on
remote repositories.  Another purpose was to make it very clear and
explicit what steps are involved "under the covers" to build and run
Tuscany applications.  This information is useful to people who want
to develop solutions that embed Tuscany.

   Simon

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@gmail.com>]

On Thu, Feb 24, 2011 at 3:58 PM, Simon Nash <na...@apache.org> wrote:
> Florian Moga wrote:
>>
>> I was thinking that if we use blogging as the primary way of describing
>> samples, it's not even necessary to include a README in each and every
>> sample, people can just search the blog knowing that information will be
>> there (I'm trying to keep things as simple and interactive as possible -- to
>> be honest, in most of the cases, I for one, am not checking the README files
>> not even when I was first starting to look at Tuscany. They are hard to
>> maintain and get out-dated quite easily).
>> One other advantage of blogging would be that comments containing
>> questions and issues to which we'll respond will remain visible for
>> everybody who's checking them out. When a user asks for clarification about
>> a sample, I'm pretty sure we currently don't update the README to cover
>> that. I'm just saying that it might help us be more open to our users, their
>> needs, receive feedback from them and simplify maintainability (a blog post
>> can always be edited or deleted and rewritten if major changes are done).
>>
>> IMO, this will improve the promotion of Tuscany especially with 2.0
>> approaching and help keep a better contact with users. Imagine that you're
>> doing a nifty improvement on a module and update the sample. Nobody is
>> checking the READMEs, a blog post is out there notifying people.
>>
>> I agree the distribution should have some kind of documentation on
>> samples, I'm thinking that there should be a way of exporting the blog posts
>> to a pdf format with a nice template which we can place in the samples/
>> directory right before doing a release (this way we don't end up with out
>> dated information).
>>
>> There are a number of open source projects which have dedicated websites
>> for samples, most of which I've seen are web frameworks (e.g Apache Wicket).
>> It's not our case but I think we can do something similar and gain the
>> benefits.
>>
> I think it's important that samples include intructions for running them.
> If we can also blog about new samples before we release them, that's
> good too.
>
> The purpose of samples is to make it easy for new users to understand
> how to use Tuscany by running the sample.  If the instructions aren't
> included with the sample, the user has to find the instructions and
> make sure that they have the right version of instructions for this
> version of the sample.  This adds an additional step to what a new user
> needs to do.
>
> Also, as samples move through multiple releases, having instructions
> in a separate place from the sample increases the chance of a user
> accidentally getting the wrong version of the instructions.
>
>  Simon
>
>>
>> On Thu, Feb 24, 2011 at 1:53 PM, Simon Laws <simonslaws@googlemail.com
>> <ma...@googlemail.com>> wrote:
>>
>>    On Wed, Feb 23, 2011 at 1:14 PM, Florian Moga <moga.flo@gmail.com
>>    <ma...@gmail.com>> wrote:
>>     > Yes, I was thinking that in this case READMEs would only contain
>> some
>>     > instructions on how to start the shell so it will basically be
>>    the same
>>     > README copied in each and every folder.
>>     >
>>     > On Wed, Feb 23, 2011 at 3:02 PM, ant elder <antelder@apache.org
>>    <ma...@apache.org>> wrote:
>>     >>
>>     >> On Wed, Feb 23, 2011 at 9:20 AM, Florian Moga
>>    <moga.flo@gmail.com <ma...@gmail.com>> wrote:
>>     >> > As for doc, what do you think about the following idea? As
>>    soon as a
>>     >> > sample
>>     >> > graduates from contrib/ we can write a blog post explaining
>>    various
>>     >> > things
>>     >> > about it. It's much more interactive for both users and us.
>>    Also, the
>>     >> > blog
>>     >> > will probably get more attention and would be more complete.
>>    In this
>>     >> > case, a
>>     >> > top level README explaning how to start a sample and interact
>>    with it
>>     >> > using
>>     >> > the shell would be enough IMO.
>>     >> >
>>     >>
>>     >> Is that suggestion to just have the blog posts and only a single
>> top
>>     >> level sample README? Blog posts seem like a fine idea but i do
>> think
>>     >> its good to have some sort of doc within each sample folder as
>>    its so
>>     >> obvious there when a new user first looks at a sample.
>>     >>
>>     >>   ...ant
>>     >
>>     >
>>
>>    I think it's useful to have descriptive text distributed with the
>>    samples otherwise it can be difficult to work out what the intended
>>    function is. I've nothing against blogging about the samples but if we
>>    commit to this a primary mechanism for detailed description then we
>>    have the same problem we have with the web site in that people have to
>>    follow a link to get to the details.
>>
>>    Simon

I think i also like having a readme within each sample that gives at
least some minimal description of what the sample does and how to run
it, but that doesn't mean we couldn't also blog about it or have doc
on the website or something else too.

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Nash <na...@apache.org>]

Florian Moga wrote:
> I was thinking that if we use blogging as the primary way of describing 
> samples, it's not even necessary to include a README in each and every 
> sample, people can just search the blog knowing that information will be 
> there (I'm trying to keep things as simple and interactive as possible 
> -- to be honest, in most of the cases, I for one, am not checking the 
> README files not even when I was first starting to look at Tuscany. They 
> are hard to maintain and get out-dated quite easily). 
> 
> One other advantage of blogging would be that comments containing 
> questions and issues to which we'll respond will remain visible for 
> everybody who's checking them out. When a user asks for clarification 
> about a sample, I'm pretty sure we currently don't update the README to 
> cover that. I'm just saying that it might help us be more open to our 
> users, their needs, receive feedback from them and simplify 
> maintainability (a blog post can always be edited or deleted and 
> rewritten if major changes are done).
> 
> IMO, this will improve the promotion of Tuscany especially with 2.0 
> approaching and help keep a better contact with users. Imagine that 
> you're doing a nifty improvement on a module and update the sample. 
> Nobody is checking the READMEs, a blog post is out there notifying people.
> 
> I agree the distribution should have some kind of documentation on 
> samples, I'm thinking that there should be a way of exporting the blog 
> posts to a pdf format with a nice template which we can place in the 
> samples/ directory right before doing a release (this way we don't end 
> up with out dated information).
> 
> There are a number of open source projects which have dedicated websites 
> for samples, most of which I've seen are web frameworks (e.g Apache 
> Wicket). It's not our case but I think we can do something similar and 
> gain the benefits.
> 
I think it's important that samples include intructions for running them.
If we can also blog about new samples before we release them, that's
good too.

The purpose of samples is to make it easy for new users to understand
how to use Tuscany by running the sample.  If the instructions aren't
included with the sample, the user has to find the instructions and
make sure that they have the right version of instructions for this
version of the sample.  This adds an additional step to what a new user
needs to do.

Also, as samples move through multiple releases, having instructions
in a separate place from the sample increases the chance of a user
accidentally getting the wrong version of the instructions.

   Simon

> 
> On Thu, Feb 24, 2011 at 1:53 PM, Simon Laws <simonslaws@googlemail.com 
> <ma...@googlemail.com>> wrote:
> 
>     On Wed, Feb 23, 2011 at 1:14 PM, Florian Moga <moga.flo@gmail.com
>     <ma...@gmail.com>> wrote:
>      > Yes, I was thinking that in this case READMEs would only contain some
>      > instructions on how to start the shell so it will basically be
>     the same
>      > README copied in each and every folder.
>      >
>      > On Wed, Feb 23, 2011 at 3:02 PM, ant elder <antelder@apache.org
>     <ma...@apache.org>> wrote:
>      >>
>      >> On Wed, Feb 23, 2011 at 9:20 AM, Florian Moga
>     <moga.flo@gmail.com <ma...@gmail.com>> wrote:
>      >> > As for doc, what do you think about the following idea? As
>     soon as a
>      >> > sample
>      >> > graduates from contrib/ we can write a blog post explaining
>     various
>      >> > things
>      >> > about it. It's much more interactive for both users and us.
>     Also, the
>      >> > blog
>      >> > will probably get more attention and would be more complete.
>     In this
>      >> > case, a
>      >> > top level README explaning how to start a sample and interact
>     with it
>      >> > using
>      >> > the shell would be enough IMO.
>      >> >
>      >>
>      >> Is that suggestion to just have the blog posts and only a single top
>      >> level sample README? Blog posts seem like a fine idea but i do think
>      >> its good to have some sort of doc within each sample folder as
>     its so
>      >> obvious there when a new user first looks at a sample.
>      >>
>      >>   ...ant
>      >
>      >
> 
>     I think it's useful to have descriptive text distributed with the
>     samples otherwise it can be difficult to work out what the intended
>     function is. I've nothing against blogging about the samples but if we
>     commit to this a primary mechanism for detailed description then we
>     have the same problem we have with the web site in that people have to
>     follow a link to get to the details.
> 
>     Simon
> 
>     --
>     Apache Tuscany committer: tuscany.apache.org <http://tuscany.apache.org>
>     Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>     <http://tuscanyinaction.com>
> 
> 

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Tue, Feb 15, 2011 at 7:08 PM, ant elder <an...@apache.org> wrote:
> On Thu, Feb 10, 2011 at 9:10 AM, ant elder <an...@apache.org> wrote:
>
>>
>> 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.
>>
>
> So how do we progress this? What do we need to change in the
> helloworld sample at
> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/helloworld-contribution/
> to make in complete and move it back to trunk/samples?
>
>   ...ant
>

And while we think about that helloworld sample, how shall we do
samples for other bindings?

Previously we've had helloworld or calculator type contributions for
every binding type which duplicate the entire helloworld or calculator
contribution, do we really need to do that? All the Tuscany APIs and
Shell support starting a composite xml file that is external to a
contribution, so could we use that to add other bindings without
duplicating the contribution? For example, i've added a
binding.ws.composite at [1] that you can use with the helloworld
contribution to expose the helloworld service as a Web Service
endpoint.

That seems simpler to me than duplicating the helloworld sample, but
what does everyone else think?

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Mike Edwards <mi...@gmail.com>]

On 24/02/2011 14:28, Florian Moga wrote:
> I was thinking that if we use blogging as the primary way of describing samples, it's not even
> necessary to include a README in each and every sample, people can just search the blog knowing that
> information will be there (I'm trying to keep things as simple and interactive as possible -- to be
> honest, in most of the cases, I for one, am not checking the README files not even when I was first
> starting to look at Tuscany. They are hard to maintain and get out-dated quite easily).
>
> One other advantage of blogging would be that comments containing questions and issues to which
> we'll respond will remain visible for everybody who's checking them out. When a user asks for
> clarification about a sample, I'm pretty sure we currently don't update the README to cover that.
> I'm just saying that it might help us be more open to our users, their needs, receive feedback from
> them and simplify maintainability (a blog post can always be edited or deleted and rewritten if
> major changes are done).
>
> IMO, this will improve the promotion of Tuscany especially with 2.0 approaching and help keep a
> better contact with users. Imagine that you're doing a nifty improvement on a module and update the
> sample. Nobody is checking the READMEs, a blog post is out there notifying people.
>
> I agree the distribution should have some kind of documentation on samples, I'm thinking that there
> should be a way of exporting the blog posts to a pdf format with a nice template which we can place
> in the samples/ directory right before doing a release (this way we don't end up with out dated
> information).
>
> There are a number of open source projects which have dedicated websites for samples, most of which
> I've seen are web frameworks (e.g Apache Wicket). It's not our case but I think we can do something
> similar and gain the benefits.
>
Florian,

I'm not against blogging, but there must be a description of how to run each sample contained in the 
distribution along with each sample.  There is nothing worse for a newbie than getting a 
distribution with samples only to find that there is nothing telling them how to run the samples to 
see what it takes to run an application with that runtime.

In my opinion, there should be readme material in the samples directories - that material can point 
to blogs, but it should be possible to use the samples without ever seeing the blogs.


Yours,  Mike.

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Laws <si...@googlemail.com>]

On Tue, Mar 1, 2011 at 9:09 AM, ant elder <an...@apache.org> wrote:
> On Mon, Feb 28, 2011 at 4:26 PM, Simon Laws <si...@googlemail.com> wrote:
>> On Mon, Feb 28, 2011 at 3:24 PM, ant elder <an...@gmail.com> wrote:
>>> FWIW i've now added an Ant build.xml to the helloworld sample at:
>>>
>>> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/helloworld-contribution/.
>>>
>>> That build does not use jars from a  binary distribution but instead
>>> the build script downloads the necessary jars itself.
>>
>> Do we really want to further ignore the jars we ship in the binary
>> distro or are you thinking of a different distro?
>>
>>>
>>> Note that earlier in this now very long thread there was some
>>> agreement to _not_ include Ant builds in each sample but to perhaps
>>> have separate sample(s) dedicated to how to use Tuscany with Ant.
>>
>> Right, we could do with running-tuscany/ant
>>
>
> From whats been said in this thread and elsewhere some people would
> still want an Ant build within each sample to build the actual
> contribution. I think what you're suggesting is to split the building
> the contribution and running it in Tuscany into two separate build
> steps which are run from separate places, but going back to the review
> comments in 2.0-Beta1 that approach wasn't found totally helpful. It
> also means that there isn't a way to run samples without having a
> binary distribution which is also something that has been asked for.
>
> It is getting hard to think of something that will meet everyones
> wishes with all the divergent views. I still quite like the helloworld
> sample thats in unreleased. Maybe what we need to do is create some
> more samples for different approaches and then see what sort of
> distribution or distributions we would need to release them. Or does
> anyone have any other suggestions on what to do?
>
>   ...ant
>

I agree that there seem to be some conflicting requirements. I need to
read back through the various threads again. The other thing I'd like
to do is understand better the question you've quite rightly posed
about what the binary distribution is for. In particular I'd like to
understand how to fix some of the loose ends that were left last time
around. For example, is there an alternative to the "load everything
in the modules directory" approach we have for using Tuscany in an
OSGi environment.

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Mon, Feb 28, 2011 at 4:26 PM, Simon Laws <si...@googlemail.com> wrote:
> On Mon, Feb 28, 2011 at 3:24 PM, ant elder <an...@gmail.com> wrote:
>> FWIW i've now added an Ant build.xml to the helloworld sample at:
>>
>> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/helloworld-contribution/.
>>
>> That build does not use jars from a  binary distribution but instead
>> the build script downloads the necessary jars itself.
>
> Do we really want to further ignore the jars we ship in the binary
> distro or are you thinking of a different distro?
>
>>
>> Note that earlier in this now very long thread there was some
>> agreement to _not_ include Ant builds in each sample but to perhaps
>> have separate sample(s) dedicated to how to use Tuscany with Ant.
>
> Right, we could do with running-tuscany/ant
>

>From whats been said in this thread and elsewhere some people would
still want an Ant build within each sample to build the actual
contribution. I think what you're suggesting is to split the building
the contribution and running it in Tuscany into two separate build
steps which are run from separate places, but going back to the review
comments in 2.0-Beta1 that approach wasn't found totally helpful. It
also means that there isn't a way to run samples without having a
binary distribution which is also something that has been asked for.

It is getting hard to think of something that will meet everyones
wishes with all the divergent views. I still quite like the helloworld
sample thats in unreleased. Maybe what we need to do is create some
more samples for different approaches and then see what sort of
distribution or distributions we would need to release them. Or does
anyone have any other suggestions on what to do?

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Laws <si...@googlemail.com>]

On Mon, Feb 28, 2011 at 3:24 PM, ant elder <an...@gmail.com> wrote:
> FWIW i've now added an Ant build.xml to the helloworld sample at:
>
> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/helloworld-contribution/.
>
> That build does not use jars from a  binary distribution but instead
> the build script downloads the necessary jars itself.

Do we really want to further ignore the jars we ship in the binary
distro or are you thinking of a different distro?

>
> Note that earlier in this now very long thread there was some
> agreement to _not_ include Ant builds in each sample but to perhaps
> have separate sample(s) dedicated to how to use Tuscany with Ant.

Right, we could do with running-tuscany/ant

>
>   ...ant
>

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@gmail.com>]

FWIW i've now added an Ant build.xml to the helloworld sample at:

https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/helloworld-contribution/.

That build does not use jars from a  binary distribution but instead
the build script downloads the necessary jars itself.

Note that earlier in this now very long thread there was some
agreement to _not_ include Ant builds in each sample but to perhaps
have separate sample(s) dedicated to how to use Tuscany with Ant.

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Mike Edwards <mi...@gmail.com>]

On 28/02/2011 09:58, ant elder wrote:
<snip>
>
> It might be worth looking at what the binary distribution is actually
> for though, perhaps not in this thread so it doesn't bog down the
> sample discussion. The binary distribution isn't used by any of the
> Maven builds of the samples or running them.
>
>     ...ant
>
Folks,

For me that IS one of the problems - ie having to use Maven to run a sample.

In my opinion, the binary distribution should be available for those folks who want to use Tuscany - 
and the samples should show them a way to do this without requiring them to use Maven, which is a 
build tool that not everyone is used to using.


Yours,  Mike.

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Mon, Feb 28, 2011 at 9:39 AM, Simon Laws <si...@googlemail.com> wrote:
> On Mon, Feb 28, 2011 at 8:07 AM, ant elder <an...@apache.org> wrote:
>> On Mon, Feb 21, 2011 at 10:52 AM, Simon Laws <si...@googlemail.com> wrote:
>>
>>>
>>> I wonder whether we need the ability to run from maven at all. We need
>>> a way for people to compile samples of course. I've be happy with the
>>> following.
>>>
>>> 1 - use the shell as the primary out of the box mechanism for
>>> loading/running sample contributions where possible
>>> 2 - present all the other options for running/embedding Tuscany under
>>> "running tuscany" which is after all why we created that  directory in
>>> the first place, i.e. to separate sample contributions from the large
>>> number of ways we have of running them
>>> 3 - make using the sample contributions in eclipse really easy
>>> (re-instate the eclipse plugin? provide instructions for generating
>>> projects files? Or even ship project files?)
>>>
>>
>> I can understand the motivation for doing that but we did try it a bit
>> before and I got the feeling people didn't really like it. Eg needing
>> to have a prebuilt binary distribution can be a bit painful.
>>
>>   ...ant
>>
>
> Are you suggesting that we don't ship a binary distribution now and go
> with just a source distribution?
>
> Simon
>

No I wasn't suggesting that, just trying to find some way to make some
progress on the samples.

It might be worth looking at what the binary distribution is actually
for though, perhaps not in this thread so it doesn't bog down the
sample discussion. The binary distribution isn't used by any of the
Maven builds of the samples or running them.

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Laws <si...@googlemail.com>]

On Mon, Feb 28, 2011 at 8:07 AM, ant elder <an...@apache.org> wrote:
> On Mon, Feb 21, 2011 at 10:52 AM, Simon Laws <si...@googlemail.com> wrote:
>
>>
>> I wonder whether we need the ability to run from maven at all. We need
>> a way for people to compile samples of course. I've be happy with the
>> following.
>>
>> 1 - use the shell as the primary out of the box mechanism for
>> loading/running sample contributions where possible
>> 2 - present all the other options for running/embedding Tuscany under
>> "running tuscany" which is after all why we created that  directory in
>> the first place, i.e. to separate sample contributions from the large
>> number of ways we have of running them
>> 3 - make using the sample contributions in eclipse really easy
>> (re-instate the eclipse plugin? provide instructions for generating
>> projects files? Or even ship project files?)
>>
>
> I can understand the motivation for doing that but we did try it a bit
> before and I got the feeling people didn't really like it. Eg needing
> to have a prebuilt binary distribution can be a bit painful.
>
>   ...ant
>

Are you suggesting that we don't ship a binary distribution now and go
with just a source distribution?

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Mon, Feb 21, 2011 at 10:52 AM, Simon Laws <si...@googlemail.com> wrote:

>
> I wonder whether we need the ability to run from maven at all. We need
> a way for people to compile samples of course. I've be happy with the
> following.
>
> 1 - use the shell as the primary out of the box mechanism for
> loading/running sample contributions where possible
> 2 - present all the other options for running/embedding Tuscany under
> "running tuscany" which is after all why we created that  directory in
> the first place, i.e. to separate sample contributions from the large
> number of ways we have of running them
> 3 - make using the sample contributions in eclipse really easy
> (re-instate the eclipse plugin? provide instructions for generating
> projects files? Or even ship project files?)
>

I can understand the motivation for doing that but we did try it a bit
before and I got the feeling people didn't really like it. Eg needing
to have a prebuilt binary distribution can be a bit painful.

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Florian Moga <mo...@gmail.com>]

I was thinking that if we use blogging as the primary way of describing
samples, it's not even necessary to include a README in each and every
sample, people can just search the blog knowing that information will be
there (I'm trying to keep things as simple and interactive as possible -- to
be honest, in most of the cases, I for one, am not checking the README files
not even when I was first starting to look at Tuscany. They are hard to
maintain and get out-dated quite easily).

One other advantage of blogging would be that comments containing questions
and issues to which we'll respond will remain visible for everybody who's
checking them out. When a user asks for clarification about a sample, I'm
pretty sure we currently don't update the README to cover that. I'm just
saying that it might help us be more open to our users, their needs, receive
feedback from them and simplify maintainability (a blog post can always be
edited or deleted and rewritten if major changes are done).

IMO, this will improve the promotion of Tuscany especially with 2.0
approaching and help keep a better contact with users. Imagine that you're
doing a nifty improvement on a module and update the sample. Nobody is
checking the READMEs, a blog post is out there notifying people.

I agree the distribution should have some kind of documentation on samples,
I'm thinking that there should be a way of exporting the blog posts to a pdf
format with a nice template which we can place in the samples/ directory
right before doing a release (this way we don't end up with out dated
information).

There are a number of open source projects which have dedicated websites for
samples, most of which I've seen are web frameworks (e.g Apache Wicket).
It's not our case but I think we can do something similar and gain the
benefits.


On Thu, Feb 24, 2011 at 1:53 PM, Simon Laws <si...@googlemail.com>wrote:

> On Wed, Feb 23, 2011 at 1:14 PM, Florian Moga <mo...@gmail.com> wrote:
> > Yes, I was thinking that in this case READMEs would only contain some
> > instructions on how to start the shell so it will basically be the same
> > README copied in each and every folder.
> >
> > On Wed, Feb 23, 2011 at 3:02 PM, ant elder <an...@apache.org> wrote:
> >>
> >> On Wed, Feb 23, 2011 at 9:20 AM, Florian Moga <mo...@gmail.com>
> wrote:
> >> > As for doc, what do you think about the following idea? As soon as a
> >> > sample
> >> > graduates from contrib/ we can write a blog post explaining various
> >> > things
> >> > about it. It's much more interactive for both users and us. Also, the
> >> > blog
> >> > will probably get more attention and would be more complete. In this
> >> > case, a
> >> > top level README explaning how to start a sample and interact with it
> >> > using
> >> > the shell would be enough IMO.
> >> >
> >>
> >> Is that suggestion to just have the blog posts and only a single top
> >> level sample README? Blog posts seem like a fine idea but i do think
> >> its good to have some sort of doc within each sample folder as its so
> >> obvious there when a new user first looks at a sample.
> >>
> >>   ...ant
> >
> >
>
> I think it's useful to have descriptive text distributed with the
> samples otherwise it can be difficult to work out what the intended
> function is. I've nothing against blogging about the samples but if we
> commit to this a primary mechanism for detailed description then we
> have the same problem we have with the web site in that people have to
> follow a link to get to the details.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Laws <si...@googlemail.com>]

On Wed, Feb 23, 2011 at 1:14 PM, Florian Moga <mo...@gmail.com> wrote:
> Yes, I was thinking that in this case READMEs would only contain some
> instructions on how to start the shell so it will basically be the same
> README copied in each and every folder.
>
> On Wed, Feb 23, 2011 at 3:02 PM, ant elder <an...@apache.org> wrote:
>>
>> On Wed, Feb 23, 2011 at 9:20 AM, Florian Moga <mo...@gmail.com> wrote:
>> > As for doc, what do you think about the following idea? As soon as a
>> > sample
>> > graduates from contrib/ we can write a blog post explaining various
>> > things
>> > about it. It's much more interactive for both users and us. Also, the
>> > blog
>> > will probably get more attention and would be more complete. In this
>> > case, a
>> > top level README explaning how to start a sample and interact with it
>> > using
>> > the shell would be enough IMO.
>> >
>>
>> Is that suggestion to just have the blog posts and only a single top
>> level sample README? Blog posts seem like a fine idea but i do think
>> its good to have some sort of doc within each sample folder as its so
>> obvious there when a new user first looks at a sample.
>>
>>   ...ant
>
>

I think it's useful to have descriptive text distributed with the
samples otherwise it can be difficult to work out what the intended
function is. I've nothing against blogging about the samples but if we
commit to this a primary mechanism for detailed description then we
have the same problem we have with the web site in that people have to
follow a link to get to the details.

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Florian Moga <mo...@gmail.com>]

Yes, I was thinking that in this case READMEs would only contain some
instructions on how to start the shell so it will basically be the same
README copied in each and every folder.

On Wed, Feb 23, 2011 at 3:02 PM, ant elder <an...@apache.org> wrote:

> On Wed, Feb 23, 2011 at 9:20 AM, Florian Moga <mo...@gmail.com> wrote:
> > As for doc, what do you think about the following idea? As soon as a
> sample
> > graduates from contrib/ we can write a blog post explaining various
> things
> > about it. It's much more interactive for both users and us. Also, the
> blog
> > will probably get more attention and would be more complete. In this
> case, a
> > top level README explaning how to start a sample and interact with it
> using
> > the shell would be enough IMO.
> >
>
> Is that suggestion to just have the blog posts and only a single top
> level sample README? Blog posts seem like a fine idea but i do think
> its good to have some sort of doc within each sample folder as its so
> obvious there when a new user first looks at a sample.
>
>   ...ant
>

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Wed, Feb 23, 2011 at 9:20 AM, Florian Moga <mo...@gmail.com> wrote:
> As for doc, what do you think about the following idea? As soon as a sample
> graduates from contrib/ we can write a blog post explaining various things
> about it. It's much more interactive for both users and us. Also, the blog
> will probably get more attention and would be more complete. In this case, a
> top level README explaning how to start a sample and interact with it using
> the shell would be enough IMO.
>

Is that suggestion to just have the blog posts and only a single top
level sample README? Blog posts seem like a fine idea but i do think
its good to have some sort of doc within each sample folder as its so
obvious there when a new user first looks at a sample.

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Florian Moga <mo...@gmail.com>]

As for doc, what do you think about the following idea? As soon as a sample
graduates from contrib/ we can write a blog post explaining various things
about it. It's much more interactive for both users and us. Also, the blog
will probably get more attention and would be more complete. In this case, a
top level README explaning how to start a sample and interact with it using
the shell would be enough IMO.


On Wed, Feb 23, 2011 at 11:07 AM, Florian Moga <mo...@gmail.com> wrote:

> On Wed, Feb 23, 2011 at 10:46 AM, ant elder <an...@apache.org> wrote:
>
>>
>> The main differences are that the testcase doesn't run Tuscany and the
>> Tuscany plugin isn't defined in the pom.xml.
>
>
> I think having a unit test that starts the Tuscany runtime has multiple
> benefits:
>   - more helpful for the newbie user (he's actually seeing the runtime
> starting)
>   - helps us keep track of the broken samples through Hudson
>
> Regarding the tuscany shell, I'm not sure which option I'd prefer for
> starting it (declaring the tuscany plugin and use it with maven or have the
> user set his path to the jar). I guess I'm fine with both.
>

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Florian Moga <mo...@gmail.com>]

On Wed, Feb 23, 2011 at 10:46 AM, ant elder <an...@apache.org> wrote:

>
> The main differences are that the testcase doesn't run Tuscany and the
> Tuscany plugin isn't defined in the pom.xml.


I think having a unit test that starts the Tuscany runtime has multiple
benefits:
  - more helpful for the newbie user (he's actually seeing the runtime
starting)
  - helps us keep track of the broken samples through Hudson

Regarding the tuscany shell, I'm not sure which option I'd prefer for
starting it (declaring the tuscany plugin and use it with maven or have the
user set his path to the jar). I guess I'm fine with both.

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Laws <si...@googlemail.com>]

> Re the doc, what sort of thing do we want? I don't think what we tried
> with the beta1 release with having the sample doc only on the Tuscany
> website worked that well, so these samples just have a plain text
> README file. What could be done differently or better over that?
>
>   ...ant
>

I agree. It was relatively easy to generate the doc having it in one
place but it didn't work from a user point of view. How about we ship
html formatted READMEs with each sample to try and get the best of
both worlds.

Ideally they would be linked from the website also so people could
browse the sample portfolio directly from the website. This part is
tied up with how we revamp the website so we should probably treat
that as a separate problem.

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Mon, Feb 21, 2011 at 10:52 AM, Simon Laws <si...@googlemail.com> wrote:
> On Sun, Feb 20, 2011 at 8:35 AM, ant elder <an...@apache.org> wrote:
>> On Tue, Feb 15, 2011 at 7:08 PM, ant elder <an...@apache.org> wrote:
>>> On Thu, Feb 10, 2011 at 9:10 AM, ant elder <an...@apache.org> wrote:
>>>
>>>>
>>>> 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.
>>>>
>>>
>>> So how do we progress this? What do we need to change in the
>>> helloworld sample at
>>> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/helloworld-contribution/
>>> to make in complete and move it back to trunk/samples?
>>>
>>>   ...ant
>>>
>>
>> Ok no comments so if we're all happy with that then in a few days i'll
>> move it back to trunk/samples and use it as a model for the next ones.
>>
>>  ...ant
>>
>
> I wonder whether we need the ability to run from maven at all. We need
> a way for people to compile samples of course. I've be happy with the
> following.
>
> 1 - use the shell as the primary out of the box mechanism for
> loading/running sample contributions where possible
> 2 - present all the other options for running/embedding Tuscany under
> "running tuscany" which is after all why we created that  directory in
> the first place, i.e. to separate sample contributions from the large
> number of ways we have of running them
> 3 - make using the sample contributions in eclipse really easy
> (re-instate the eclipse plugin? provide instructions for generating
> projects files? Or even ship project files?)
>
> I'd also like us to use this one sample to decide how we are going to
> do the docs so the get it right for the rest of them.
>
> I'm +1 for moving back to trunk as is for further development.
>
> Simon
>

So we can see what that looks like I've added another version of the
sample based on what i think you're suggesting:
https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/helloworld-contribution2/

The main differences are that the testcase doesn't run Tuscany and the
Tuscany plugin isn't defined in the pom.xml.

Re the doc, what sort of thing do we want? I don't think what we tried
with the beta1 release with having the sample doc only on the Tuscany
website worked that well, so these samples just have a plain text
README file. What could be done differently or better over that?

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Laws <si...@googlemail.com>]

On Sun, Feb 20, 2011 at 8:35 AM, ant elder <an...@apache.org> wrote:
> On Tue, Feb 15, 2011 at 7:08 PM, ant elder <an...@apache.org> wrote:
>> On Thu, Feb 10, 2011 at 9:10 AM, ant elder <an...@apache.org> wrote:
>>
>>>
>>> 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.
>>>
>>
>> So how do we progress this? What do we need to change in the
>> helloworld sample at
>> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/helloworld-contribution/
>> to make in complete and move it back to trunk/samples?
>>
>>   ...ant
>>
>
> Ok no comments so if we're all happy with that then in a few days i'll
> move it back to trunk/samples and use it as a model for the next ones.
>
>  ...ant
>

I wonder whether we need the ability to run from maven at all. We need
a way for people to compile samples of course. I've be happy with the
following.

1 - use the shell as the primary out of the box mechanism for
loading/running sample contributions where possible
2 - present all the other options for running/embedding Tuscany under
"running tuscany" which is after all why we created that  directory in
the first place, i.e. to separate sample contributions from the large
number of ways we have of running them
3 - make using the sample contributions in eclipse really easy
(re-instate the eclipse plugin? provide instructions for generating
projects files? Or even ship project files?)

I'd also like us to use this one sample to decide how we are going to
do the docs so the get it right for the rest of them.

I'm +1 for moving back to trunk as is for further development.

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Tue, Feb 15, 2011 at 7:08 PM, ant elder <an...@apache.org> wrote:
> On Thu, Feb 10, 2011 at 9:10 AM, ant elder <an...@apache.org> wrote:
>
>>
>> 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.
>>
>
> So how do we progress this? What do we need to change in the
> helloworld sample at
> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/helloworld-contribution/
> to make in complete and move it back to trunk/samples?
>
>   ...ant
>

Ok no comments so if we're all happy with that then in a few days i'll
move it back to trunk/samples and use it as a model for the next ones.

  ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Thu, Feb 10, 2011 at 9:10 AM, ant elder <an...@apache.org> wrote:

>
> 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.
>

So how do we progress this? What do we need to change in the
helloworld sample at
https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/helloworld-contribution/
to make in complete and move it back to trunk/samples?

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Thu, Feb 10, 2011 at 10:36 AM, Florian Moga <mo...@gmail.com> wrote:

> 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?
>

I've been thinking the same thing lately, especially now that you
pointed out that we can do "mvn ant:ant" to have Ant scripts
automatically generated. Instead of Ant builds for each sample there
could just be some doc in the top level samples folder or README that
describes how to use "mvn ant:ant".

The build scripts generated with mvn ant:ant download all the
dependencies from the Maven repositories, that does mean that not much
would be actually using all the jars from the Tuscany binary
distribution so we might want to consider what all thats really for.

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Florian Moga <mo...@gmail.com>]

>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 <an...@apache.org> wrote:

> On Tue, Feb 8, 2011 at 7:18 PM, ant elder <an...@apache.org> wrote:
> > On Tue, Feb 8, 2011 at 1:26 PM, Simon Laws <si...@googlemail.com>
> wrote:
> >> On Tue, Feb 8, 2011 at 12:58 PM, ant elder <an...@apache.org> wrote:
> >>> On Tue, Feb 8, 2011 at 11:09 AM, Florian Moga <mo...@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
>

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Tue, Feb 8, 2011 at 7:18 PM, ant elder <an...@apache.org> wrote:
> On Tue, Feb 8, 2011 at 1:26 PM, Simon Laws <si...@googlemail.com> wrote:
>> On Tue, Feb 8, 2011 at 12:58 PM, ant elder <an...@apache.org> wrote:
>>> On Tue, Feb 8, 2011 at 11:09 AM, Florian Moga <mo...@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

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Tue, Feb 8, 2011 at 8:04 PM, Florian Moga <mo...@gmail.com> wrote:
> On Tue, Feb 8, 2011 at 9:18 PM, ant elder <an...@apache.org> wrote:
>>
>> 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
>
> Does this mean that samples will be in their current format for beta2? Or
> shall we leave only be helloworld-contribution and helloworld-webapp?
>

As things are now I'd probably just do the svn copy to the branch and
then leave everything as is, if/when the release is made from the
branch then the others could get removed.

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Florian Moga <mo...@gmail.com>]

On Tue, Feb 8, 2011 at 9:18 PM, ant elder <an...@apache.org> wrote:
>
> 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
>

Does this mean that samples will be in their current format for beta2? Or
shall we leave only be helloworld-contribution and helloworld-webapp?


> - 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.
>

I'd be glad to help on that.

   ...ant
>

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Tue, Feb 8, 2011 at 1:26 PM, Simon Laws <si...@googlemail.com> wrote:
> On Tue, Feb 8, 2011 at 12:58 PM, ant elder <an...@apache.org> wrote:
>> On Tue, Feb 8, 2011 at 11:09 AM, Florian Moga <mo...@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

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Laws <si...@googlemail.com>]

On Tue, Feb 8, 2011 at 12:58 PM, ant elder <an...@apache.org> wrote:
> On Tue, Feb 8, 2011 at 11:09 AM, Florian Moga <mo...@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

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Tue, Feb 8, 2011 at 11:09 AM, Florian Moga <mo...@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

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Florian Moga <mo...@gmail.com>]

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.


On Tue, Feb 8, 2011 at 10:39 AM, ant elder <an...@apache.org> wrote:

> On Mon, Feb 7, 2011 at 8:43 PM, Florian Moga <mo...@gmail.com> wrote:
> > I gave it a try and it found the same problem. It looks like it is not
> > expected that the junit jar to be specified amongst dependencies but in
> the
> > $ANT_HOME/lib folder... I've added the build.test.classpath to the
> > test-junit-present target and tests are working now.
> >   <target name="test-junit-present">
> >     <available classname="junit.framework.Test" property="junit.present">
> > <classpath refid="build.test.classpath"/>
> >     </available>
> >   </target>
> > After that, at the package target I'm getting "maven-build.xml:250:
> > Attributes must have name and value" and I cannot find what it's all
> about.
> >
>
> That updated test-junit-present target fixes it for me and everything
> seems to run fine and I don't get any of those problems with the
> attributes that you see. The plugin doc makes it sound like that junit
> issue might be expected behavior but it seems like a bug to me or at
> least something that should be a plugin config option.
>
>   ...ant
>

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Mon, Feb 7, 2011 at 8:43 PM, Florian Moga <mo...@gmail.com> wrote:
> I gave it a try and it found the same problem. It looks like it is not
> expected that the junit jar to be specified amongst dependencies but in the
> $ANT_HOME/lib folder... I've added the build.test.classpath to the
> test-junit-present target and tests are working now.
>   <target name="test-junit-present">
>     <available classname="junit.framework.Test" property="junit.present">
> <classpath refid="build.test.classpath"/>
>     </available>
>   </target>
> After that, at the package target I'm getting "maven-build.xml:250:
> Attributes must have name and value" and I cannot find what it's all about.
>

That updated test-junit-present target fixes it for me and everything
seems to run fine and I don't get any of those problems with the
attributes that you see. The plugin doc makes it sound like that junit
issue might be expected behavior but it seems like a bug to me or at
least something that should be a plugin config option.

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Florian Moga <mo...@gmail.com>]

I gave it a try and it found the same problem. It looks like it is not
expected that the junit jar to be specified amongst dependencies but in the
$ANT_HOME/lib folder... I've added the build.test.classpath to the
test-junit-present target and tests are working now.

  <target name="test-junit-present">
    <available classname="junit.framework.Test" property="junit.present">
<classpath refid="build.test.classpath"/>
    </available>
  </target>

After that, at the package target I'm getting "maven-build.xml:250:
Attributes must have name and value" and I cannot find what it's all about.


On Mon, Feb 7, 2011 at 9:13 PM, ant elder <an...@apache.org> wrote:

> On Sun, Feb 6, 2011 at 12:50 PM, Florian MOGA <mo...@gmail.com> wrote:
> > I've just checked out "mvn ant:ant" and seems to do a decent job in
> > generating an ant build file.
>
> I didn't know about "mvn ant:ant" that does look good. I haven't quite
> got it to work properly yet though, if i run "mvn ant:ant" in
> getting-started/helloworld-contribution it all seems to work but then
> when running it fails to run the unit tests saying junit isn't
> available, which is odd as it seems to download junit ok and looks
> like it is where it says its looking. Does that work for anyone else?
>
>   ...ant
>

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Sun, Feb 6, 2011 at 12:50 PM, Florian MOGA <mo...@gmail.com> wrote:
> I've just checked out "mvn ant:ant" and seems to do a decent job in
> generating an ant build file.

I didn't know about "mvn ant:ant" that does look good. I haven't quite
got it to work properly yet though, if i run "mvn ant:ant" in
getting-started/helloworld-contribution it all seems to work but then
when running it fails to run the unit tests saying junit isn't
available, which is odd as it seems to download junit ok and looks
like it is where it says its looking. Does that work for anyone else?

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Florian MOGA <mo...@gmail.com>]

I've just checked out "mvn ant:ant" and seems to do a decent job in
generating an ant build file.

Figuring out what should samples look like imply taking other decisions
first (how will documentation look like, what type of launcher is required,
...). So, for now I'd suggest to temporarily move the samples that don't
work at all and require a reasonable amount of resources to fix (most of
them are trivial fixes so there will be a fairly small number that will get
moved). IMO that should be enough to ship the release. After that we might
need to first agree on the other topics in order to have a knowledgeable
context for this discussion.

On Sun, Feb 6, 2011 at 1:48 PM, ant elder <an...@gmail.com> wrote:

> On Sun, Feb 6, 2011 at 11:32 AM, Simon Nash <na...@apache.org> wrote:
> > Florian MOGA wrote:
> >>
> >> Current naming with beta isn't that flexible. We could continue doing a
> >> lot of betaX releases or start naming betaX.X. I'm fine with both of
> them.
> >> After we get 2.0 out we can start having 2.0.1, 2.0.2 ... 2.1, 2.1.1,
> ....,
> >> 2.2 and things will get more obvious.
> >>
> >> Regarding samples, we can either move them to unreleased/ and move them
> >> back as they get fixed or we can just open a ticket with subtasks for
> each
> >> sample to keep track of them. I assume we're now doing a 'minor' release
> so
> >> doesn't really matter at the moment.
> >>
> > IMO it would be better to only include samples that work.  It's
> > frustrating and confusing for users when they attempt to run a sample
> > that's included in a release and find that it doesn't work.
> >
> > Are there a few samples that could be got working quite easily?
> > If so, I think it would be good to include those few in this release
> > and move the rest to unreleased/ until the next major release.
> > If the release includes working samples (even a few) then we could
> > regard it as a "major" release.
> >
> >  Simon
> >
>
> That sounds reasonable but what does "work" mean? Up till now we've
> had no minimum standard so anyone can add anything to samples/ and it
> gets included in a release. I'd probably in favour of tightening that
> up a bit now but I wonder if we'd agree on a minimum set of
> requirements.
>
> We have samples with no Ant build, no doc, no obvious way of running
> them, and not even a sentence in a README saying what the purpose of
> the sample is, but some of them do still "work" if you happen to know
> what to do with it. Must there be proper tests so we know if the
> sample gets broken? What if someone doesn't particularly care about
> Ant builds so doesn't write a build.xml, is that sample excluded or is
> a release held up till someone else write the build file?
>
>   ...ant
>

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@gmail.com>]

On Sun, Feb 6, 2011 at 11:32 AM, Simon Nash <na...@apache.org> wrote:
> Florian MOGA wrote:
>>
>> Current naming with beta isn't that flexible. We could continue doing a
>> lot of betaX releases or start naming betaX.X. I'm fine with both of them.
>> After we get 2.0 out we can start having 2.0.1, 2.0.2 ... 2.1, 2.1.1, ....,
>> 2.2 and things will get more obvious.
>>
>> Regarding samples, we can either move them to unreleased/ and move them
>> back as they get fixed or we can just open a ticket with subtasks for each
>> sample to keep track of them. I assume we're now doing a 'minor' release so
>> doesn't really matter at the moment.
>>
> IMO it would be better to only include samples that work.  It's
> frustrating and confusing for users when they attempt to run a sample
> that's included in a release and find that it doesn't work.
>
> Are there a few samples that could be got working quite easily?
> If so, I think it would be good to include those few in this release
> and move the rest to unreleased/ until the next major release.
> If the release includes working samples (even a few) then we could
> regard it as a "major" release.
>
>  Simon
>

That sounds reasonable but what does "work" mean? Up till now we've
had no minimum standard so anyone can add anything to samples/ and it
gets included in a release. I'd probably in favour of tightening that
up a bit now but I wonder if we'd agree on a minimum set of
requirements.

We have samples with no Ant build, no doc, no obvious way of running
them, and not even a sentence in a README saying what the purpose of
the sample is, but some of them do still "work" if you happen to know
what to do with it. Must there be proper tests so we know if the
sample gets broken? What if someone doesn't particularly care about
Ant builds so doesn't write a build.xml, is that sample excluded or is
a release held up till someone else write the build file?

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Nash <na...@apache.org>]

Florian MOGA wrote:
> Current naming with beta isn't that flexible. We could continue doing a 
> lot of betaX releases or start naming betaX.X. I'm fine with both of 
> them. After we get 2.0 out we can start having 2.0.1, 2.0.2 ... 2.1, 
> 2.1.1, ...., 2.2 and things will get more obvious.
> 
> Regarding samples, we can either move them to unreleased/ and move them 
> back as they get fixed or we can just open a ticket with subtasks for 
> each sample to keep track of them. I assume we're now doing a 'minor' 
> release so doesn't really matter at the moment.
> 
IMO it would be better to only include samples that work.  It's
frustrating and confusing for users when they attempt to run a sample
that's included in a release and find that it doesn't work.

Are there a few samples that could be got working quite easily?
If so, I think it would be good to include those few in this release
and move the rest to unreleased/ until the next major release.
If the release includes working samples (even a few) then we could
regard it as a "major" release.

   Simon

> On Sat, Feb 5, 2011 at 8:44 PM, ant elder <ant.elder@gmail.com 
> <ma...@gmail.com>> wrote:
> 
>     Well ok, the current release was going to be called 2.0-beta2,with
>     where we are now and not having done a 2.0 yet if i want to do a
>     release now from the current trunk then what should it be called to it
>     get out with the samples being in the less than perfect state that
>     they are? And can the current samples be left in or should they be
>     removed from the binary distribution?
> 
>       ...ant
> 
>     On Sat, Feb 5, 2011 at 2:44 PM, Florian MOGA <moga.flo@gmail.com
>     <ma...@gmail.com>> wrote:
>      > I agree with Simon. Cutting releases just to make fixes available for
>      > affected users is definitely something we should do more
>     often. Marking
>      > releases with major and minor sounds like a good way to signal
>     what type of
>      > release it is. It also helps the release review process as we
>     know what to
>      > focus on. I'm +1 for this as I believe it enables us to do more
>     frequent
>      > releases.
>      >
>      > On Sat, Feb 5, 2011 at 4:10 PM, Simon Nash <nash@apache.org
>     <ma...@apache.org>> wrote:
>      >>
>      >> ant elder wrote:
>      >>>
>      >>> On Sat, Feb 5, 2011 at 10:45 AM, Florian MOGA
>     <moga.flo@gmail.com <ma...@gmail.com>> wrote:
>      >>>>
>      >>>> On Sat, Feb 5, 2011 at 11:58 AM, ant elder
>     <ant.elder@gmail.com <ma...@gmail.com>> wrote:
>      >>>>>
>      >>>>> Great stuff Florian, thanks for doing that work.
>      >>>>>
>      >>>>> Some of those I know are relatively easy to fix and its just
>     a matter
>      >>>>> of getting around to it.
>      >>>>
>      >>>> That's right, some of them are trivial, but some are pretty
>     nasty... I'd
>      >>>> consider moving samples like helloworld-js-client-webapp to the
>      >>>> unreleased
>      >>>> folder.
>      >>>>
>      >>>>> I'll try to find some time on it over the
>      >>>>> next days. Some of those don't have unit or integration tests
>     run in
>      >>>>> the build is why they got broken but quite a lot of them do
>     but the
>      >>>>> tests just aren't testing enough or properly.
>      >>>>
>      >>>> Talking about unit tests, I've noticed quite a lot of tests
>     marked as
>      >>>> skipped in the maven log... This worries me and I think we should
>      >>>> definitely
>      >>>> revisit them in the next releases.
>      >>>>>
>      >>>>> I'm starting to wonder if we should find a new sample
>     approach. An
>      >>>>> issue is presently anyone can add a sample which may or may
>     not have
>      >>>>> doc or tests or work in a standard or unusual way and it gets
>     included
>      >>>>> in the releases and then adds to perceived quality seen by
>     users and
>      >>>>> release reviewers. Because of that what we often do is delay
>     releasing
>      >>>>> until "most" of the samples have been brought up to a reasonable
>      >>>>> consistent standard but thats not perfect as it slows down
>     releases
>      >>>>> and theres still usually some samples that don't work
>     normally and
>      >>>>> without doc which users to find a get confused about.
>      >>>>
>      >>>> As I've already mentioned on another thread, I think a code
>     review tool
>      >>>> would help a lot achieving more quality in our project. I'd go
>     for no
>      >>>> major
>      >>>> commits without code review but that might not fit everyones
>     taste. It
>      >>>> actually isn't that painful as it sounds. A good percent of
>     the bugs are
>      >>>> found, knowledge is transferred, more filtering / brushing up
>     until
>      >>>> something actually gets in trunk. It might all determine us to
>     write
>      >>>> more
>      >>>> quality code, add tests, doc.
>      >>>> I'm also thinking that as we're heading to alpha releases, we
>     need to
>      >>>> 'freeze' the runtime code and do more maintenance releases
>     (samples,
>      >>>> unit
>      >>>> tests, documentation). It might not be as fun as doing
>     development in
>      >>>> the
>      >>>> runtime code but I'm afraid it is the only way to have a
>     quality 2.0
>      >>>> out.
>      >>>> Last time I heard, we had good oasis compliance, so I think we can
>      >>>> afford
>      >>>> doing this. With that in mind, I'd like to propose for the
>     upcoming
>      >>>> releases
>      >>>> to start spinning a new release right after we're done with
>     another one.
>      >>>>
>      >>>>> One thing we could try is releasing the samples separately
>     from the
>      >>>>> main code, a lot of other projects do that, and our SDO
>     releases had
>      >>>>> the samples separate. That would mean we could do much more
>     frequent
>      >>>>> releases of the runtime code as releases wouldn't get held up
>     with
>      >>>>> sample quality issues. Is any one for or against trying
>     something like
>      >>>>> that?
>      >>>>
>      >>>> I think keeping samples together with the runtime code is a
>     good thing
>      >>>> because it forces us to maintain samples as well :) If we
>     split samples
>      >>>> from
>      >>>> code, I think we're going to run into version mismatch
>     problems and it
>      >>>> will
>      >>>> be much harder and more painful to do sample releases than it
>     is now.
>      >>>> I'm
>      >>>> calling -0 at the moment, I'd like to see other opinions as well.
>      >>>>
>      >>>>>  ...ant
>      >>>>
>      >>>
>      >>> Consider a hypothetical example:
>      >>>
>      >>> Raymond commits a fix for the pass-by-reference enhancements
>     mentioned
>      >>> earlier this week and really wants to get the fix out in a
>     release for
>      >>> his users to use.
>      >>>
>      >>> Wouldn't it be better to be able to release that right now
>     instead of
>      >>> having to wait for weeks or months while we tinker about with
>     samples?
>      >>>
>      >>>   ...ant
>      >>>
>      >>>
>      >> It depends on who is the audience for the release.
>      >>
>      >> 1) If the release is going to be consumed by existing Tuscany
>     users, who
>      >>   are familiar with the technology and have already developed
>      >> applications,
>      >>   these people don't need working samples and would like to get
>     the fix.
>      >>
>      >> 2) If the release is going to be consumed by people who are
>     interested
>      >>   in Tuscany and SCA and are evaluating the technology with a
>     view to
>      >>   possible adoption, doing a release without samples (or with
>     non-working
>      >>   samples) is likely to put these people off Tuscany because
>     they won't
>      >>   be able to understand what it is and how to use it.
>      >>
>      >> At this stage I believe that Tuscany/SCA adoption is still in
>     the growth
>      >> phase and therefore the audience for category 2) should exceed
>     that for
>      >> category 1).  If not, I would be very concerned.
>      >>
>      >> Could we have the best of both worlds by doing "major" and "minor"
>      >> releases as follows?
>      >>  major release N: contains samples that work
>      >>  minor release N.1: fixes to the runtime, without new samples
>      >>  minor release N.m: as above
>      >>  major release N+1: adds more samples that work, and functional
>      >> enhancements
>      >>  minor release N+1.1: fixes to the runtime, without new samples
>      >>  minor release N+1.m: as above
>      >>
>      >> The N.m designation isn't meant to dictate what the releases are
>     called.
>      >>
>      >>  Simon
>      >>
>      >
>      >
> 
> 

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Florian MOGA <mo...@gmail.com>]

Current naming with beta isn't that flexible. We could continue doing a lot
of betaX releases or start naming betaX.X. I'm fine with both of them. After
we get 2.0 out we can start having 2.0.1, 2.0.2 ... 2.1, 2.1.1, ...., 2.2
and things will get more obvious.

Regarding samples, we can either move them to unreleased/ and move them back
as they get fixed or we can just open a ticket with subtasks for each sample
to keep track of them. I assume we're now doing a 'minor' release so doesn't
really matter at the moment.

On Sat, Feb 5, 2011 at 8:44 PM, ant elder <an...@gmail.com> wrote:

> Well ok, the current release was going to be called 2.0-beta2,with
> where we are now and not having done a 2.0 yet if i want to do a
> release now from the current trunk then what should it be called to it
> get out with the samples being in the less than perfect state that
> they are? And can the current samples be left in or should they be
> removed from the binary distribution?
>
>   ...ant
>
> On Sat, Feb 5, 2011 at 2:44 PM, Florian MOGA <mo...@gmail.com> wrote:
> > I agree with Simon. Cutting releases just to make fixes available for
> > affected users is definitely something we should do more often. Marking
> > releases with major and minor sounds like a good way to signal what type
> of
> > release it is. It also helps the release review process as we know what
> to
> > focus on. I'm +1 for this as I believe it enables us to do more frequent
> > releases.
> >
> > On Sat, Feb 5, 2011 at 4:10 PM, Simon Nash <na...@apache.org> wrote:
> >>
> >> ant elder wrote:
> >>>
> >>> On Sat, Feb 5, 2011 at 10:45 AM, Florian MOGA <mo...@gmail.com>
> wrote:
> >>>>
> >>>> On Sat, Feb 5, 2011 at 11:58 AM, ant elder <an...@gmail.com>
> wrote:
> >>>>>
> >>>>> Great stuff Florian, thanks for doing that work.
> >>>>>
> >>>>> Some of those I know are relatively easy to fix and its just a matter
> >>>>> of getting around to it.
> >>>>
> >>>> That's right, some of them are trivial, but some are pretty nasty...
> I'd
> >>>> consider moving samples like helloworld-js-client-webapp to the
> >>>> unreleased
> >>>> folder.
> >>>>
> >>>>> I'll try to find some time on it over the
> >>>>> next days. Some of those don't have unit or integration tests run in
> >>>>> the build is why they got broken but quite a lot of them do but the
> >>>>> tests just aren't testing enough or properly.
> >>>>
> >>>> Talking about unit tests, I've noticed quite a lot of tests marked as
> >>>> skipped in the maven log... This worries me and I think we should
> >>>> definitely
> >>>> revisit them in the next releases.
> >>>>>
> >>>>> I'm starting to wonder if we should find a new sample approach. An
> >>>>> issue is presently anyone can add a sample which may or may not have
> >>>>> doc or tests or work in a standard or unusual way and it gets
> included
> >>>>> in the releases and then adds to perceived quality seen by users and
> >>>>> release reviewers. Because of that what we often do is delay
> releasing
> >>>>> until "most" of the samples have been brought up to a reasonable
> >>>>> consistent standard but thats not perfect as it slows down releases
> >>>>> and theres still usually some samples that don't work normally and
> >>>>> without doc which users to find a get confused about.
> >>>>
> >>>> As I've already mentioned on another thread, I think a code review
> tool
> >>>> would help a lot achieving more quality in our project. I'd go for no
> >>>> major
> >>>> commits without code review but that might not fit everyones taste. It
> >>>> actually isn't that painful as it sounds. A good percent of the bugs
> are
> >>>> found, knowledge is transferred, more filtering / brushing up until
> >>>> something actually gets in trunk. It might all determine us to write
> >>>> more
> >>>> quality code, add tests, doc.
> >>>> I'm also thinking that as we're heading to alpha releases, we need to
> >>>> 'freeze' the runtime code and do more maintenance releases (samples,
> >>>> unit
> >>>> tests, documentation). It might not be as fun as doing development in
> >>>> the
> >>>> runtime code but I'm afraid it is the only way to have a quality 2.0
> >>>> out.
> >>>> Last time I heard, we had good oasis compliance, so I think we can
> >>>> afford
> >>>> doing this. With that in mind, I'd like to propose for the upcoming
> >>>> releases
> >>>> to start spinning a new release right after we're done with another
> one.
> >>>>
> >>>>> One thing we could try is releasing the samples separately from the
> >>>>> main code, a lot of other projects do that, and our SDO releases had
> >>>>> the samples separate. That would mean we could do much more frequent
> >>>>> releases of the runtime code as releases wouldn't get held up with
> >>>>> sample quality issues. Is any one for or against trying something
> like
> >>>>> that?
> >>>>
> >>>> I think keeping samples together with the runtime code is a good thing
> >>>> because it forces us to maintain samples as well :) If we split
> samples
> >>>> from
> >>>> code, I think we're going to run into version mismatch problems and it
> >>>> will
> >>>> be much harder and more painful to do sample releases than it is now.
> >>>> I'm
> >>>> calling -0 at the moment, I'd like to see other opinions as well.
> >>>>
> >>>>>  ...ant
> >>>>
> >>>
> >>> Consider a hypothetical example:
> >>>
> >>> Raymond commits a fix for the pass-by-reference enhancements mentioned
> >>> earlier this week and really wants to get the fix out in a release for
> >>> his users to use.
> >>>
> >>> Wouldn't it be better to be able to release that right now instead of
> >>> having to wait for weeks or months while we tinker about with samples?
> >>>
> >>>   ...ant
> >>>
> >>>
> >> It depends on who is the audience for the release.
> >>
> >> 1) If the release is going to be consumed by existing Tuscany users, who
> >>   are familiar with the technology and have already developed
> >> applications,
> >>   these people don't need working samples and would like to get the fix.
> >>
> >> 2) If the release is going to be consumed by people who are interested
> >>   in Tuscany and SCA and are evaluating the technology with a view to
> >>   possible adoption, doing a release without samples (or with
> non-working
> >>   samples) is likely to put these people off Tuscany because they won't
> >>   be able to understand what it is and how to use it.
> >>
> >> At this stage I believe that Tuscany/SCA adoption is still in the growth
> >> phase and therefore the audience for category 2) should exceed that for
> >> category 1).  If not, I would be very concerned.
> >>
> >> Could we have the best of both worlds by doing "major" and "minor"
> >> releases as follows?
> >>  major release N: contains samples that work
> >>  minor release N.1: fixes to the runtime, without new samples
> >>  minor release N.m: as above
> >>  major release N+1: adds more samples that work, and functional
> >> enhancements
> >>  minor release N+1.1: fixes to the runtime, without new samples
> >>  minor release N+1.m: as above
> >>
> >> The N.m designation isn't meant to dictate what the releases are called.
> >>
> >>  Simon
> >>
> >
> >
>

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@gmail.com>]

Well ok, the current release was going to be called 2.0-beta2,with
where we are now and not having done a 2.0 yet if i want to do a
release now from the current trunk then what should it be called to it
get out with the samples being in the less than perfect state that
they are? And can the current samples be left in or should they be
removed from the binary distribution?

   ...ant

On Sat, Feb 5, 2011 at 2:44 PM, Florian MOGA <mo...@gmail.com> wrote:
> I agree with Simon. Cutting releases just to make fixes available for
> affected users is definitely something we should do more often. Marking
> releases with major and minor sounds like a good way to signal what type of
> release it is. It also helps the release review process as we know what to
> focus on. I'm +1 for this as I believe it enables us to do more frequent
> releases.
>
> On Sat, Feb 5, 2011 at 4:10 PM, Simon Nash <na...@apache.org> wrote:
>>
>> ant elder wrote:
>>>
>>> On Sat, Feb 5, 2011 at 10:45 AM, Florian MOGA <mo...@gmail.com> wrote:
>>>>
>>>> On Sat, Feb 5, 2011 at 11:58 AM, ant elder <an...@gmail.com> wrote:
>>>>>
>>>>> Great stuff Florian, thanks for doing that work.
>>>>>
>>>>> Some of those I know are relatively easy to fix and its just a matter
>>>>> of getting around to it.
>>>>
>>>> That's right, some of them are trivial, but some are pretty nasty... I'd
>>>> consider moving samples like helloworld-js-client-webapp to the
>>>> unreleased
>>>> folder.
>>>>
>>>>> I'll try to find some time on it over the
>>>>> next days. Some of those don't have unit or integration tests run in
>>>>> the build is why they got broken but quite a lot of them do but the
>>>>> tests just aren't testing enough or properly.
>>>>
>>>> Talking about unit tests, I've noticed quite a lot of tests marked as
>>>> skipped in the maven log... This worries me and I think we should
>>>> definitely
>>>> revisit them in the next releases.
>>>>>
>>>>> I'm starting to wonder if we should find a new sample approach. An
>>>>> issue is presently anyone can add a sample which may or may not have
>>>>> doc or tests or work in a standard or unusual way and it gets included
>>>>> in the releases and then adds to perceived quality seen by users and
>>>>> release reviewers. Because of that what we often do is delay releasing
>>>>> until "most" of the samples have been brought up to a reasonable
>>>>> consistent standard but thats not perfect as it slows down releases
>>>>> and theres still usually some samples that don't work normally and
>>>>> without doc which users to find a get confused about.
>>>>
>>>> As I've already mentioned on another thread, I think a code review tool
>>>> would help a lot achieving more quality in our project. I'd go for no
>>>> major
>>>> commits without code review but that might not fit everyones taste. It
>>>> actually isn't that painful as it sounds. A good percent of the bugs are
>>>> found, knowledge is transferred, more filtering / brushing up until
>>>> something actually gets in trunk. It might all determine us to write
>>>> more
>>>> quality code, add tests, doc.
>>>> I'm also thinking that as we're heading to alpha releases, we need to
>>>> 'freeze' the runtime code and do more maintenance releases (samples,
>>>> unit
>>>> tests, documentation). It might not be as fun as doing development in
>>>> the
>>>> runtime code but I'm afraid it is the only way to have a quality 2.0
>>>> out.
>>>> Last time I heard, we had good oasis compliance, so I think we can
>>>> afford
>>>> doing this. With that in mind, I'd like to propose for the upcoming
>>>> releases
>>>> to start spinning a new release right after we're done with another one.
>>>>
>>>>> One thing we could try is releasing the samples separately from the
>>>>> main code, a lot of other projects do that, and our SDO releases had
>>>>> the samples separate. That would mean we could do much more frequent
>>>>> releases of the runtime code as releases wouldn't get held up with
>>>>> sample quality issues. Is any one for or against trying something like
>>>>> that?
>>>>
>>>> I think keeping samples together with the runtime code is a good thing
>>>> because it forces us to maintain samples as well :) If we split samples
>>>> from
>>>> code, I think we're going to run into version mismatch problems and it
>>>> will
>>>> be much harder and more painful to do sample releases than it is now.
>>>> I'm
>>>> calling -0 at the moment, I'd like to see other opinions as well.
>>>>
>>>>>  ...ant
>>>>
>>>
>>> Consider a hypothetical example:
>>>
>>> Raymond commits a fix for the pass-by-reference enhancements mentioned
>>> earlier this week and really wants to get the fix out in a release for
>>> his users to use.
>>>
>>> Wouldn't it be better to be able to release that right now instead of
>>> having to wait for weeks or months while we tinker about with samples?
>>>
>>>   ...ant
>>>
>>>
>> It depends on who is the audience for the release.
>>
>> 1) If the release is going to be consumed by existing Tuscany users, who
>>   are familiar with the technology and have already developed
>> applications,
>>   these people don't need working samples and would like to get the fix.
>>
>> 2) If the release is going to be consumed by people who are interested
>>   in Tuscany and SCA and are evaluating the technology with a view to
>>   possible adoption, doing a release without samples (or with non-working
>>   samples) is likely to put these people off Tuscany because they won't
>>   be able to understand what it is and how to use it.
>>
>> At this stage I believe that Tuscany/SCA adoption is still in the growth
>> phase and therefore the audience for category 2) should exceed that for
>> category 1).  If not, I would be very concerned.
>>
>> Could we have the best of both worlds by doing "major" and "minor"
>> releases as follows?
>>  major release N: contains samples that work
>>  minor release N.1: fixes to the runtime, without new samples
>>  minor release N.m: as above
>>  major release N+1: adds more samples that work, and functional
>> enhancements
>>  minor release N+1.1: fixes to the runtime, without new samples
>>  minor release N+1.m: as above
>>
>> The N.m designation isn't meant to dictate what the releases are called.
>>
>>  Simon
>>
>
>

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Florian MOGA <mo...@gmail.com>]

I agree with Simon. Cutting releases just to make fixes available for
affected users is definitely something we should do more often. Marking
releases with major and minor sounds like a good way to signal what type of
release it is. It also helps the release review process as we know what to
focus on. I'm +1 for this as I believe it enables us to do more frequent
releases.


On Sat, Feb 5, 2011 at 4:10 PM, Simon Nash <na...@apache.org> wrote:

> ant elder wrote:
>
>> On Sat, Feb 5, 2011 at 10:45 AM, Florian MOGA <mo...@gmail.com> wrote:
>>
>>> On Sat, Feb 5, 2011 at 11:58 AM, ant elder <an...@gmail.com> wrote:
>>>
>>>> Great stuff Florian, thanks for doing that work.
>>>>
>>>> Some of those I know are relatively easy to fix and its just a matter
>>>> of getting around to it.
>>>>
>>> That's right, some of them are trivial, but some are pretty nasty... I'd
>>> consider moving samples like helloworld-js-client-webapp to the
>>> unreleased
>>> folder.
>>>
>>>  I'll try to find some time on it over the
>>>> next days. Some of those don't have unit or integration tests run in
>>>> the build is why they got broken but quite a lot of them do but the
>>>> tests just aren't testing enough or properly.
>>>>
>>>
>>> Talking about unit tests, I've noticed quite a lot of tests marked as
>>> skipped in the maven log... This worries me and I think we should
>>> definitely
>>> revisit them in the next releases.
>>>
>>>> I'm starting to wonder if we should find a new sample approach. An
>>>> issue is presently anyone can add a sample which may or may not have
>>>> doc or tests or work in a standard or unusual way and it gets included
>>>> in the releases and then adds to perceived quality seen by users and
>>>> release reviewers. Because of that what we often do is delay releasing
>>>> until "most" of the samples have been brought up to a reasonable
>>>> consistent standard but thats not perfect as it slows down releases
>>>> and theres still usually some samples that don't work normally and
>>>> without doc which users to find a get confused about.
>>>>
>>> As I've already mentioned on another thread, I think a code review tool
>>> would help a lot achieving more quality in our project. I'd go for no
>>> major
>>> commits without code review but that might not fit everyones taste. It
>>> actually isn't that painful as it sounds. A good percent of the bugs are
>>> found, knowledge is transferred, more filtering / brushing up until
>>> something actually gets in trunk. It might all determine us to write more
>>> quality code, add tests, doc.
>>> I'm also thinking that as we're heading to alpha releases, we need to
>>> 'freeze' the runtime code and do more maintenance releases (samples, unit
>>> tests, documentation). It might not be as fun as doing development in the
>>> runtime code but I'm afraid it is the only way to have a quality 2.0 out.
>>> Last time I heard, we had good oasis compliance, so I think we can afford
>>> doing this. With that in mind, I'd like to propose for the upcoming
>>> releases
>>> to start spinning a new release right after we're done with another one.
>>>
>>>  One thing we could try is releasing the samples separately from the
>>>> main code, a lot of other projects do that, and our SDO releases had
>>>> the samples separate. That would mean we could do much more frequent
>>>> releases of the runtime code as releases wouldn't get held up with
>>>> sample quality issues. Is any one for or against trying something like
>>>> that?
>>>>
>>> I think keeping samples together with the runtime code is a good thing
>>> because it forces us to maintain samples as well :) If we split samples
>>> from
>>> code, I think we're going to run into version mismatch problems and it
>>> will
>>> be much harder and more painful to do sample releases than it is now. I'm
>>> calling -0 at the moment, I'd like to see other opinions as well.
>>>
>>>   ...ant
>>>>
>>>
>>>
>> Consider a hypothetical example:
>>
>> Raymond commits a fix for the pass-by-reference enhancements mentioned
>> earlier this week and really wants to get the fix out in a release for
>> his users to use.
>>
>> Wouldn't it be better to be able to release that right now instead of
>> having to wait for weeks or months while we tinker about with samples?
>>
>>   ...ant
>>
>>
>>  It depends on who is the audience for the release.
>
> 1) If the release is going to be consumed by existing Tuscany users, who
>   are familiar with the technology and have already developed applications,
>   these people don't need working samples and would like to get the fix.
>
> 2) If the release is going to be consumed by people who are interested
>   in Tuscany and SCA and are evaluating the technology with a view to
>   possible adoption, doing a release without samples (or with non-working
>   samples) is likely to put these people off Tuscany because they won't
>   be able to understand what it is and how to use it.
>
> At this stage I believe that Tuscany/SCA adoption is still in the growth
> phase and therefore the audience for category 2) should exceed that for
> category 1).  If not, I would be very concerned.
>
> Could we have the best of both worlds by doing "major" and "minor"
> releases as follows?
>  major release N: contains samples that work
>  minor release N.1: fixes to the runtime, without new samples
>  minor release N.m: as above
>  major release N+1: adds more samples that work, and functional
> enhancements
>  minor release N+1.1: fixes to the runtime, without new samples
>  minor release N+1.m: as above
>
> The N.m designation isn't meant to dictate what the releases are called.
>
>  Simon
>
>

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Nash <na...@apache.org>]

ant elder wrote:
> On Sat, Feb 5, 2011 at 10:45 AM, Florian MOGA <mo...@gmail.com> wrote:
>> On Sat, Feb 5, 2011 at 11:58 AM, ant elder <an...@gmail.com> wrote:
>>> Great stuff Florian, thanks for doing that work.
>>>
>>> Some of those I know are relatively easy to fix and its just a matter
>>> of getting around to it.
>> That's right, some of them are trivial, but some are pretty nasty... I'd
>> consider moving samples like helloworld-js-client-webapp to the unreleased
>> folder.
>>
>>> I'll try to find some time on it over the
>>> next days. Some of those don't have unit or integration tests run in
>>> the build is why they got broken but quite a lot of them do but the
>>> tests just aren't testing enough or properly.
>>
>> Talking about unit tests, I've noticed quite a lot of tests marked as
>> skipped in the maven log... This worries me and I think we should definitely
>> revisit them in the next releases.
>>> I'm starting to wonder if we should find a new sample approach. An
>>> issue is presently anyone can add a sample which may or may not have
>>> doc or tests or work in a standard or unusual way and it gets included
>>> in the releases and then adds to perceived quality seen by users and
>>> release reviewers. Because of that what we often do is delay releasing
>>> until "most" of the samples have been brought up to a reasonable
>>> consistent standard but thats not perfect as it slows down releases
>>> and theres still usually some samples that don't work normally and
>>> without doc which users to find a get confused about.
>> As I've already mentioned on another thread, I think a code review tool
>> would help a lot achieving more quality in our project. I'd go for no major
>> commits without code review but that might not fit everyones taste. It
>> actually isn't that painful as it sounds. A good percent of the bugs are
>> found, knowledge is transferred, more filtering / brushing up until
>> something actually gets in trunk. It might all determine us to write more
>> quality code, add tests, doc.
>> I'm also thinking that as we're heading to alpha releases, we need to
>> 'freeze' the runtime code and do more maintenance releases (samples, unit
>> tests, documentation). It might not be as fun as doing development in the
>> runtime code but I'm afraid it is the only way to have a quality 2.0 out.
>> Last time I heard, we had good oasis compliance, so I think we can afford
>> doing this. With that in mind, I'd like to propose for the upcoming releases
>> to start spinning a new release right after we're done with another one.
>>
>>> One thing we could try is releasing the samples separately from the
>>> main code, a lot of other projects do that, and our SDO releases had
>>> the samples separate. That would mean we could do much more frequent
>>> releases of the runtime code as releases wouldn't get held up with
>>> sample quality issues. Is any one for or against trying something like
>>> that?
>> I think keeping samples together with the runtime code is a good thing
>> because it forces us to maintain samples as well :) If we split samples from
>> code, I think we're going to run into version mismatch problems and it will
>> be much harder and more painful to do sample releases than it is now. I'm
>> calling -0 at the moment, I'd like to see other opinions as well.
>>
>>>   ...ant
>>
> 
> Consider a hypothetical example:
> 
> Raymond commits a fix for the pass-by-reference enhancements mentioned
> earlier this week and really wants to get the fix out in a release for
> his users to use.
> 
> Wouldn't it be better to be able to release that right now instead of
> having to wait for weeks or months while we tinker about with samples?
> 
>    ...ant
> 
> 
It depends on who is the audience for the release.

1) If the release is going to be consumed by existing Tuscany users, who
    are familiar with the technology and have already developed applications,
    these people don't need working samples and would like to get the fix.

2) If the release is going to be consumed by people who are interested
    in Tuscany and SCA and are evaluating the technology with a view to
    possible adoption, doing a release without samples (or with non-working
    samples) is likely to put these people off Tuscany because they won't
    be able to understand what it is and how to use it.

At this stage I believe that Tuscany/SCA adoption is still in the growth
phase and therefore the audience for category 2) should exceed that for
category 1).  If not, I would be very concerned.

Could we have the best of both worlds by doing "major" and "minor"
releases as follows?
  major release N: contains samples that work
  minor release N.1: fixes to the runtime, without new samples
  minor release N.m: as above
  major release N+1: adds more samples that work, and functional enhancements
  minor release N+1.1: fixes to the runtime, without new samples
  minor release N+1.m: as above

The N.m designation isn't meant to dictate what the releases are called.

   Simon

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@apache.org>]

On Sat, Feb 5, 2011 at 10:45 AM, Florian MOGA <mo...@gmail.com> wrote:
> On Sat, Feb 5, 2011 at 11:58 AM, ant elder <an...@gmail.com> wrote:
>>
>> Great stuff Florian, thanks for doing that work.
>>
>> Some of those I know are relatively easy to fix and its just a matter
>> of getting around to it.
>
> That's right, some of them are trivial, but some are pretty nasty... I'd
> consider moving samples like helloworld-js-client-webapp to the unreleased
> folder.
>
>>
>> I'll try to find some time on it over the
>> next days. Some of those don't have unit or integration tests run in
>> the build is why they got broken but quite a lot of them do but the
>> tests just aren't testing enough or properly.
>
>
> Talking about unit tests, I've noticed quite a lot of tests marked as
> skipped in the maven log... This worries me and I think we should definitely
> revisit them in the next releases.
>>
>> I'm starting to wonder if we should find a new sample approach. An
>> issue is presently anyone can add a sample which may or may not have
>> doc or tests or work in a standard or unusual way and it gets included
>> in the releases and then adds to perceived quality seen by users and
>> release reviewers. Because of that what we often do is delay releasing
>> until "most" of the samples have been brought up to a reasonable
>> consistent standard but thats not perfect as it slows down releases
>> and theres still usually some samples that don't work normally and
>> without doc which users to find a get confused about.
>
> As I've already mentioned on another thread, I think a code review tool
> would help a lot achieving more quality in our project. I'd go for no major
> commits without code review but that might not fit everyones taste. It
> actually isn't that painful as it sounds. A good percent of the bugs are
> found, knowledge is transferred, more filtering / brushing up until
> something actually gets in trunk. It might all determine us to write more
> quality code, add tests, doc.
> I'm also thinking that as we're heading to alpha releases, we need to
> 'freeze' the runtime code and do more maintenance releases (samples, unit
> tests, documentation). It might not be as fun as doing development in the
> runtime code but I'm afraid it is the only way to have a quality 2.0 out.
> Last time I heard, we had good oasis compliance, so I think we can afford
> doing this. With that in mind, I'd like to propose for the upcoming releases
> to start spinning a new release right after we're done with another one.
>
>>
>> One thing we could try is releasing the samples separately from the
>> main code, a lot of other projects do that, and our SDO releases had
>> the samples separate. That would mean we could do much more frequent
>> releases of the runtime code as releases wouldn't get held up with
>> sample quality issues. Is any one for or against trying something like
>> that?
>
> I think keeping samples together with the runtime code is a good thing
> because it forces us to maintain samples as well :) If we split samples from
> code, I think we're going to run into version mismatch problems and it will
> be much harder and more painful to do sample releases than it is now. I'm
> calling -0 at the moment, I'd like to see other opinions as well.
>
>>
>>   ...ant
>
>

Consider a hypothetical example:

Raymond commits a fix for the pass-by-reference enhancements mentioned
earlier this week and really wants to get the fix out in a release for
his users to use.

Wouldn't it be better to be able to release that right now instead of
having to wait for weeks or months while we tinker about with samples?

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Florian MOGA <mo...@gmail.com>]

On Sat, Feb 5, 2011 at 11:58 AM, ant elder <an...@gmail.com> wrote:

>
> Great stuff Florian, thanks for doing that work.
>
> Some of those I know are relatively easy to fix and its just a matter
> of getting around to it.


That's right, some of them are trivial, but some are pretty nasty... I'd
consider moving samples like helloworld-js-client-webapp to the unreleased
folder.


> I'll try to find some time on it over the
> next days. Some of those don't have unit or integration tests run in
> the build is why they got broken but quite a lot of them do but the
> tests just aren't testing enough or properly.
>

Talking about unit tests, I've noticed quite a lot of tests marked as
skipped in the maven log... This worries me and I think we should definitely
revisit them in the next releases.

I'm starting to wonder if we should find a new sample approach. An
> issue is presently anyone can add a sample which may or may not have
> doc or tests or work in a standard or unusual way and it gets included
> in the releases and then adds to perceived quality seen by users and
> release reviewers. Because of that what we often do is delay releasing
> until "most" of the samples have been brought up to a reasonable
> consistent standard but thats not perfect as it slows down releases
> and theres still usually some samples that don't work normally and
> without doc which users to find a get confused about.


As I've already mentioned on another thread, I think a code review tool
would help a lot achieving more quality in our project. I'd go for no major
commits without code review but that might not fit everyones taste. It
actually isn't that painful as it sounds. A good percent of the bugs are
found, knowledge is transferred, more filtering / brushing up until
something actually gets in trunk. It might all determine us to write more
quality code, add tests, doc.

I'm also thinking that as we're heading to alpha releases, we need to
'freeze' the runtime code and do more maintenance releases (samples, unit
tests, documentation). It might not be as fun as doing development in the
runtime code but I'm afraid it is the only way to have a quality 2.0 out.
Last time I heard, we had good oasis compliance, so I think we can afford
doing this. With that in mind, I'd like to propose for the upcoming releases
to start spinning a new release right after we're done with another one.


> One thing we could try is releasing the samples separately from the
> main code, a lot of other projects do that, and our SDO releases had
> the samples separate. That would mean we could do much more frequent
> releases of the runtime code as releases wouldn't get held up with
> sample quality issues. Is any one for or against trying something like
> that?
>

I think keeping samples together with the runtime code is a good thing
because it forces us to maintain samples as well :) If we split samples from
code, I think we're going to run into version mismatch problems and it will
be much harder and more painful to do sample releases than it is now. I'm
calling -0 at the moment, I'd like to see other opinions as well.


>   ...ant
>

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder <an...@gmail.com>]

On Fri, Feb 4, 2011 at 10:36 AM, Florian MOGA <mo...@gmail.com> wrote:
> Hi,
> I've decided to open a separate thread for this discussion as this topic is
> big enough. I've tried all the samples from 2.0-beta2 rc2 and here are my
> findings:
> - sample-scdl-include-contribution (fails to load contribution when using
> mvn tuscany:run, is there another way to start the runtime for this sample?)
> - sample-dosgi-calculator-operations (org.osgi.framework.BundleException:
> The bundle could not be resolved.)
> - sample-dosgi-dynamic-calculator-operations
> (org.osgi.framework.BundleException: The bundle could not be resolved.)
> - sample-implementation-bpel-contribution (fails to load contribution when
> using mvn tuscany:run, is there another way to start the runtime for this
> sample?)
> - sample-implementation-bpel-webapp ("Cant find BPEL Process" at startup)
> - sample-implementation-composite-helloworld-contribution
> (java.lang.IllegalArgumentException: Contribution not found as file or
> dependency: ..\helloworld\target\sample-helloworld.jar)
> - sample-implementation-composite-helloworld-ws-contribution
> (java.lang.IllegalArgumentException: Contribution not found as file or
> dependency: ..\helloworld-recursive\target\sample-helloworld-recursive.jar)
> - sample-implementation-java-calculator-async-contribution (Caused by:
> org.xml.sax.SAXParseException; systemId: http://calculator/; lineNumber: 2;
> columnNumber: 132; The value of the attribute
> "prefix="xmlns",localpart="ns4",rawname="xmlns:ns4"" is invalid. Prefixed
> namespace bindings may not be empty.)
> - sample-implementation-script-calculator(Caused by:
> java.lang.IllegalStateException: Provider factory not found for class:
> org.apache.tuscany.sca.implementation.script.impl.ScriptImplementationImpl)
> - sample-implementation-spring-helloworld-webapp (fails at startup)
> - sample-implementation-web-helloworld-js-client-webapp (functionality
> broken)
> - sample-implementation-web-helloworld-jsf-webapp (functionality broken)
> - sample-sca-client-calculator(Caused by: java.lang.IllegalStateException:
> Provider factory not found for class:
> org.apache.tuscany.sca.implementation.script.impl.ScriptImplementationImpl)
> - sample-sca-client-helloworld (Caused by: java.lang.IllegalStateException:
> Provider factory not found for class:
> org.apache.tuscany.sca.implementation.script.impl.ScriptImplementationImpl)
> - shell (scripts don't load successfully)
> - maven-osgi-junit (exceptions in junit log)
> - sample-store (tests pass but when using Launch.java ->
> ClassNotFoundException)
> - feed in sample-store-webapp returns 404
> - eightball-webapp (when clicking Ask returns 500)
> There are samples that don't have Java classes or unit tests as launchers so
> I've started them using mvn tuscany:run. Let me know if those samples
> should've been launched differently.
> How should we approach all those issues? It might worth having the
> discussion about the consistent way of running samples now and applying
> changes along with fixing the samples. Same with documentation.
> Florian
>

Great stuff Florian, thanks for doing that work.

Some of those I know are relatively easy to fix and its just a matter
of getting around to it. I'll try to find some time on it over the
next days. Some of those don't have unit or integration tests run in
the build is why they got broken but quite a lot of them do but the
tests just aren't testing enough or properly.

I'm starting to wonder if we should find a new sample approach. An
issue is presently anyone can add a sample which may or may not have
doc or tests or work in a standard or unusual way and it gets included
in the releases and then adds to perceived quality seen by users and
release reviewers. Because of that what we often do is delay releasing
until "most" of the samples have been brought up to a reasonable
consistent standard but thats not perfect as it slows down releases
and theres still usually some samples that don't work normally and
without doc which users to find a get confused about.

One thing we could try is releasing the samples separately from the
main code, a lot of other projects do that, and our SDO releases had
the samples separate. That would mean we could do much more frequent
releases of the runtime code as releases wouldn't get held up with
sample quality issues. Is any one for or against trying something like
that?

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Florian MOGA <mo...@gmail.com>]

Deciding how to launch samples is tricky. If we're trying to sort out which
is the easiest way to fire up the runtime, probably the tuscany maven plugin
and the shell have an advantage. However, I think we should take into
consideration the fact that probably the first step that users do with a
sample is to import it in their favorite IDE (me included) so they can look
at the code. In this situation, a class or a unit test that starts the
runtime is often more useful than leaving the IDE and launching the sample
with an external tool.


On Fri, Feb 4, 2011 at 12:57 PM, Simon Laws <si...@googlemail.com>wrote:

> On Fri, Feb 4, 2011 at 10:36 AM, Florian MOGA <mo...@gmail.com> wrote:
> > Hi,
> > I've decided to open a separate thread for this discussion as this topic
> is
> > big enough. I've tried all the samples from 2.0-beta2 rc2 and here are my
> > findings:
> > - sample-scdl-include-contribution (fails to load contribution when using
> > mvn tuscany:run, is there another way to start the runtime for this
> sample?)
> > - sample-dosgi-calculator-operations (org.osgi.framework.BundleException:
> > The bundle could not be resolved.)
> > - sample-dosgi-dynamic-calculator-operations
> > (org.osgi.framework.BundleException: The bundle could not be resolved.)
> > - sample-implementation-bpel-contribution (fails to load contribution
> when
> > using mvn tuscany:run, is there another way to start the runtime for this
> > sample?)
> > - sample-implementation-bpel-webapp ("Cant find BPEL Process" at startup)
> > - sample-implementation-composite-helloworld-contribution
> > (java.lang.IllegalArgumentException: Contribution not found as file or
> > dependency: ..\helloworld\target\sample-helloworld.jar)
> > - sample-implementation-composite-helloworld-ws-contribution
> > (java.lang.IllegalArgumentException: Contribution not found as file or
> > dependency:
> ..\helloworld-recursive\target\sample-helloworld-recursive.jar)
> > - sample-implementation-java-calculator-async-contribution (Caused by:
> > org.xml.sax.SAXParseException; systemId: http://calculator/; lineNumber:
> 2;
> > columnNumber: 132; The value of the attribute
> > "prefix="xmlns",localpart="ns4",rawname="xmlns:ns4"" is invalid. Prefixed
> > namespace bindings may not be empty.)
> > - sample-implementation-script-calculator(Caused by:
> > java.lang.IllegalStateException: Provider factory not found for class:
> >
> org.apache.tuscany.sca.implementation.script.impl.ScriptImplementationImpl)
> > - sample-implementation-spring-helloworld-webapp (fails at startup)
> > - sample-implementation-web-helloworld-js-client-webapp (functionality
> > broken)
> > - sample-implementation-web-helloworld-jsf-webapp (functionality broken)
> > - sample-sca-client-calculator(Caused by:
> java.lang.IllegalStateException:
> > Provider factory not found for class:
> >
> org.apache.tuscany.sca.implementation.script.impl.ScriptImplementationImpl)
> > - sample-sca-client-helloworld (Caused by:
> java.lang.IllegalStateException:
> > Provider factory not found for class:
> >
> org.apache.tuscany.sca.implementation.script.impl.ScriptImplementationImpl)
> > - shell (scripts don't load successfully)
> > - maven-osgi-junit (exceptions in junit log)
> > - sample-store (tests pass but when using Launch.java ->
> > ClassNotFoundException)
> > - feed in sample-store-webapp returns 404
> > - eightball-webapp (when clicking Ask returns 500)
> > There are samples that don't have Java classes or unit tests as launchers
> so
> > I've started them using mvn tuscany:run. Let me know if those samples
> > should've been launched differently.
> > How should we approach all those issues? It might worth having the
> > discussion about the consistent way of running samples now and applying
> > changes along with fixing the samples. Same with documentation.
> > Florian
> >
>
> Hi Florian
>
> Thanks for kicking this off.
>
> I think we need to decide what, for each type of sample, is our
> default launch mechanism. There are numerous different mechanisms in
> samples/running-tuscany but we need to pick something that will be
> obvious and easy to use for the first time user.
>
> There are different types of samples we have included
>
>  jar/zip standalone contributions (in some cases more than one
> contribution has to be run)
> contributions that must be run and then accessed by an SCA or Tuscany
> client
> contributions wrapped in a war
> contribution bundles (that expect to be run in an OSGi environment)
>
> There are probably some I've missed.
>
> Typically we've provided maven and ant scripts in the past. However we
> now have the new shell stuff and mvn plugins that can do some of the
> work. I wouldn't advocate removing any of these options but, for each
> type of sample, we should pick a simple default approach that we can
> easily document.
>
> IMHO, having tried it, documenting multiple approaches for each sample
> is hard work and makes the sample doc look complicated.
>
> I'll have  a play with the options we have now to see which one I like
> in each situation. If others can do the same we can discuss.
>
> Simon
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Laws <si...@googlemail.com>]

On Fri, Feb 4, 2011 at 10:36 AM, Florian MOGA <mo...@gmail.com> wrote:
> Hi,
> I've decided to open a separate thread for this discussion as this topic is
> big enough. I've tried all the samples from 2.0-beta2 rc2 and here are my
> findings:
> - sample-scdl-include-contribution (fails to load contribution when using
> mvn tuscany:run, is there another way to start the runtime for this sample?)
> - sample-dosgi-calculator-operations (org.osgi.framework.BundleException:
> The bundle could not be resolved.)
> - sample-dosgi-dynamic-calculator-operations
> (org.osgi.framework.BundleException: The bundle could not be resolved.)
> - sample-implementation-bpel-contribution (fails to load contribution when
> using mvn tuscany:run, is there another way to start the runtime for this
> sample?)
> - sample-implementation-bpel-webapp ("Cant find BPEL Process" at startup)
> - sample-implementation-composite-helloworld-contribution
> (java.lang.IllegalArgumentException: Contribution not found as file or
> dependency: ..\helloworld\target\sample-helloworld.jar)
> - sample-implementation-composite-helloworld-ws-contribution
> (java.lang.IllegalArgumentException: Contribution not found as file or
> dependency: ..\helloworld-recursive\target\sample-helloworld-recursive.jar)
> - sample-implementation-java-calculator-async-contribution (Caused by:
> org.xml.sax.SAXParseException; systemId: http://calculator/; lineNumber: 2;
> columnNumber: 132; The value of the attribute
> "prefix="xmlns",localpart="ns4",rawname="xmlns:ns4"" is invalid. Prefixed
> namespace bindings may not be empty.)
> - sample-implementation-script-calculator(Caused by:
> java.lang.IllegalStateException: Provider factory not found for class:
> org.apache.tuscany.sca.implementation.script.impl.ScriptImplementationImpl)
> - sample-implementation-spring-helloworld-webapp (fails at startup)
> - sample-implementation-web-helloworld-js-client-webapp (functionality
> broken)
> - sample-implementation-web-helloworld-jsf-webapp (functionality broken)
> - sample-sca-client-calculator(Caused by: java.lang.IllegalStateException:
> Provider factory not found for class:
> org.apache.tuscany.sca.implementation.script.impl.ScriptImplementationImpl)
> - sample-sca-client-helloworld (Caused by: java.lang.IllegalStateException:
> Provider factory not found for class:
> org.apache.tuscany.sca.implementation.script.impl.ScriptImplementationImpl)
> - shell (scripts don't load successfully)
> - maven-osgi-junit (exceptions in junit log)
> - sample-store (tests pass but when using Launch.java ->
> ClassNotFoundException)
> - feed in sample-store-webapp returns 404
> - eightball-webapp (when clicking Ask returns 500)
> There are samples that don't have Java classes or unit tests as launchers so
> I've started them using mvn tuscany:run. Let me know if those samples
> should've been launched differently.
> How should we approach all those issues? It might worth having the
> discussion about the consistent way of running samples now and applying
> changes along with fixing the samples. Same with documentation.
> Florian
>

Hi Florian

Thanks for kicking this off.

I think we need to decide what, for each type of sample, is our
default launch mechanism. There are numerous different mechanisms in
samples/running-tuscany but we need to pick something that will be
obvious and easy to use for the first time user.

There are different types of samples we have included

 jar/zip standalone contributions (in some cases more than one
contribution has to be run)
contributions that must be run and then accessed by an SCA or Tuscany client
contributions wrapped in a war
contribution bundles (that expect to be run in an OSGi environment)

There are probably some I've missed.

Typically we've provided maven and ant scripts in the past. However we
now have the new shell stuff and mvn plugins that can do some of the
work. I wouldn't advocate removing any of these options but, for each
type of sample, we should pick a simple default approach that we can
easily document.

IMHO, having tried it, documenting multiple approaches for each sample
is hard work and makes the sample doc look complicated.

I'll have  a play with the options we have now to see which one I like
in each situation. If others can do the same we can discuss.

Simon
-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com