You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Nash <na...@hursley.ibm.com> on 2006/10/04 19:45:59 UTC
SCA Java samples for M2
I'm planning to go through all the SCA Java samples, building them
and runnning them, to make sure that they work. We also need to
consider whether this is the right set of samples to introduce
users to the capabilities of SCA and Tuscany.
Right now we have the following in the samples/sca directory.
Samples that are currently building:
bigbank
calculator
eagerinit
echo.binding
echo.databinding
helloworldJavaScript
helloworldws
helloworldws-celtix
helloworldwsclient
local.wire
local.wire.cdi
spring.simple
supplychain
webapp
Samples that are not currently building:
helloworld.rmiReference
helloworld.rmiService
helloworldjsonrpc
helloworldwsclientOM
helloworldwsOM
inner.composite
simplecallback
spring
For a first pass I would assume that we are intending to deliver the
former list in our M2 binary release but not the latter. Is this
a correct assumption? Should any of the "not building" samples be
included? Should any of the "building" samples be excluded?
Should we be adding any more samples that are currently not in
either list?
From a quick look through these lists, I have the following questions.
1. It is my understanding that we are including RMI, so presumably
we need the RMI samples.
2. It is my understanding that we are not including celtix in the
binary release, so presumably we don't need the celtix sample.
3. I don't know whether we will be including Spring, so I'm not
whether we will need the spring.simple sample.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Simon,
I shall get the RMI samples up by tomorrow for sure.
Thanks
- Venkat
On 10/4/06, Andy Piper <an...@bea.com> wrote:
>
> At 18:45 04/10/2006, Simon Nash wrote:
> >3. I don't know whether we will be including Spring, so I'm not
> > whether we will need the spring.simple sample.
>
> I have this sample fixed. I'm working with Ken on getting it submitted
>
> andy
>
> _______________________________________________________________________
> Notice: This email message, together with any attachments, may contain
> information of BEA Systems, Inc., its subsidiaries and affiliated
> entities, that may be confidential, proprietary, copyrighted and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: SCA Java samples for M2
Posted by Andy Piper <an...@bea.com>.
At 18:45 04/10/2006, Simon Nash wrote:
>3. I don't know whether we will be including Spring, so I'm not
> whether we will need the spring.simple sample.
I have this sample fixed. I'm working with Ken on getting it submitted
andy
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi...
I have posted a patch on the JIRA to fix the RMI samples. Now they must
work with the current state of the Standalone.
http://issues.apache.org/jira/browse/TUSCANY-799
Thanks
- Venkat
On 10/5/06, ant elder <an...@gmail.com> wrote:
>
> There was a discussion on the samples a while back [1] where i think there
> was some agreement to restructure the samples based on the extension they
> are demonstrating. It wasn't so clear what the out come of that discussion
> was so how about the following (for now ignoring whats
> in/out/works/broken):
>
> sampleapps/bigbank
> bigbank
>
> samples/echo
> - echo.binding
> - echo.databinding
>
> samples/javascript
> helloworld
>
> samples/axis2
> helloworldws
> helloworldwsclient
> helloworldwsclientOM
> helloworldwsOM
>
> samples/celtix
> helloworldws-celtix
>
> samples/spring
> spring.simple
> spring
>
> samples/rmi
> helloworld.rmiReference
> helloworld.rmiService
>
> samples/jsonrpc
> helloworldjsonrpc
>
> samples/java?
> calculator
> eagerinit
> inner.composite
> local.wire
> local.wire.cdi
> simplecallback
> supplychain
> webapp
>
> In the same thread there was the suggestion about using a calculator
> sample
> instead of or as well as helloworld so I'll also add a javascript
> calculator
> sample and look at doing both for the other script languages as well.
>
> If we can reach some consensus about what this should look like I can do
> the
> changes.
>
> ...ant
>
> [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06572.html
>
> On 10/4/06, Simon Nash <na...@hursley.ibm.com> wrote:
> >
> > I'm planning to go through all the SCA Java samples, building them
> > and runnning them, to make sure that they work. We also need to
> > consider whether this is the right set of samples to introduce
> > users to the capabilities of SCA and Tuscany.
> >
> > Right now we have the following in the samples/sca directory.
> >
> > Samples that are currently building:
> > bigbank
> > calculator
> > eagerinit
> > echo.binding
> > echo.databinding
> > helloworldJavaScript
> > helloworldws
> > helloworldws-celtix
> > helloworldwsclient
> > local.wire
> > local.wire.cdi
> > spring.simple
> > supplychain
> > webapp
> >
> > Samples that are not currently building:
> > helloworld.rmiReference
> > helloworld.rmiService
> > helloworldjsonrpc
> > helloworldwsclientOM
> > helloworldwsOM
> > inner.composite
> > simplecallback
> > spring
> >
> > For a first pass I would assume that we are intending to deliver the
> > former list in our M2 binary release but not the latter. Is this
> > a correct assumption? Should any of the "not building" samples be
> > included? Should any of the "building" samples be excluded?
> > Should we be adding any more samples that are currently not in
> > either list?
> >
> > From a quick look through these lists, I have the following questions.
> >
> > 1. It is my understanding that we are including RMI, so presumably
> > we need the RMI samples.
> >
> > 2. It is my understanding that we are not including celtix in the
> > binary release, so presumably we don't need the celtix sample.
> >
> > 3. I don't know whether we will be including Spring, so I'm not
> > whether we will need the spring.simple sample.
> >
> > Simon
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
Re: SCA Java samples for M2
Posted by Jeremy Boynes <jb...@apache.org>.
On Oct 5, 2006, at 7:14 AM, ant elder wrote:
> On 10/5/06, Jeremy Boynes <jb...@apache.org> wrote:
>>
>> I think organizing the samples like this is a good idea. I'd suggest
>> going one step further and place each sample with the implementation
>> of the service that it is illustrating. That way it becomes much
>> easier to tag/release each module on its own.
>
>
> I'm not sure I follow "place each sample with the implementation of
> the
> service that it is illustrating" , do you mean something like:
>
> samples/helloworld/java
> samples/helloworld/javascript
> samples/calculator/java
> samples/calculator/javascript
>
> Or do you mean include them with the extension so the JavaScript
> folder
> would include samples/helloworld and samples/calculator? I didn't
> think Jim
> liked this way, from the previous thread - "In other words, each
> sample
> project should not be a sibling to the project containing extension
> code but
> should go under a samples folder in separate projects".
Yes, I mean moving the samples into (e.g.) the Javascript folder so
that JavaScript becomes a standalone module that can be treated as a
single item when it comes to building/releasing. We've seen from sdo
and das that grouping things in that way makes this much much easier.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi...
Yes this makes sense to me.
- Venkat
where I'd like to put component implementations
On 10/6/06, ant elder <an...@gmail.com> wrote:
>
> Ok I think we're getting some agreement but I'd like to be clear everyone
> agrees and is happy before I make any changes. Sounds like for things like
> the Groovy/JavaScript/etc helloworld and calculator type samples they
> would
> go with the extension, I'm guessing samples that use just sca and java
> would
> go in an sca/samples directory. Samples that use multiple extensions but
> still just SCA would also go in the sca/samples directory, and there'd be
> a
> top level samples directory for things like bigbank that use sca/sdo/das.
>
> So:
>
> samples/bingbank
> das/samples/companyweb
> sca/samples/calculator
> sca/services/containers/container.javascript/src/samples/calculator
>
> Comments?
>
> ...ant
>
> On 10/5/06, Jim Marino <jm...@myromatours.com> wrote:
> >
> >
> > On Oct 5, 2006, at 7:14 AM, ant elder wrote:
> >
> > > On 10/5/06, Jeremy Boynes <jb...@apache.org> wrote:
> > >>
> > >> I think organizing the samples like this is a good idea. I'd suggest
> > >> going one step further and place each sample with the implementation
> > >> of the service that it is illustrating. That way it becomes much
> > >> easier to tag/release each module on its own.
> > >
> > >
> > > I'm not sure I follow "place each sample with the implementation of
> > > the
> > > service that it is illustrating" , do you mean something like:
> > >
> > > samples/helloworld/java
> > > samples/helloworld/javascript
> > > samples/calculator/java
> > > samples/calculator/javascript
> > >
> > > Or do you mean include them with the extension so the JavaScript
> > > folder
> > > would include samples/helloworld and samples/calculator? I didn't
> > > think Jim
> > > liked this way, from the previous thread - "In other words, each
> > > sample
> > > project should not be a sibling to the project containing extension
> > > code but
> > > should go under a samples folder in separate projects".
> > I was thinking samples for particular extensions would go under the
> > particular extension's directory. For samples that used multiple
> > extensions, they would go under the master samples folder. I liked
> > what was done with the calculator where stuff is shared between
> > projects (component reuse) so if that structuring won't work for re-
> > use I would be fine with what Ant just outlined. My preference,
> > though, would be to group samples with individual extensions.
> >
> > Jim
> >
> > >
> > > ...ant
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
Re: SCA Java samples for M2
Posted by Ken Tam <ke...@gmail.com>.
Right -- I was just elaborating on Jeremy's earlier statement re: one
motivation for packing extension-specific samples with the extensions
themselves:
On 10/5/06, Jeremy Boynes <jb...@apache.org> wrote:
>I think organizing the samples like this is a good idea. I'd suggest
>going one step further and place each sample with the implementation
>of the service that it is illustrating. That way it becomes much
>easier to tag/release each module on its own.
and pointing out that the existence of samples using multiple
extensions inherently complicates (though not ruling out) scenarios
like tagging/releasing extension modules separately.
On 10/6/06, Simon Nash <na...@hursley.ibm.com> wrote:
> Ken,
> I don't think the existence of a sample that uses multiple extensions
> restricts the ability to work with those extensions separately. It is
> true that anyone wanting to work with just one of the extensions will
> be unable to use the multi-extension sample, but they can still use the
> extension. I believe the requirement is that every extension should
> have samples that don't require the use of other extensions as well.
>
> Simon
>
> Ken Tam wrote:
>
> > +1.
> >
> > It sounds like we still have an issue wrt samples that use multiple
> > extensions (in that the existence of such samples restricts the
> > ability to separately work with those extensions), but I'm fine with
> > not addressing that now.
> >
> > On 10/6/06, ant elder <an...@gmail.com> wrote:
> >
> >> Ok I think we're getting some agreement but I'd like to be clear everyone
> >> agrees and is happy before I make any changes. Sounds like for things
> >> like
> >> the Groovy/JavaScript/etc helloworld and calculator type samples they
> >> would
> >> go with the extension, I'm guessing samples that use just sca and java
> >> would
> >> go in an sca/samples directory. Samples that use multiple extensions but
> >> still just SCA would also go in the sca/samples directory, and there'd
> >> be a
> >> top level samples directory for things like bigbank that use sca/sdo/das.
> >>
> >> So:
> >>
> >> samples/bingbank
> >> das/samples/companyweb
> >> sca/samples/calculator
> >> sca/services/containers/container.javascript/src/samples/calculator
> >>
> >> Comments?
> >>
> >> ...ant
> >>
> >> On 10/5/06, Jim Marino <jm...@myromatours.com> wrote:
> >> >
> >> >
> >> > On Oct 5, 2006, at 7:14 AM, ant elder wrote:
> >> >
> >> > > On 10/5/06, Jeremy Boynes <jb...@apache.org> wrote:
> >> > >>
> >> > >> I think organizing the samples like this is a good idea. I'd suggest
> >> > >> going one step further and place each sample with the implementation
> >> > >> of the service that it is illustrating. That way it becomes much
> >> > >> easier to tag/release each module on its own.
> >> > >
> >> > >
> >> > > I'm not sure I follow "place each sample with the implementation of
> >> > > the
> >> > > service that it is illustrating" , do you mean something like:
> >> > >
> >> > > samples/helloworld/java
> >> > > samples/helloworld/javascript
> >> > > samples/calculator/java
> >> > > samples/calculator/javascript
> >> > >
> >> > > Or do you mean include them with the extension so the JavaScript
> >> > > folder
> >> > > would include samples/helloworld and samples/calculator? I didn't
> >> > > think Jim
> >> > > liked this way, from the previous thread - "In other words, each
> >> > > sample
> >> > > project should not be a sibling to the project containing extension
> >> > > code but
> >> > > should go under a samples folder in separate projects".
> >> > I was thinking samples for particular extensions would go under the
> >> > particular extension's directory. For samples that used multiple
> >> > extensions, they would go under the master samples folder. I liked
> >> > what was done with the calculator where stuff is shared between
> >> > projects (component reuse) so if that structuring won't work for re-
> >> > use I would be fine with what Ant just outlined. My preference,
> >> > though, would be to group samples with individual extensions.
> >> >
> >> > Jim
> >> >
> >> > >
> >> > > ...ant
> >> >
> >> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by Simon Nash <na...@hursley.ibm.com>.
Ken,
I don't think the existence of a sample that uses multiple extensions
restricts the ability to work with those extensions separately. It is
true that anyone wanting to work with just one of the extensions will
be unable to use the multi-extension sample, but they can still use the
extension. I believe the requirement is that every extension should
have samples that don't require the use of other extensions as well.
Simon
Ken Tam wrote:
> +1.
>
> It sounds like we still have an issue wrt samples that use multiple
> extensions (in that the existence of such samples restricts the
> ability to separately work with those extensions), but I'm fine with
> not addressing that now.
>
> On 10/6/06, ant elder <an...@gmail.com> wrote:
>
>> Ok I think we're getting some agreement but I'd like to be clear everyone
>> agrees and is happy before I make any changes. Sounds like for things
>> like
>> the Groovy/JavaScript/etc helloworld and calculator type samples they
>> would
>> go with the extension, I'm guessing samples that use just sca and java
>> would
>> go in an sca/samples directory. Samples that use multiple extensions but
>> still just SCA would also go in the sca/samples directory, and there'd
>> be a
>> top level samples directory for things like bigbank that use sca/sdo/das.
>>
>> So:
>>
>> samples/bingbank
>> das/samples/companyweb
>> sca/samples/calculator
>> sca/services/containers/container.javascript/src/samples/calculator
>>
>> Comments?
>>
>> ...ant
>>
>> On 10/5/06, Jim Marino <jm...@myromatours.com> wrote:
>> >
>> >
>> > On Oct 5, 2006, at 7:14 AM, ant elder wrote:
>> >
>> > > On 10/5/06, Jeremy Boynes <jb...@apache.org> wrote:
>> > >>
>> > >> I think organizing the samples like this is a good idea. I'd suggest
>> > >> going one step further and place each sample with the implementation
>> > >> of the service that it is illustrating. That way it becomes much
>> > >> easier to tag/release each module on its own.
>> > >
>> > >
>> > > I'm not sure I follow "place each sample with the implementation of
>> > > the
>> > > service that it is illustrating" , do you mean something like:
>> > >
>> > > samples/helloworld/java
>> > > samples/helloworld/javascript
>> > > samples/calculator/java
>> > > samples/calculator/javascript
>> > >
>> > > Or do you mean include them with the extension so the JavaScript
>> > > folder
>> > > would include samples/helloworld and samples/calculator? I didn't
>> > > think Jim
>> > > liked this way, from the previous thread - "In other words, each
>> > > sample
>> > > project should not be a sibling to the project containing extension
>> > > code but
>> > > should go under a samples folder in separate projects".
>> > I was thinking samples for particular extensions would go under the
>> > particular extension's directory. For samples that used multiple
>> > extensions, they would go under the master samples folder. I liked
>> > what was done with the calculator where stuff is shared between
>> > projects (component reuse) so if that structuring won't work for re-
>> > use I would be fine with what Ant just outlined. My preference,
>> > though, would be to group samples with individual extensions.
>> >
>> > Jim
>> >
>> > >
>> > > ...ant
>> >
>> >
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by Ken Tam <ke...@gmail.com>.
+1.
It sounds like we still have an issue wrt samples that use multiple
extensions (in that the existence of such samples restricts the
ability to separately work with those extensions), but I'm fine with
not addressing that now.
On 10/6/06, ant elder <an...@gmail.com> wrote:
> Ok I think we're getting some agreement but I'd like to be clear everyone
> agrees and is happy before I make any changes. Sounds like for things like
> the Groovy/JavaScript/etc helloworld and calculator type samples they would
> go with the extension, I'm guessing samples that use just sca and java would
> go in an sca/samples directory. Samples that use multiple extensions but
> still just SCA would also go in the sca/samples directory, and there'd be a
> top level samples directory for things like bigbank that use sca/sdo/das.
>
> So:
>
> samples/bingbank
> das/samples/companyweb
> sca/samples/calculator
> sca/services/containers/container.javascript/src/samples/calculator
>
> Comments?
>
> ...ant
>
> On 10/5/06, Jim Marino <jm...@myromatours.com> wrote:
> >
> >
> > On Oct 5, 2006, at 7:14 AM, ant elder wrote:
> >
> > > On 10/5/06, Jeremy Boynes <jb...@apache.org> wrote:
> > >>
> > >> I think organizing the samples like this is a good idea. I'd suggest
> > >> going one step further and place each sample with the implementation
> > >> of the service that it is illustrating. That way it becomes much
> > >> easier to tag/release each module on its own.
> > >
> > >
> > > I'm not sure I follow "place each sample with the implementation of
> > > the
> > > service that it is illustrating" , do you mean something like:
> > >
> > > samples/helloworld/java
> > > samples/helloworld/javascript
> > > samples/calculator/java
> > > samples/calculator/javascript
> > >
> > > Or do you mean include them with the extension so the JavaScript
> > > folder
> > > would include samples/helloworld and samples/calculator? I didn't
> > > think Jim
> > > liked this way, from the previous thread - "In other words, each
> > > sample
> > > project should not be a sibling to the project containing extension
> > > code but
> > > should go under a samples folder in separate projects".
> > I was thinking samples for particular extensions would go under the
> > particular extension's directory. For samples that used multiple
> > extensions, they would go under the master samples folder. I liked
> > what was done with the calculator where stuff is shared between
> > projects (component reuse) so if that structuring won't work for re-
> > use I would be fine with what Ant just outlined. My preference,
> > though, would be to group samples with individual extensions.
> >
> > Jim
> >
> > >
> > > ...ant
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by Jeremy Boynes <jb...@apache.org>.
On Oct 6, 2006, at 1:57 AM, ant elder wrote:
> Ok I think we're getting some agreement but I'd like to be clear
> everyone
> agrees and is happy before I make any changes. Sounds like for
> things like
> the Groovy/JavaScript/etc helloworld and calculator type samples
> they would
> go with the extension, I'm guessing samples that use just sca and
> java would
> go in an sca/samples directory. Samples that use multiple
> extensions but
> still just SCA would also go in the sca/samples directory, and
> there'd be a
> top level samples directory for things like bigbank that use sca/
> sdo/das.
>
> So:
>
> samples/bingbank
> das/samples/companyweb
> sca/samples/calculator
> sca/services/containers/container.javascript/src/samples/calculator
>
> Comments?
+1
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by Simon Nash <na...@hursley.ibm.com>.
Venkat,
+1 from me. This seems exactly right.
Simon
Venkata Krishnan wrote:
> Hi,
>
> I'd prefer to have business samples under 'samples' itself. I perceive
> that
> technology samples will go to the respective project directories and all
> others are to demonstrate the cool things of combining containers,
> transports - the integration story and they would all get under samples
> i.e.
> samples/BigBang, samples/SupplyChain .. and so on.
>
> - Venkat
>
>
>
> On 10/7/06, ant elder <an...@gmail.com> wrote:
>
>>
>> I guess I was thinking that the technology type samples would be the ones
>> that are now moved further down into the folder hierarchy so the only
>> thing
>> left up at the top would be the business samples so there wasn't the need
>> for the two folders 'samples' and 'sampleapps' so sampleapps might as
>> well
>> just be renamed to samples to keep everything consistent.
>>
>> Please anyone say if they disagree with that. I'd also still like to hear
>> comments or suggestions on all this from others who've expressed an
>> interest
>> in the samples in the past before I make the changes - Jim , Rick,
>> Simon?
>>
>> ...ant
>>
>> On 10/6/06, Brent Daniel <br...@gmail.com> wrote:
>> >
>> > Previously we had discussed having a "sampleapps" directory to
>> > distinguish "business samples" from technology samples.[1] Do we want
>> > to continue this distinction?
>> >
>> > Brent
>> >
>> >
>> > [1] -
>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01812.html
>> >
>> > On 10/6/06, ant elder <an...@gmail.com> wrote:
>> > > Ok I think we're getting some agreement but I'd like to be clear
>> > everyone
>> > > agrees and is happy before I make any changes. Sounds like for things
>> > like
>> > > the Groovy/JavaScript/etc helloworld and calculator type samples they
>> > would
>> > > go with the extension, I'm guessing samples that use just sca and
>> java
>> > would
>> > > go in an sca/samples directory. Samples that use multiple extensions
>> but
>> > > still just SCA would also go in the sca/samples directory, and
>> there'd
>> > be a
>> > > top level samples directory for things like bigbank that use
>> > sca/sdo/das.
>> > >
>> > > So:
>> > >
>> > > samples/bingbank
>> > > das/samples/companyweb
>> > > sca/samples/calculator
>> > > sca/services/containers/container.javascript/src/samples/calculator
>> > >
>> > > Comments?
>> > >
>> > > ...ant
>> > >
>> > > On 10/5/06, Jim Marino <jm...@myromatours.com> wrote:
>> > > >
>> > > >
>> > > > On Oct 5, 2006, at 7:14 AM, ant elder wrote:
>> > > >
>> > > > > On 10/5/06, Jeremy Boynes <jb...@apache.org> wrote:
>> > > > >>
>> > > > >> I think organizing the samples like this is a good idea. I'd
>> > suggest
>> > > > >> going one step further and place each sample with the
>> > implementation
>> > > > >> of the service that it is illustrating. That way it becomes much
>> > > > >> easier to tag/release each module on its own.
>> > > > >
>> > > > >
>> > > > > I'm not sure I follow "place each sample with the implementation
>> of
>> > > > > the
>> > > > > service that it is illustrating" , do you mean something like:
>> > > > >
>> > > > > samples/helloworld/java
>> > > > > samples/helloworld/javascript
>> > > > > samples/calculator/java
>> > > > > samples/calculator/javascript
>> > > > >
>> > > > > Or do you mean include them with the extension so the JavaScript
>> > > > > folder
>> > > > > would include samples/helloworld and samples/calculator? I didn't
>> > > > > think Jim
>> > > > > liked this way, from the previous thread - "In other words, each
>> > > > > sample
>> > > > > project should not be a sibling to the project containing
>> extension
>> > > > > code but
>> > > > > should go under a samples folder in separate projects".
>> > > > I was thinking samples for particular extensions would go under the
>> > > > particular extension's directory. For samples that used multiple
>> > > > extensions, they would go under the master samples folder. I liked
>> > > > what was done with the calculator where stuff is shared between
>> > > > projects (component reuse) so if that structuring won't work for
>> re-
>> > > > use I would be fine with what Ant just outlined. My preference,
>> > > > though, would be to group samples with individual extensions.
>> > > >
>> > > > Jim
>> > > >
>> > > > >
>> > > > > ...ant
>> > > >
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> > > >
>> > > >
>> > >
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>> >
>>
>>
>
--
Simon C Nash IBM Distinguished Engineer
Hursley Park, Winchester, UK nash@hursley.ibm.com
Tel. +44-1962-815156 Fax +44-1962-818999
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by Jim Marino <jm...@myromatours.com>.
On Oct 10, 2006, at 1:26 PM, ant elder wrote:
> All i was suggesting for right now was moving the entire top level
> samples
> folder as-is to sca/samples and renaming the top level sampleapps
> folder to
> be samples. I don't think there's consensus on anything else yet.
One thing I would be against is having the samples built from the
main checkin build under /sca. If that's not the case (i.e. samples
are not built by the default goal) then my preference would be to
have a more definite plan before we moved stuff. If people feel
moving these around prior to getting a plan in place is progress, and
there are no other objections, then I'd be o.k. (again as long as the
samples are not part of the main build). Ultimately, I think our
release manager needs to chime in given our goals of delivering
something soon...
Jim
>
> ...ant
>
> On 10/10/06, Jim Marino <jm...@myromatours.com> wrote:
>>
>>
>> On Oct 10, 2006, at 12:47 PM, ant elder wrote:
>>
>> > Also, as I think there has been some consensus on large parts of
>> > this how
>> > about making some incremental changes? For example, I think there's
>> > agreement that the vast majority of the existing top level
>> > 'samples' folder
>> > would move to 'sca/samples', and that the top level folder which
>> > contains
>> > bigbank will be renamed from 'sampleapps' to 'samples'. So how
>> > about I go
>> > ahead and make those changes now?
>> I think we should be clear on what the incremental changes are...Will
>> the existing samples specific to extensions then be refactored into
>> their respective extension projects, e.g. JavaScript samples under
>> the JavaScript extension? Also, I'm not sure we are clear on what the
>> move entails. Specifically, the samples should *not* be built as part
>> of the standard checkin build. What I propose is:
>>
>> 1. There is a samples directory under root that contains a version of
>> BigBank which spans multiple Tuscany sub-projects (SDO/DAS/SCA)
>>
>> 2. There is a samples directory under /sca for "baseline" samples.
>> These baseline samples would comprise a samples distribution
>> consisting of source. The source would be buildable by end-users from
>> the distribution and we could add a variety of artifacts to assist in
>> that, including a build.xml, .project (Eclipse), and .iml (IDEA)
>> files. This distribution would not be built by the standard Tuscany
>> check-in build. Since it is important for samples to *work* (not just
>> build), there would be a series of integration tests run periodically
>> somewhere. Samples would only be guaranteed to work on a stable
>> snapshot of core.
>>
>> 3. An extension could also choose to include samples with it. These
>> samples would also be distributed as source and would *not* be built
>> as part of the main checkin process. The difference with #2 is that
>> these samples would be non-baseline (e.g. "contrib" samples) and
>> could release independently from the main samples distribution. In
>> terms of the svn repo format, the sample artifacts could either go
>> under a sibling folder of java/main (e.g. java/samples) or be
>> contained within a Maven sub-module of the extension.
>>
>> I think this would address issues we are having around modularity as
>> well as provide a way for us to verify samples are working through
>> integration testing (which cannot be done by seeing if they compile).
>>
>> I'd like to have a plan agreed on before we make repo changes given
>> we are trying to also get a release out.
>>
>> Jim
>>
>>
>> > I'll go ahead and do this unless I hear
>> > any objections (but it would be nice to hear at least couple of
>> > okays).
>> >
>> > ...ant
>> >
>> > On 10/10/06, ant elder <an...@gmail.com> wrote:
>> >>
>> >> Putting aside the when they get built question for now, what i was
>> >> really
>> >> asking (in a very unclear way) a few emails ago was if I've really
>> >> got the
>> >> directory structure quite right yet?
>> >>
>> >> For example, there's the existing JavaScript container maven
>> >> project at:
>> >>
>> >> sca/services/containers/container.javascript
>> >>
>> >> I'd suggested samples would go at:
>> >>
>> >> sca/services/containers/container.javascript/src/samples/
>> >> calculator
>> >>
>> >> But can maven projects really be nested like this? If there's a
>> >> pom.xml in
>> >> that calculator folder does that work nested in the JavaScript
>> >> project with
>> >> a pom.xml in the container.javascript folder? What references the
>> >> sample
>> >> pom.xml and how would it ever get built? I've not tried this but
>> >> it seems
>> >> odd, could someone who understands maven projects comment on if
>> >> this ok?
>> >>
>> >> ...ant
>> >>
>> >> On 10/9/06, Jim Marino <jm...@myromatours.com> wrote:
>> >> >
>> >> >
>> >> > On Oct 9, 2006, at 8:37 AM, Simon Nash wrote:
>> >> >
>> >> > > I agree with Andy. An integration test framework ro build and
>> >> > > run the samples is the right long term solution, but until we
>> >> have
>> >> > > that framework, we should not remove building the samples from
>> >> > > the regular build.
>> >> > The samples are not part of the "regular" build, they are part
>> >> of the
>> >> > root one. The root build should never have to be run for a
>> >> checkin of
>> >> > Java SCA as it includes SDO and DAS, which we agreed should
>> not be
>> >> > required by the former for modularity.
>> >> >
>> >> > I'm not going to rehash old ground but I will state that we
>> need an
>> >> > integration test framework run as part of a continuous
>> integration
>> >> > process that will include samples testing but goes well beyond
>> >> that.
>> >> > In addition, the check-in build should contain test cases that
>> >> verify
>> >> > basic things like bootstrapping (standalone, webapp); this can
>> >> all be
>> >> > done using EasyMock without the need for code to execute in-
>> >> > container. The reason the samples are breaking is not because we
>> >> > don't run them as part of the build, it's because our basic test
>> >> > coverage is lacking.
>> >> >
>> >> > I propose we work to resolve this by the following:
>> >> >
>> >> > 1. Put testcases that verify bootstrapping in the checkin build.
>> >> > these should only use EasyMock and not run any containers (e.g.
>> >> Jetty)
>> >> > 2. Move to a continuous integration framework, perhaps
>> Continuum.
>> >> > These tests should
>> >> >
>> >> > - Run the samples in a number of container hosts we
>> support
>> >> > (Tomcat,
>> >> > Jetty, Standalone, etc.)
>> >> > - Perform a deeper level of integration tests between
>> >> various
>> >> > subsystems, such as wiring between component implementation
>> types,
>> >> > interop testing, etc.
>> >> > - Be run periodically. We may eventually want to break
>> >> them into
>> >> >
>> >> > parts. Some which run every 15 minutes or so, others (more
>> resource
>> >> > intensive) which run around twice a day
>> >> >
>> >> > I'm willing to help out if there are some volunteers. Any
>> >> volunteers?
>> >> >
>> >> > Jim
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >> >
>> >> >
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by ant elder <an...@gmail.com>.
All i was suggesting for right now was moving the entire top level samples
folder as-is to sca/samples and renaming the top level sampleapps folder to
be samples. I don't think there's consensus on anything else yet.
...ant
On 10/10/06, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Oct 10, 2006, at 12:47 PM, ant elder wrote:
>
> > Also, as I think there has been some consensus on large parts of
> > this how
> > about making some incremental changes? For example, I think there's
> > agreement that the vast majority of the existing top level
> > 'samples' folder
> > would move to 'sca/samples', and that the top level folder which
> > contains
> > bigbank will be renamed from 'sampleapps' to 'samples'. So how
> > about I go
> > ahead and make those changes now?
> I think we should be clear on what the incremental changes are...Will
> the existing samples specific to extensions then be refactored into
> their respective extension projects, e.g. JavaScript samples under
> the JavaScript extension? Also, I'm not sure we are clear on what the
> move entails. Specifically, the samples should *not* be built as part
> of the standard checkin build. What I propose is:
>
> 1. There is a samples directory under root that contains a version of
> BigBank which spans multiple Tuscany sub-projects (SDO/DAS/SCA)
>
> 2. There is a samples directory under /sca for "baseline" samples.
> These baseline samples would comprise a samples distribution
> consisting of source. The source would be buildable by end-users from
> the distribution and we could add a variety of artifacts to assist in
> that, including a build.xml, .project (Eclipse), and .iml (IDEA)
> files. This distribution would not be built by the standard Tuscany
> check-in build. Since it is important for samples to *work* (not just
> build), there would be a series of integration tests run periodically
> somewhere. Samples would only be guaranteed to work on a stable
> snapshot of core.
>
> 3. An extension could also choose to include samples with it. These
> samples would also be distributed as source and would *not* be built
> as part of the main checkin process. The difference with #2 is that
> these samples would be non-baseline (e.g. "contrib" samples) and
> could release independently from the main samples distribution. In
> terms of the svn repo format, the sample artifacts could either go
> under a sibling folder of java/main (e.g. java/samples) or be
> contained within a Maven sub-module of the extension.
>
> I think this would address issues we are having around modularity as
> well as provide a way for us to verify samples are working through
> integration testing (which cannot be done by seeing if they compile).
>
> I'd like to have a plan agreed on before we make repo changes given
> we are trying to also get a release out.
>
> Jim
>
>
> > I'll go ahead and do this unless I hear
> > any objections (but it would be nice to hear at least couple of
> > okays).
> >
> > ...ant
> >
> > On 10/10/06, ant elder <an...@gmail.com> wrote:
> >>
> >> Putting aside the when they get built question for now, what i was
> >> really
> >> asking (in a very unclear way) a few emails ago was if I've really
> >> got the
> >> directory structure quite right yet?
> >>
> >> For example, there's the existing JavaScript container maven
> >> project at:
> >>
> >> sca/services/containers/container.javascript
> >>
> >> I'd suggested samples would go at:
> >>
> >> sca/services/containers/container.javascript/src/samples/
> >> calculator
> >>
> >> But can maven projects really be nested like this? If there's a
> >> pom.xml in
> >> that calculator folder does that work nested in the JavaScript
> >> project with
> >> a pom.xml in the container.javascript folder? What references the
> >> sample
> >> pom.xml and how would it ever get built? I've not tried this but
> >> it seems
> >> odd, could someone who understands maven projects comment on if
> >> this ok?
> >>
> >> ...ant
> >>
> >> On 10/9/06, Jim Marino <jm...@myromatours.com> wrote:
> >> >
> >> >
> >> > On Oct 9, 2006, at 8:37 AM, Simon Nash wrote:
> >> >
> >> > > I agree with Andy. An integration test framework ro build and
> >> > > run the samples is the right long term solution, but until we
> >> have
> >> > > that framework, we should not remove building the samples from
> >> > > the regular build.
> >> > The samples are not part of the "regular" build, they are part
> >> of the
> >> > root one. The root build should never have to be run for a
> >> checkin of
> >> > Java SCA as it includes SDO and DAS, which we agreed should not be
> >> > required by the former for modularity.
> >> >
> >> > I'm not going to rehash old ground but I will state that we need an
> >> > integration test framework run as part of a continuous integration
> >> > process that will include samples testing but goes well beyond
> >> that.
> >> > In addition, the check-in build should contain test cases that
> >> verify
> >> > basic things like bootstrapping (standalone, webapp); this can
> >> all be
> >> > done using EasyMock without the need for code to execute in-
> >> > container. The reason the samples are breaking is not because we
> >> > don't run them as part of the build, it's because our basic test
> >> > coverage is lacking.
> >> >
> >> > I propose we work to resolve this by the following:
> >> >
> >> > 1. Put testcases that verify bootstrapping in the checkin build.
> >> > these should only use EasyMock and not run any containers (e.g.
> >> Jetty)
> >> > 2. Move to a continuous integration framework, perhaps Continuum.
> >> > These tests should
> >> >
> >> > - Run the samples in a number of container hosts we support
> >> > (Tomcat,
> >> > Jetty, Standalone, etc.)
> >> > - Perform a deeper level of integration tests between
> >> various
> >> > subsystems, such as wiring between component implementation types,
> >> > interop testing, etc.
> >> > - Be run periodically. We may eventually want to break
> >> them into
> >> >
> >> > parts. Some which run every 15 minutes or so, others (more resource
> >> > intensive) which run around twice a day
> >> >
> >> > I'm willing to help out if there are some volunteers. Any
> >> volunteers?
> >> >
> >> > Jim
> >> >
> >> >
> >> >
> >> >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >
> >> >
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: SCA Java samples for M2
Posted by Jim Marino <jm...@myromatours.com>.
On Oct 10, 2006, at 12:47 PM, ant elder wrote:
> Also, as I think there has been some consensus on large parts of
> this how
> about making some incremental changes? For example, I think there's
> agreement that the vast majority of the existing top level
> 'samples' folder
> would move to 'sca/samples', and that the top level folder which
> contains
> bigbank will be renamed from 'sampleapps' to 'samples'. So how
> about I go
> ahead and make those changes now?
I think we should be clear on what the incremental changes are...Will
the existing samples specific to extensions then be refactored into
their respective extension projects, e.g. JavaScript samples under
the JavaScript extension? Also, I'm not sure we are clear on what the
move entails. Specifically, the samples should *not* be built as part
of the standard checkin build. What I propose is:
1. There is a samples directory under root that contains a version of
BigBank which spans multiple Tuscany sub-projects (SDO/DAS/SCA)
2. There is a samples directory under /sca for "baseline" samples.
These baseline samples would comprise a samples distribution
consisting of source. The source would be buildable by end-users from
the distribution and we could add a variety of artifacts to assist in
that, including a build.xml, .project (Eclipse), and .iml (IDEA)
files. This distribution would not be built by the standard Tuscany
check-in build. Since it is important for samples to *work* (not just
build), there would be a series of integration tests run periodically
somewhere. Samples would only be guaranteed to work on a stable
snapshot of core.
3. An extension could also choose to include samples with it. These
samples would also be distributed as source and would *not* be built
as part of the main checkin process. The difference with #2 is that
these samples would be non-baseline (e.g. "contrib" samples) and
could release independently from the main samples distribution. In
terms of the svn repo format, the sample artifacts could either go
under a sibling folder of java/main (e.g. java/samples) or be
contained within a Maven sub-module of the extension.
I think this would address issues we are having around modularity as
well as provide a way for us to verify samples are working through
integration testing (which cannot be done by seeing if they compile).
I'd like to have a plan agreed on before we make repo changes given
we are trying to also get a release out.
Jim
> I'll go ahead and do this unless I hear
> any objections (but it would be nice to hear at least couple of
> okays).
>
> ...ant
>
> On 10/10/06, ant elder <an...@gmail.com> wrote:
>>
>> Putting aside the when they get built question for now, what i was
>> really
>> asking (in a very unclear way) a few emails ago was if I've really
>> got the
>> directory structure quite right yet?
>>
>> For example, there's the existing JavaScript container maven
>> project at:
>>
>> sca/services/containers/container.javascript
>>
>> I'd suggested samples would go at:
>>
>> sca/services/containers/container.javascript/src/samples/
>> calculator
>>
>> But can maven projects really be nested like this? If there's a
>> pom.xml in
>> that calculator folder does that work nested in the JavaScript
>> project with
>> a pom.xml in the container.javascript folder? What references the
>> sample
>> pom.xml and how would it ever get built? I've not tried this but
>> it seems
>> odd, could someone who understands maven projects comment on if
>> this ok?
>>
>> ...ant
>>
>> On 10/9/06, Jim Marino <jm...@myromatours.com> wrote:
>> >
>> >
>> > On Oct 9, 2006, at 8:37 AM, Simon Nash wrote:
>> >
>> > > I agree with Andy. An integration test framework ro build and
>> > > run the samples is the right long term solution, but until we
>> have
>> > > that framework, we should not remove building the samples from
>> > > the regular build.
>> > The samples are not part of the "regular" build, they are part
>> of the
>> > root one. The root build should never have to be run for a
>> checkin of
>> > Java SCA as it includes SDO and DAS, which we agreed should not be
>> > required by the former for modularity.
>> >
>> > I'm not going to rehash old ground but I will state that we need an
>> > integration test framework run as part of a continuous integration
>> > process that will include samples testing but goes well beyond
>> that.
>> > In addition, the check-in build should contain test cases that
>> verify
>> > basic things like bootstrapping (standalone, webapp); this can
>> all be
>> > done using EasyMock without the need for code to execute in-
>> > container. The reason the samples are breaking is not because we
>> > don't run them as part of the build, it's because our basic test
>> > coverage is lacking.
>> >
>> > I propose we work to resolve this by the following:
>> >
>> > 1. Put testcases that verify bootstrapping in the checkin build.
>> > these should only use EasyMock and not run any containers (e.g.
>> Jetty)
>> > 2. Move to a continuous integration framework, perhaps Continuum.
>> > These tests should
>> >
>> > - Run the samples in a number of container hosts we support
>> > (Tomcat,
>> > Jetty, Standalone, etc.)
>> > - Perform a deeper level of integration tests between
>> various
>> > subsystems, such as wiring between component implementation types,
>> > interop testing, etc.
>> > - Be run periodically. We may eventually want to break
>> them into
>> >
>> > parts. Some which run every 15 minutes or so, others (more resource
>> > intensive) which run around twice a day
>> >
>> > I'm willing to help out if there are some volunteers. Any
>> volunteers?
>> >
>> > Jim
>> >
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>> >
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by ant elder <an...@gmail.com>.
Also, as I think there has been some consensus on large parts of this how
about making some incremental changes? For example, I think there's
agreement that the vast majority of the existing top level 'samples' folder
would move to 'sca/samples', and that the top level folder which contains
bigbank will be renamed from 'sampleapps' to 'samples'. So how about I go
ahead and make those changes now? I'll go ahead and do this unless I hear
any objections (but it would be nice to hear at least couple of okays).
...ant
On 10/10/06, ant elder <an...@gmail.com> wrote:
>
> Putting aside the when they get built question for now, what i was really
> asking (in a very unclear way) a few emails ago was if I've really got the
> directory structure quite right yet?
>
> For example, there's the existing JavaScript container maven project at:
>
> sca/services/containers/container.javascript
>
> I'd suggested samples would go at:
>
> sca/services/containers/container.javascript/src/samples/calculator
>
> But can maven projects really be nested like this? If there's a pom.xml in
> that calculator folder does that work nested in the JavaScript project with
> a pom.xml in the container.javascript folder? What references the sample
> pom.xml and how would it ever get built? I've not tried this but it seems
> odd, could someone who understands maven projects comment on if this ok?
>
> ...ant
>
> On 10/9/06, Jim Marino <jm...@myromatours.com> wrote:
> >
> >
> > On Oct 9, 2006, at 8:37 AM, Simon Nash wrote:
> >
> > > I agree with Andy. An integration test framework ro build and
> > > run the samples is the right long term solution, but until we have
> > > that framework, we should not remove building the samples from
> > > the regular build.
> > The samples are not part of the "regular" build, they are part of the
> > root one. The root build should never have to be run for a checkin of
> > Java SCA as it includes SDO and DAS, which we agreed should not be
> > required by the former for modularity.
> >
> > I'm not going to rehash old ground but I will state that we need an
> > integration test framework run as part of a continuous integration
> > process that will include samples testing but goes well beyond that.
> > In addition, the check-in build should contain test cases that verify
> > basic things like bootstrapping (standalone, webapp); this can all be
> > done using EasyMock without the need for code to execute in-
> > container. The reason the samples are breaking is not because we
> > don't run them as part of the build, it's because our basic test
> > coverage is lacking.
> >
> > I propose we work to resolve this by the following:
> >
> > 1. Put testcases that verify bootstrapping in the checkin build.
> > these should only use EasyMock and not run any containers (e.g. Jetty)
> > 2. Move to a continuous integration framework, perhaps Continuum.
> > These tests should
> >
> > - Run the samples in a number of container hosts we support
> > (Tomcat,
> > Jetty, Standalone, etc.)
> > - Perform a deeper level of integration tests between various
> > subsystems, such as wiring between component implementation types,
> > interop testing, etc.
> > - Be run periodically. We may eventually want to break them into
> >
> > parts. Some which run every 15 minutes or so, others (more resource
> > intensive) which run around twice a day
> >
> > I'm willing to help out if there are some volunteers. Any volunteers?
> >
> > Jim
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
Re: SCA Java samples for M2
Posted by ant elder <an...@gmail.com>.
Putting aside the when they get built question for now, what i was really
asking (in a very unclear way) a few emails ago was if I've really got the
directory structure quite right yet?
For example, there's the existing JavaScript container maven project at:
sca/services/containers/container.javascript
I'd suggested samples would go at:
sca/services/containers/container.javascript/src/samples/calculator
But can maven projects really be nested like this? If there's a pom.xml in
that calculator folder does that work nested in the JavaScript project with
a pom.xml in the container.javascript folder? What references the sample
pom.xml and how would it ever get built? I've not tried this but it seems
odd, could someone who understands maven projects comment on if this ok?
...ant
On 10/9/06, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Oct 9, 2006, at 8:37 AM, Simon Nash wrote:
>
> > I agree with Andy. An integration test framework ro build and
> > run the samples is the right long term solution, but until we have
> > that framework, we should not remove building the samples from
> > the regular build.
> The samples are not part of the "regular" build, they are part of the
> root one. The root build should never have to be run for a checkin of
> Java SCA as it includes SDO and DAS, which we agreed should not be
> required by the former for modularity.
>
> I'm not going to rehash old ground but I will state that we need an
> integration test framework run as part of a continuous integration
> process that will include samples testing but goes well beyond that.
> In addition, the check-in build should contain test cases that verify
> basic things like bootstrapping (standalone, webapp); this can all be
> done using EasyMock without the need for code to execute in-
> container. The reason the samples are breaking is not because we
> don't run them as part of the build, it's because our basic test
> coverage is lacking.
>
> I propose we work to resolve this by the following:
>
> 1. Put testcases that verify bootstrapping in the checkin build.
> these should only use EasyMock and not run any containers (e.g. Jetty)
> 2. Move to a continuous integration framework, perhaps Continuum.
> These tests should
>
> - Run the samples in a number of container hosts we support
> (Tomcat,
> Jetty, Standalone, etc.)
> - Perform a deeper level of integration tests between various
> subsystems, such as wiring between component implementation types,
> interop testing, etc.
> - Be run periodically. We may eventually want to break them into
> parts. Some which run every 15 minutes or so, others (more resource
> intensive) which run around twice a day
>
> I'm willing to help out if there are some volunteers. Any volunteers?
>
> Jim
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: SCA Java samples for M2
Posted by Rick <cr...@gmail.com>.
I see value that we know they still build and we may have in the future some
unit tests for these too. I agree the was is still lacking is an integration
test - which does not run during normal build.
Jeremy Boynes wrote:
> In many cases building the sample does not actually prove anything as
> they are not executed. This applies, for example, to the webapp-based
> samples we have. When they are executed, we still don't know that they
> run in the end-user environment - e.g. the standalone samples that run
> from SCATestCase but which fail to run from the launcher.
>
> Where they should be built/run is as part of an integration test suite.
> We don't have that ATM.
> --
> Jeremy
>
> On Oct 9, 2006, at 7:12 AM, Rick wrote:
>
>> What is the reasoning behind not wanting to build samples? You can
>> always go in a subdir while developing and only re-build a particular
>> extension or the core. I'm worried that this will lead the samples to
>> go out of date.
>>
>> ant elder wrote:
>>> A final part of this is how the samples get built. One thing Jim
>>> wanted was
>>> for the samples to not get built with a regular build. If there's a (or
>>> some?) sample in
>>> sca/services/containers/container.javascript/src/samples/calculator
>>> how does
>>> that fit in with the maven build?
>>> ...ant
>>> On 10/9/06, Venkata Krishnan <fo...@gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> So can we finalize on this and start moving the samples. While
>>>> doing this
>>>>
>>>> can we also do the following: -
>>>>
>>>> - Go up to the wiki
>>>> http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2Tasks#preview and
>>>> update
>>>> the
>>>> samples section
>>>> - If the sample is tried and includes a readme that explains how to go
>>>> about
>>>> setting it up and running it mark the sample as complete.
>>>> - If there are issues related to the sample, please update the
>>>> issues that
>>>>
>>>> are pending or being worked upon.
>>>>
>>>> Thoughts ?
>>>>
>>>> - Venkat
>>>>
>>>> On 10/8/06, Venkata Krishnan <fo...@gmail.com> wrote:
>>>> >
>>>> > Yes Jim.. so that the pattern is clear to the user. i.e the user
>>>> would
>>>> > see and feel in the samples at a particular level, only those
>>>> features
>>>> that
>>>> > exist at that level.
>>>> >
>>>> > For example a user could get a feel of individual extensions from the
>>>> > various samples, be able to digest them and then move out to the SCA
>>>> level
>>>> > to get a feel of how the extensions could be combined. Then moving
>>>> futher
>>>> > out to the base wherein the samples there demonstrate the roles of
>>>> SCA,
>>>> SDO
>>>> > and DAS in providing uniform service access, data proecessing and
>>>> data
>>>> > access mechanism for SOA based applications.
>>>> >
>>>> > - Venkat
>>>> >
>>>> > On 10/8/06, Jim Marino < jmarino@myromatours.com> wrote:
>>>> > >
>>>> > >
>>>> > > On Oct 7, 2006, at 10:01 AM, Venkata Krishnan wrote:
>>>> > >
>>>> > > > Hi,
>>>> > > >
>>>> > > > I'd prefer to have business samples under 'samples' itself. I
>>>> > > > perceive that
>>>> > > > technology samples will go to the respective project directories
>>>> > > > and all
>>>> > > > others are to demonstrate the cool things of combining
>>>> containers,
>>>> > > > transports - the integration story and they would all get under
>>>> > > > samples i.e.
>>>> > > > samples/BigBang, samples/SupplyChain .. and so on.
>>>> > > >
>>>> > > I want to check that we are saying the same thing. Here is what I
>>>> > > understand the proposed structuring to be:
>>>> > >
>>>> > > > samples/bingbank
>>>> > > > > > das/samples/companyweb
>>>> > > > > > sca/samples/calculator
>>>> > > > > > sca/services/containers/container.javascript/src/samples/
>>>> > > > calculator
>>>> > >
>>>> > > To me this means:
>>>> > >
>>>> > > 1. Samples which are designed to illustrate multiple Tuscany sub-
>>>> > > projects (SCA/SDO/DAS) working together go under java/samples.
>>>> These
>>>> > > are generally "applications" or as some people like to refer to
>>>> them
>>>> > > "business samples"
>>>> > >
>>>> > > 2. Samples which are applications that are designed to
>>>> illustrate one
>>>> > > Tuscany sub-project go under their respective sub-project samples
>>>> > > directory. For example, das/samples/companyweb or
>>>> sca/samples/bigbank
>>>> > > for a version of BigBank that only uses SCA.
>>>> > >
>>>> > > 3. SCA samples that illustrate a particular Java SCA runtime
>>>> > > extension go in a samples folder under the extension, e.g. sca/
>>>> > > services/containers/container.javascript/src/samples/calculator.
>>>> SDO
>>>> > > and DAS may choose to follow a similar scheme if it makes sense for
>>>> > > those projects.
>>>> > >
>>>> > > Does that align with what you are saying?
>>>> > >
>>>> > > Jim
>>>> > >
>>>> > >
>>>> > > > - Venkat
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > > On 10/7/06, ant elder <an...@gmail.com> wrote:
>>>> > > >>
>>>> > > >> I guess I was thinking that the technology type samples would be
>>>> > > >> the ones
>>>> > > >> that are now moved further down into the folder hierarchy so the
>>>> only
>>>> > > >> thing
>>>> > > >> left up at the top would be the business samples so there wasn't
>>>> > > >> the need
>>>> > > >> for the two folders 'samples' and 'sampleapps' so sampleapps
>>>> might
>>>> > > >> as well
>>>> > > >> just be renamed to samples to keep everything consistent.
>>>> > > >>
>>>> > > >> Please anyone say if they disagree with that. I'd also still
>>>> like
>>>> > > >> to hear
>>>> > > >> comments or suggestions on all this from others who've
>>>> expressed an
>>>> > > >> interest
>>>> > > >> in the samples in the past before I make the changes - Jim ,
>>>> > > >> Rick, Simon?
>>>> > > >>
>>>> > > >> ...ant
>>>> > > >>
>>>> > > >> On 10/6/06, Brent Daniel <br...@gmail.com> wrote:
>>>> > > >> >
>>>> > > >> > Previously we had discussed having a "sampleapps" directory to
>>>> > > >> > distinguish "business samples" from technology samples.[1]
>>>> Do we
>>>> > > >> want
>>>> > > >> > to continue this distinction?
>>>> > > >> >
>>>> > > >> > Brent
>>>> > > >> >
>>>> > > >> >
>>>> > > >> > [1] -
>>>> > > >>
>>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01812.html
>>>> > > >> >
>>>> > > >> > On 10/6/06, ant elder < ant.elder@gmail.com> wrote:
>>>> > > >> > > Ok I think we're getting some agreement but I'd like to be
>>>> clear
>>>> > > >> > everyone
>>>> > > >> > > agrees and is happy before I make any changes. Sounds
>>>> like for
>>>> > > >> things
>>>> > > >> > like
>>>> > > >> > > the Groovy/JavaScript/etc helloworld and calculator type
>>>> > > >> samples they
>>>> > > >> > would
>>>> > > >> > > go with the extension, I'm guessing samples that use just
>>>> sca
>>>> > > >> and java
>>>> > > >> > would
>>>> > > >> > > go in an sca/samples directory. Samples that use multiple
>>>> > > >> extensions
>>>> > > >> but
>>>> > > >> > > still just SCA would also go in the sca/samples
>>>> directory, and
>>>> > > >> there'd
>>>> > > >> > be a
>>>> > > >> > > top level samples directory for things like bigbank that use
>>>> > > >> > sca/sdo/das.
>>>> > > >> > >
>>>> > > >> > > So:
>>>> > > >> > >
>>>> > > >> > > samples/bingbank
>>>> > > >> > > das/samples/companyweb
>>>> > > >> > > sca/samples/calculator
>>>> > > >> > > sca/services/containers/container.javascript/src/samples/
>>>> > > >> calculator
>>>> > > >> > >
>>>> > > >> > > Comments?
>>>> > > >> > >
>>>> > > >> > > ...ant
>>>> > > >> > >
>>>> > > >> > > On 10/5/06, Jim Marino <jmarino@myromatours.com > wrote:
>>>> > > >> > > >
>>>> > > >> > > >
>>>> > > >> > > > On Oct 5, 2006, at 7:14 AM, ant elder wrote:
>>>> > > >> > > >
>>>> > > >> > > > > On 10/5/06, Jeremy Boynes < jboynes@apache.org> wrote:
>>>> > > >> > > > >>
>>>> > > >> > > > >> I think organizing the samples like this is a good
>>>> idea.
>>>> I'd
>>>> > > >> > suggest
>>>> > > >> > > > >> going one step further and place each sample with the
>>>> > > >> > implementation
>>>> > > >> > > > >> of the service that it is illustrating. That way it
>>>> > > >> becomes much
>>>> > > >> > > > >> easier to tag/release each module on its own.
>>>> > > >> > > > >
>>>> > > >> > > > >
>>>> > > >> > > > > I'm not sure I follow "place each sample with the
>>>> > > >> implementation
>>>> > > >> of
>>>> > > >> > > > > the
>>>> > > >> > > > > service that it is illustrating" , do you mean something
>>>> > > >> like:
>>>> > > >> > > > >
>>>> > > >> > > > > samples/helloworld/java
>>>> > > >> > > > > samples/helloworld/javascript
>>>> > > >> > > > > samples/calculator/java
>>>> > > >> > > > > samples/calculator/javascript
>>>> > > >> > > > >
>>>> > > >> > > > > Or do you mean include them with the extension so the
>>>> > > >> JavaScript
>>>> > > >> > > > > folder
>>>> > > >> > > > > would include samples/helloworld and
>>>> samples/calculator? I
>>>> > > >> didn't
>>>> > > >> > > > > think Jim
>>>> > > >> > > > > liked this way, from the previous thread - "In other
>>>> > > >> words, each
>>>> > > >> > > > > sample
>>>> > > >> > > > > project should not be a sibling to the project
>>>> containing
>>>> > > >> extension
>>>> > > >> > > > > code but
>>>> > > >> > > > > should go under a samples folder in separate projects".
>>>> > > >> > > > I was thinking samples for particular extensions would go
>>>> > > >> under the
>>>> > > >> > > > particular extension's directory. For samples that used
>>>> > > >> multiple
>>>> > > >> > > > extensions, they would go under the master samples
>>>> folder. I
>>>> > > >> liked
>>>> > > >> > > > what was done with the calculator where stuff is shared
>>>> between
>>>> > > >> > > > projects (component reuse) so if that structuring won't
>>>> work
>>>> > > >> for re-
>>>> > > >> > > > use I would be fine with what Ant just outlined. My
>>>> preference,
>>>> > >
>>>> > > >> > > > though, would be to group samples with individual
>>>> extensions.
>>>>
>>>> > > >> > > >
>>>> > > >> > > > Jim
>>>> > > >> > > >
>>>> > > >> > > > >
>>>> > > >> > > > > ...ant
>>>> > > >> > > >
>>>> > > >> > > >
>>>> > > >> > > >
>>>> > > >>
>>>> ---------------------------------------------------------------------
>>>> > > >> > > > To unsubscribe, e-mail:
>>>> tuscany-dev-unsubscribe@ws.apache.org
>>>> > > >> > > > For additional commands, e-mail:
>>>> tuscany-dev-help@ws.apache.org
>>>>
>>>> > > >> > > >
>>>> > > >> > > >
>>>> > > >> > >
>>>> > > >> > >
>>>> > > >> >
>>>> > > >> >
>>>> > > >>
>>>> ---------------------------------------------------------------------
>>>> > > >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> > > >> > For additional commands, e-mail:
>>>> tuscany-dev-help@ws.apache.org
>>>> > > >> >
>>>> > > >> >
>>>> > > >>
>>>> > > >>
>>>> > >
>>>> > >
>>>> > >
>>>> ---------------------------------------------------------------------
>>>> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>> > >
>>>> > >
>>>> >
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Integration test environment: SCA Java samples for M2
Posted by Jeremy Boynes <jb...@apache.org>.
On Oct 9, 2006, at 12:52 PM, Rick wrote:
> Not really part of this thread, but a question that came to mind
> because of it; would an integration test deploy and use Tomcat like
> we had before? If we ever got to using a continuum type build in
> apache would that be an issue ? Opening and sending through a
> socket at build/test time ?
I think doing that kind of thing would be an important part of an
integration test environment. For example, we would want to deploy
webapps not only to Tomcat but also Geronimo, Jetty, GlassFish,
JBoss, WebLogic, WebSphere, etc. We'd also want to get integration
between e.g. Tuscany and raw Axis2 or Geronimo with J2EE1.4
webservices or between the Java, C++, PHP, etc variations of Tuscany.
That's one big reason why I think this needs to be separate from the
developer build. Not everyone is going to be able to install all
those environments, or run the suite in an environment where they all
work (think about trying to do development on an airplane).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by Rick <cr...@gmail.com>.
Not really part of this thread, but a question that came to mind because of it;
would an integration test deploy and use Tomcat like we had before? If we ever
got to using a continuum type build in apache would that be an issue ? Opening
and sending through a socket at build/test time ?
Jeremy Boynes wrote:
> In many cases building the sample does not actually prove anything as
> they are not executed. This applies, for example, to the webapp-based
> samples we have. When they are executed, we still don't know that they
> run in the end-user environment - e.g. the standalone samples that run
> from SCATestCase but which fail to run from the launcher.
>
> Where they should be built/run is as part of an integration test suite.
> We don't have that ATM.
> --
> Jeremy
>
> On Oct 9, 2006, at 7:12 AM, Rick wrote:
>
>> What is the reasoning behind not wanting to build samples? You can
>> always go in a subdir while developing and only re-build a particular
>> extension or the core. I'm worried that this will lead the samples to
>> go out of date.
>>
>> ant elder wrote:
>>> A final part of this is how the samples get built. One thing Jim
>>> wanted was
>>> for the samples to not get built with a regular build. If there's a (or
>>> some?) sample in
>>> sca/services/containers/container.javascript/src/samples/calculator
>>> how does
>>> that fit in with the maven build?
>>> ...ant
>>> On 10/9/06, Venkata Krishnan <fo...@gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> So can we finalize on this and start moving the samples. While
>>>> doing this
>>>>
>>>> can we also do the following: -
>>>>
>>>> - Go up to the wiki
>>>> http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2Tasks#preview and
>>>> update
>>>> the
>>>> samples section
>>>> - If the sample is tried and includes a readme that explains how to go
>>>> about
>>>> setting it up and running it mark the sample as complete.
>>>> - If there are issues related to the sample, please update the
>>>> issues that
>>>>
>>>> are pending or being worked upon.
>>>>
>>>> Thoughts ?
>>>>
>>>> - Venkat
>>>>
>>>> On 10/8/06, Venkata Krishnan <fo...@gmail.com> wrote:
>>>> >
>>>> > Yes Jim.. so that the pattern is clear to the user. i.e the user
>>>> would
>>>> > see and feel in the samples at a particular level, only those
>>>> features
>>>> that
>>>> > exist at that level.
>>>> >
>>>> > For example a user could get a feel of individual extensions from the
>>>> > various samples, be able to digest them and then move out to the SCA
>>>> level
>>>> > to get a feel of how the extensions could be combined. Then moving
>>>> futher
>>>> > out to the base wherein the samples there demonstrate the roles of
>>>> SCA,
>>>> SDO
>>>> > and DAS in providing uniform service access, data proecessing and
>>>> data
>>>> > access mechanism for SOA based applications.
>>>> >
>>>> > - Venkat
>>>> >
>>>> > On 10/8/06, Jim Marino < jmarino@myromatours.com> wrote:
>>>> > >
>>>> > >
>>>> > > On Oct 7, 2006, at 10:01 AM, Venkata Krishnan wrote:
>>>> > >
>>>> > > > Hi,
>>>> > > >
>>>> > > > I'd prefer to have business samples under 'samples' itself. I
>>>> > > > perceive that
>>>> > > > technology samples will go to the respective project directories
>>>> > > > and all
>>>> > > > others are to demonstrate the cool things of combining
>>>> containers,
>>>> > > > transports - the integration story and they would all get under
>>>> > > > samples i.e.
>>>> > > > samples/BigBang, samples/SupplyChain .. and so on.
>>>> > > >
>>>> > > I want to check that we are saying the same thing. Here is what I
>>>> > > understand the proposed structuring to be:
>>>> > >
>>>> > > > samples/bingbank
>>>> > > > > > das/samples/companyweb
>>>> > > > > > sca/samples/calculator
>>>> > > > > > sca/services/containers/container.javascript/src/samples/
>>>> > > > calculator
>>>> > >
>>>> > > To me this means:
>>>> > >
>>>> > > 1. Samples which are designed to illustrate multiple Tuscany sub-
>>>> > > projects (SCA/SDO/DAS) working together go under java/samples.
>>>> These
>>>> > > are generally "applications" or as some people like to refer to
>>>> them
>>>> > > "business samples"
>>>> > >
>>>> > > 2. Samples which are applications that are designed to
>>>> illustrate one
>>>> > > Tuscany sub-project go under their respective sub-project samples
>>>> > > directory. For example, das/samples/companyweb or
>>>> sca/samples/bigbank
>>>> > > for a version of BigBank that only uses SCA.
>>>> > >
>>>> > > 3. SCA samples that illustrate a particular Java SCA runtime
>>>> > > extension go in a samples folder under the extension, e.g. sca/
>>>> > > services/containers/container.javascript/src/samples/calculator.
>>>> SDO
>>>> > > and DAS may choose to follow a similar scheme if it makes sense for
>>>> > > those projects.
>>>> > >
>>>> > > Does that align with what you are saying?
>>>> > >
>>>> > > Jim
>>>> > >
>>>> > >
>>>> > > > - Venkat
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > > On 10/7/06, ant elder <an...@gmail.com> wrote:
>>>> > > >>
>>>> > > >> I guess I was thinking that the technology type samples would be
>>>> > > >> the ones
>>>> > > >> that are now moved further down into the folder hierarchy so the
>>>> only
>>>> > > >> thing
>>>> > > >> left up at the top would be the business samples so there wasn't
>>>> > > >> the need
>>>> > > >> for the two folders 'samples' and 'sampleapps' so sampleapps
>>>> might
>>>> > > >> as well
>>>> > > >> just be renamed to samples to keep everything consistent.
>>>> > > >>
>>>> > > >> Please anyone say if they disagree with that. I'd also still
>>>> like
>>>> > > >> to hear
>>>> > > >> comments or suggestions on all this from others who've
>>>> expressed an
>>>> > > >> interest
>>>> > > >> in the samples in the past before I make the changes - Jim ,
>>>> > > >> Rick, Simon?
>>>> > > >>
>>>> > > >> ...ant
>>>> > > >>
>>>> > > >> On 10/6/06, Brent Daniel <br...@gmail.com> wrote:
>>>> > > >> >
>>>> > > >> > Previously we had discussed having a "sampleapps" directory to
>>>> > > >> > distinguish "business samples" from technology samples.[1]
>>>> Do we
>>>> > > >> want
>>>> > > >> > to continue this distinction?
>>>> > > >> >
>>>> > > >> > Brent
>>>> > > >> >
>>>> > > >> >
>>>> > > >> > [1] -
>>>> > > >>
>>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01812.html
>>>> > > >> >
>>>> > > >> > On 10/6/06, ant elder < ant.elder@gmail.com> wrote:
>>>> > > >> > > Ok I think we're getting some agreement but I'd like to be
>>>> clear
>>>> > > >> > everyone
>>>> > > >> > > agrees and is happy before I make any changes. Sounds
>>>> like for
>>>> > > >> things
>>>> > > >> > like
>>>> > > >> > > the Groovy/JavaScript/etc helloworld and calculator type
>>>> > > >> samples they
>>>> > > >> > would
>>>> > > >> > > go with the extension, I'm guessing samples that use just
>>>> sca
>>>> > > >> and java
>>>> > > >> > would
>>>> > > >> > > go in an sca/samples directory. Samples that use multiple
>>>> > > >> extensions
>>>> > > >> but
>>>> > > >> > > still just SCA would also go in the sca/samples
>>>> directory, and
>>>> > > >> there'd
>>>> > > >> > be a
>>>> > > >> > > top level samples directory for things like bigbank that use
>>>> > > >> > sca/sdo/das.
>>>> > > >> > >
>>>> > > >> > > So:
>>>> > > >> > >
>>>> > > >> > > samples/bingbank
>>>> > > >> > > das/samples/companyweb
>>>> > > >> > > sca/samples/calculator
>>>> > > >> > > sca/services/containers/container.javascript/src/samples/
>>>> > > >> calculator
>>>> > > >> > >
>>>> > > >> > > Comments?
>>>> > > >> > >
>>>> > > >> > > ...ant
>>>> > > >> > >
>>>> > > >> > > On 10/5/06, Jim Marino <jmarino@myromatours.com > wrote:
>>>> > > >> > > >
>>>> > > >> > > >
>>>> > > >> > > > On Oct 5, 2006, at 7:14 AM, ant elder wrote:
>>>> > > >> > > >
>>>> > > >> > > > > On 10/5/06, Jeremy Boynes < jboynes@apache.org> wrote:
>>>> > > >> > > > >>
>>>> > > >> > > > >> I think organizing the samples like this is a good
>>>> idea.
>>>> I'd
>>>> > > >> > suggest
>>>> > > >> > > > >> going one step further and place each sample with the
>>>> > > >> > implementation
>>>> > > >> > > > >> of the service that it is illustrating. That way it
>>>> > > >> becomes much
>>>> > > >> > > > >> easier to tag/release each module on its own.
>>>> > > >> > > > >
>>>> > > >> > > > >
>>>> > > >> > > > > I'm not sure I follow "place each sample with the
>>>> > > >> implementation
>>>> > > >> of
>>>> > > >> > > > > the
>>>> > > >> > > > > service that it is illustrating" , do you mean something
>>>> > > >> like:
>>>> > > >> > > > >
>>>> > > >> > > > > samples/helloworld/java
>>>> > > >> > > > > samples/helloworld/javascript
>>>> > > >> > > > > samples/calculator/java
>>>> > > >> > > > > samples/calculator/javascript
>>>> > > >> > > > >
>>>> > > >> > > > > Or do you mean include them with the extension so the
>>>> > > >> JavaScript
>>>> > > >> > > > > folder
>>>> > > >> > > > > would include samples/helloworld and
>>>> samples/calculator? I
>>>> > > >> didn't
>>>> > > >> > > > > think Jim
>>>> > > >> > > > > liked this way, from the previous thread - "In other
>>>> > > >> words, each
>>>> > > >> > > > > sample
>>>> > > >> > > > > project should not be a sibling to the project
>>>> containing
>>>> > > >> extension
>>>> > > >> > > > > code but
>>>> > > >> > > > > should go under a samples folder in separate projects".
>>>> > > >> > > > I was thinking samples for particular extensions would go
>>>> > > >> under the
>>>> > > >> > > > particular extension's directory. For samples that used
>>>> > > >> multiple
>>>> > > >> > > > extensions, they would go under the master samples
>>>> folder. I
>>>> > > >> liked
>>>> > > >> > > > what was done with the calculator where stuff is shared
>>>> between
>>>> > > >> > > > projects (component reuse) so if that structuring won't
>>>> work
>>>> > > >> for re-
>>>> > > >> > > > use I would be fine with what Ant just outlined. My
>>>> preference,
>>>> > >
>>>> > > >> > > > though, would be to group samples with individual
>>>> extensions.
>>>>
>>>> > > >> > > >
>>>> > > >> > > > Jim
>>>> > > >> > > >
>>>> > > >> > > > >
>>>> > > >> > > > > ...ant
>>>> > > >> > > >
>>>> > > >> > > >
>>>> > > >> > > >
>>>> > > >>
>>>> ---------------------------------------------------------------------
>>>> > > >> > > > To unsubscribe, e-mail:
>>>> tuscany-dev-unsubscribe@ws.apache.org
>>>> > > >> > > > For additional commands, e-mail:
>>>> tuscany-dev-help@ws.apache.org
>>>>
>>>> > > >> > > >
>>>> > > >> > > >
>>>> > > >> > >
>>>> > > >> > >
>>>> > > >> >
>>>> > > >> >
>>>> > > >>
>>>> ---------------------------------------------------------------------
>>>> > > >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> > > >> > For additional commands, e-mail:
>>>> tuscany-dev-help@ws.apache.org
>>>> > > >> >
>>>> > > >> >
>>>> > > >>
>>>> > > >>
>>>> > >
>>>> > >
>>>> > >
>>>> ---------------------------------------------------------------------
>>>> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>> > >
>>>> > >
>>>> >
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by Kevin Williams <ke...@qwest.net>.
I agree.
Andy Piper wrote:
> At 15:21 09/10/2006, Jeremy Boynes wrote:
>
>> In many cases building the sample does not actually prove anything as
>> they are not executed. This applies, for example, to the webapp-based
>> samples we have. When they are executed, we still don't know that
>> they run in the end-user environment - e.g. the standalone samples
>> that run from SCATestCase but which fail to run from the launcher.
>>
>> Where they should be built/run is as part of an integration test
>> suite. We don't have that ATM.
>
>
> Better samples that build and don't run than samples that don't build
> at all IMO.
>
> andy
> _______________________________________________________________________
> Notice: This email message, together with any attachments, may contain
> information of BEA Systems, Inc., its subsidiaries and affiliated
> entities, that may be confidential, proprietary, copyrighted and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by Simon Nash <na...@hursley.ibm.com>.
Jeremy,
I understand the reasoning (thanks for restating it) and as I
said, this is a good long term goal. The question had been
raised (not by you) about whether or not the samples should
continue to be built as part of the regular build, and I was
responding to that discussion.
Simon
Jeremy Boynes wrote:
> And where was I advocating that? I was *pointing out the reasoning*
> which was Rick's question so helpfully cut from this thread.
> Sorry for trying to be helpful, I'll shut up now.
> --
> Jeremy
>
> On Oct 9, 2006, at 8:37 AM, Simon Nash wrote:
>
>> I agree with Andy. An integration test framework ro build and
>> run the samples is the right long term solution, but until we have
>> that framework, we should not remove building the samples from
>> the regular build.
>>
>> Simon
>>
>> Jeremy Boynes wrote:
>>
>>> I was pointing out the reasoning behind (which is what Rick asked)
>>> which should be fairly well known given the number of times we have
>>> had this particular discussion.
>>> IMO we need integration tests that pass. That would include testing
>>> the samples. Given the resources required to run real integration
>>> tests it is impractical to run them as part of a developer build.
>>> They should run on a ongoing basis, perhaps using a framework like
>>> Continuum.
>>> A plea to everyone - let's not rehash this all over again unless
>>> something has changed to make it a productive discussion.
>>> --
>>> Jeremy
>>> On Oct 9, 2006, at 7:28 AM, Andy Piper wrote:
>>>
>>>> At 15:21 09/10/2006, Jeremy Boynes wrote:
>>>>
>>>>> In many cases building the sample does not actually prove anything as
>>>>> they are not executed. This applies, for example, to the webapp- based
>>>>> samples we have. When they are executed, we still don't know that
>>>>> they run in the end-user environment - e.g. the standalone samples
>>>>> that run from SCATestCase but which fail to run from the launcher.
>>>>>
>>>>> Where they should be built/run is as part of an integration test
>>>>> suite. We don't have that ATM.
>>>>
>>>>
>>>>
>>>> Better samples that build and don't run than samples that don't
>>>> build at all IMO.
>>>>
>>>> andy
>>>> ____________________________________________________________________
>>>> __ _
>>>> Notice: This email message, together with any attachments, may
>>>> contain
>>>> information of BEA Systems, Inc., its subsidiaries and
>>>> affiliated
>>>> entities, that may be confidential, proprietary, copyrighted
>>>> and/or
>>>> legally privileged, and is intended solely for the use of the
>>>> individual
>>>> or entity named in this message. If you are not the intended
>>>> recipient,
>>>> and have received this message in error, please immediately return
>>>> this
>>>> by email and then delete it.
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
--
Simon C Nash IBM Distinguished Engineer
Hursley Park, Winchester, UK nash@hursley.ibm.com
Tel. +44-1962-815156 Fax +44-1962-818999
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by Jeremy Boynes <jb...@apache.org>.
And where was I advocating that? I was *pointing out the reasoning*
which was Rick's question so helpfully cut from this thread.
Sorry for trying to be helpful, I'll shut up now.
--
Jeremy
On Oct 9, 2006, at 8:37 AM, Simon Nash wrote:
> I agree with Andy. An integration test framework ro build and
> run the samples is the right long term solution, but until we have
> that framework, we should not remove building the samples from
> the regular build.
>
> Simon
>
> Jeremy Boynes wrote:
>> I was pointing out the reasoning behind (which is what Rick
>> asked) which should be fairly well known given the number of
>> times we have had this particular discussion.
>> IMO we need integration tests that pass. That would include
>> testing the samples. Given the resources required to run real
>> integration tests it is impractical to run them as part of a
>> developer build. They should run on a ongoing basis, perhaps
>> using a framework like Continuum.
>> A plea to everyone - let's not rehash this all over again unless
>> something has changed to make it a productive discussion.
>> --
>> Jeremy
>> On Oct 9, 2006, at 7:28 AM, Andy Piper wrote:
>>> At 15:21 09/10/2006, Jeremy Boynes wrote:
>>>
>>>> In many cases building the sample does not actually prove
>>>> anything as
>>>> they are not executed. This applies, for example, to the webapp-
>>>> based
>>>> samples we have. When they are executed, we still don't know that
>>>> they run in the end-user environment - e.g. the standalone samples
>>>> that run from SCATestCase but which fail to run from the launcher.
>>>>
>>>> Where they should be built/run is as part of an integration test
>>>> suite. We don't have that ATM.
>>>
>>>
>>> Better samples that build and don't run than samples that don't
>>> build at all IMO.
>>>
>>> andy
>>> ____________________________________________________________________
>>> __ _
>>> Notice: This email message, together with any attachments, may
>>> contain
>>> information of BEA Systems, Inc., its subsidiaries and
>>> affiliated
>>> entities, that may be confidential, proprietary, copyrighted
>>> and/or
>>> legally privileged, and is intended solely for the use of the
>>> individual
>>> or entity named in this message. If you are not the intended
>>> recipient,
>>> and have received this message in error, please immediately
>>> return this
>>> by email and then delete it.
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by Jim Marino <jm...@myromatours.com>.
On Oct 9, 2006, at 8:37 AM, Simon Nash wrote:
> I agree with Andy. An integration test framework ro build and
> run the samples is the right long term solution, but until we have
> that framework, we should not remove building the samples from
> the regular build.
The samples are not part of the "regular" build, they are part of the
root one. The root build should never have to be run for a checkin of
Java SCA as it includes SDO and DAS, which we agreed should not be
required by the former for modularity.
I'm not going to rehash old ground but I will state that we need an
integration test framework run as part of a continuous integration
process that will include samples testing but goes well beyond that.
In addition, the check-in build should contain test cases that verify
basic things like bootstrapping (standalone, webapp); this can all be
done using EasyMock without the need for code to execute in-
container. The reason the samples are breaking is not because we
don't run them as part of the build, it's because our basic test
coverage is lacking.
I propose we work to resolve this by the following:
1. Put testcases that verify bootstrapping in the checkin build.
these should only use EasyMock and not run any containers (e.g. Jetty)
2. Move to a continuous integration framework, perhaps Continuum.
These tests should
- Run the samples in a number of container hosts we support (Tomcat,
Jetty, Standalone, etc.)
- Perform a deeper level of integration tests between various
subsystems, such as wiring between component implementation types,
interop testing, etc.
- Be run periodically. We may eventually want to break them into
parts. Some which run every 15 minutes or so, others (more resource
intensive) which run around twice a day
I'm willing to help out if there are some volunteers. Any volunteers?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by Simon Nash <na...@hursley.ibm.com>.
I agree with Andy. An integration test framework ro build and
run the samples is the right long term solution, but until we have
that framework, we should not remove building the samples from
the regular build.
Simon
Jeremy Boynes wrote:
> I was pointing out the reasoning behind (which is what Rick asked)
> which should be fairly well known given the number of times we have had
> this particular discussion.
>
> IMO we need integration tests that pass. That would include testing the
> samples. Given the resources required to run real integration tests it
> is impractical to run them as part of a developer build. They should
> run on a ongoing basis, perhaps using a framework like Continuum.
>
> A plea to everyone - let's not rehash this all over again unless
> something has changed to make it a productive discussion.
> --
> Jeremy
>
> On Oct 9, 2006, at 7:28 AM, Andy Piper wrote:
>
>> At 15:21 09/10/2006, Jeremy Boynes wrote:
>>
>>> In many cases building the sample does not actually prove anything as
>>> they are not executed. This applies, for example, to the webapp-based
>>> samples we have. When they are executed, we still don't know that
>>> they run in the end-user environment - e.g. the standalone samples
>>> that run from SCATestCase but which fail to run from the launcher.
>>>
>>> Where they should be built/run is as part of an integration test
>>> suite. We don't have that ATM.
>>
>>
>> Better samples that build and don't run than samples that don't build
>> at all IMO.
>>
>> andy
>> ______________________________________________________________________ _
>> Notice: This email message, together with any attachments, may contain
>> information of BEA Systems, Inc., its subsidiaries and affiliated
>> entities, that may be confidential, proprietary, copyrighted and/or
>> legally privileged, and is intended solely for the use of the individual
>> or entity named in this message. If you are not the intended recipient,
>> and have received this message in error, please immediately return this
>> by email and then delete it.
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by Jeremy Boynes <jb...@apache.org>.
I was pointing out the reasoning behind (which is what Rick asked)
which should be fairly well known given the number of times we have
had this particular discussion.
IMO we need integration tests that pass. That would include testing
the samples. Given the resources required to run real integration
tests it is impractical to run them as part of a developer build.
They should run on a ongoing basis, perhaps using a framework like
Continuum.
A plea to everyone - let's not rehash this all over again unless
something has changed to make it a productive discussion.
--
Jeremy
On Oct 9, 2006, at 7:28 AM, Andy Piper wrote:
> At 15:21 09/10/2006, Jeremy Boynes wrote:
>> In many cases building the sample does not actually prove anything as
>> they are not executed. This applies, for example, to the webapp-based
>> samples we have. When they are executed, we still don't know that
>> they run in the end-user environment - e.g. the standalone samples
>> that run from SCATestCase but which fail to run from the launcher.
>>
>> Where they should be built/run is as part of an integration test
>> suite. We don't have that ATM.
>
> Better samples that build and don't run than samples that don't
> build at all IMO.
>
> andy
> ______________________________________________________________________
> _
> Notice: This email message, together with any attachments, may
> contain
> information of BEA Systems, Inc., its subsidiaries and
> affiliated
> entities, that may be confidential, proprietary, copyrighted
> and/or
> legally privileged, and is intended solely for the use of the
> individual
> or entity named in this message. If you are not the intended
> recipient,
> and have received this message in error, please immediately return
> this
> by email and then delete it.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by Andy Piper <an...@bea.com>.
At 15:21 09/10/2006, Jeremy Boynes wrote:
>In many cases building the sample does not actually prove anything as
>they are not executed. This applies, for example, to the webapp-based
>samples we have. When they are executed, we still don't know that
>they run in the end-user environment - e.g. the standalone samples
>that run from SCATestCase but which fail to run from the launcher.
>
>Where they should be built/run is as part of an integration test
>suite. We don't have that ATM.
Better samples that build and don't run than samples that don't build
at all IMO.
andy
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by Jeremy Boynes <jb...@apache.org>.
In many cases building the sample does not actually prove anything as
they are not executed. This applies, for example, to the webapp-based
samples we have. When they are executed, we still don't know that
they run in the end-user environment - e.g. the standalone samples
that run from SCATestCase but which fail to run from the launcher.
Where they should be built/run is as part of an integration test
suite. We don't have that ATM.
--
Jeremy
On Oct 9, 2006, at 7:12 AM, Rick wrote:
> What is the reasoning behind not wanting to build samples? You can
> always go in a subdir while developing and only re-build a
> particular extension or the core. I'm worried that this will lead
> the samples to go out of date.
>
> ant elder wrote:
>> A final part of this is how the samples get built. One thing Jim
>> wanted was
>> for the samples to not get built with a regular build. If there's
>> a (or
>> some?) sample in
>> sca/services/containers/container.javascript/src/samples/
>> calculator how does
>> that fit in with the maven build?
>> ...ant
>> On 10/9/06, Venkata Krishnan <fo...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> So can we finalize on this and start moving the samples. While
>>> doing this
>>>
>>> can we also do the following: -
>>>
>>> - Go up to the wiki
>>> http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2Tasks#preview and
>>> update
>>> the
>>> samples section
>>> - If the sample is tried and includes a readme that explains how
>>> to go
>>> about
>>> setting it up and running it mark the sample as complete.
>>> - If there are issues related to the sample, please update the
>>> issues that
>>>
>>> are pending or being worked upon.
>>>
>>> Thoughts ?
>>>
>>> - Venkat
>>>
>>> On 10/8/06, Venkata Krishnan <fo...@gmail.com> wrote:
>>> >
>>> > Yes Jim.. so that the pattern is clear to the user. i.e the
>>> user would
>>> > see and feel in the samples at a particular level, only those
>>> features
>>> that
>>> > exist at that level.
>>> >
>>> > For example a user could get a feel of individual extensions
>>> from the
>>> > various samples, be able to digest them and then move out to
>>> the SCA
>>> level
>>> > to get a feel of how the extensions could be combined. Then
>>> moving
>>> futher
>>> > out to the base wherein the samples there demonstrate the roles
>>> of SCA,
>>> SDO
>>> > and DAS in providing uniform service access, data proecessing
>>> and data
>>> > access mechanism for SOA based applications.
>>> >
>>> > - Venkat
>>> >
>>> > On 10/8/06, Jim Marino < jmarino@myromatours.com> wrote:
>>> > >
>>> > >
>>> > > On Oct 7, 2006, at 10:01 AM, Venkata Krishnan wrote:
>>> > >
>>> > > > Hi,
>>> > > >
>>> > > > I'd prefer to have business samples under 'samples' itself. I
>>> > > > perceive that
>>> > > > technology samples will go to the respective project
>>> directories
>>> > > > and all
>>> > > > others are to demonstrate the cool things of combining
>>> containers,
>>> > > > transports - the integration story and they would all get
>>> under
>>> > > > samples i.e.
>>> > > > samples/BigBang, samples/SupplyChain .. and so on.
>>> > > >
>>> > > I want to check that we are saying the same thing. Here is
>>> what I
>>> > > understand the proposed structuring to be:
>>> > >
>>> > > > samples/bingbank
>>> > > > > > das/samples/companyweb
>>> > > > > > sca/samples/calculator
>>> > > > > > sca/services/containers/container.javascript/src/samples/
>>> > > > calculator
>>> > >
>>> > > To me this means:
>>> > >
>>> > > 1. Samples which are designed to illustrate multiple Tuscany
>>> sub-
>>> > > projects (SCA/SDO/DAS) working together go under java/
>>> samples. These
>>> > > are generally "applications" or as some people like to refer
>>> to them
>>> > > "business samples"
>>> > >
>>> > > 2. Samples which are applications that are designed to
>>> illustrate one
>>> > > Tuscany sub-project go under their respective sub-project
>>> samples
>>> > > directory. For example, das/samples/companyweb or sca/samples/
>>> bigbank
>>> > > for a version of BigBank that only uses SCA.
>>> > >
>>> > > 3. SCA samples that illustrate a particular Java SCA runtime
>>> > > extension go in a samples folder under the extension, e.g. sca/
>>> > > services/containers/container.javascript/src/samples/
>>> calculator. SDO
>>> > > and DAS may choose to follow a similar scheme if it makes
>>> sense for
>>> > > those projects.
>>> > >
>>> > > Does that align with what you are saying?
>>> > >
>>> > > Jim
>>> > >
>>> > >
>>> > > > - Venkat
>>> > > >
>>> > > >
>>> > > >
>>> > > > On 10/7/06, ant elder <an...@gmail.com> wrote:
>>> > > >>
>>> > > >> I guess I was thinking that the technology type samples
>>> would be
>>> > > >> the ones
>>> > > >> that are now moved further down into the folder hierarchy
>>> so the
>>> only
>>> > > >> thing
>>> > > >> left up at the top would be the business samples so there
>>> wasn't
>>> > > >> the need
>>> > > >> for the two folders 'samples' and 'sampleapps' so
>>> sampleapps might
>>> > > >> as well
>>> > > >> just be renamed to samples to keep everything consistent.
>>> > > >>
>>> > > >> Please anyone say if they disagree with that. I'd also
>>> still like
>>> > > >> to hear
>>> > > >> comments or suggestions on all this from others who've
>>> expressed an
>>> > > >> interest
>>> > > >> in the samples in the past before I make the changes - Jim ,
>>> > > >> Rick, Simon?
>>> > > >>
>>> > > >> ...ant
>>> > > >>
>>> > > >> On 10/6/06, Brent Daniel <br...@gmail.com> wrote:
>>> > > >> >
>>> > > >> > Previously we had discussed having a "sampleapps"
>>> directory to
>>> > > >> > distinguish "business samples" from technology samples.
>>> [1] Do we
>>> > > >> want
>>> > > >> > to continue this distinction?
>>> > > >> >
>>> > > >> > Brent
>>> > > >> >
>>> > > >> >
>>> > > >> > [1] -
>>> > > >> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>>> msg01812.html
>>> > > >> >
>>> > > >> > On 10/6/06, ant elder < ant.elder@gmail.com> wrote:
>>> > > >> > > Ok I think we're getting some agreement but I'd like
>>> to be
>>> clear
>>> > > >> > everyone
>>> > > >> > > agrees and is happy before I make any changes. Sounds
>>> like for
>>> > > >> things
>>> > > >> > like
>>> > > >> > > the Groovy/JavaScript/etc helloworld and calculator type
>>> > > >> samples they
>>> > > >> > would
>>> > > >> > > go with the extension, I'm guessing samples that use
>>> just sca
>>> > > >> and java
>>> > > >> > would
>>> > > >> > > go in an sca/samples directory. Samples that use multiple
>>> > > >> extensions
>>> > > >> but
>>> > > >> > > still just SCA would also go in the sca/samples
>>> directory, and
>>> > > >> there'd
>>> > > >> > be a
>>> > > >> > > top level samples directory for things like bigbank
>>> that use
>>> > > >> > sca/sdo/das.
>>> > > >> > >
>>> > > >> > > So:
>>> > > >> > >
>>> > > >> > > samples/bingbank
>>> > > >> > > das/samples/companyweb
>>> > > >> > > sca/samples/calculator
>>> > > >> > > sca/services/containers/container.javascript/src/samples/
>>> > > >> calculator
>>> > > >> > >
>>> > > >> > > Comments?
>>> > > >> > >
>>> > > >> > > ...ant
>>> > > >> > >
>>> > > >> > > On 10/5/06, Jim Marino <jmarino@myromatours.com > wrote:
>>> > > >> > > >
>>> > > >> > > >
>>> > > >> > > > On Oct 5, 2006, at 7:14 AM, ant elder wrote:
>>> > > >> > > >
>>> > > >> > > > > On 10/5/06, Jeremy Boynes < jboynes@apache.org>
>>> wrote:
>>> > > >> > > > >>
>>> > > >> > > > >> I think organizing the samples like this is a
>>> good idea.
>>> I'd
>>> > > >> > suggest
>>> > > >> > > > >> going one step further and place each sample with
>>> the
>>> > > >> > implementation
>>> > > >> > > > >> of the service that it is illustrating. That way it
>>> > > >> becomes much
>>> > > >> > > > >> easier to tag/release each module on its own.
>>> > > >> > > > >
>>> > > >> > > > >
>>> > > >> > > > > I'm not sure I follow "place each sample with the
>>> > > >> implementation
>>> > > >> of
>>> > > >> > > > > the
>>> > > >> > > > > service that it is illustrating" , do you mean
>>> something
>>> > > >> like:
>>> > > >> > > > >
>>> > > >> > > > > samples/helloworld/java
>>> > > >> > > > > samples/helloworld/javascript
>>> > > >> > > > > samples/calculator/java
>>> > > >> > > > > samples/calculator/javascript
>>> > > >> > > > >
>>> > > >> > > > > Or do you mean include them with the extension so the
>>> > > >> JavaScript
>>> > > >> > > > > folder
>>> > > >> > > > > would include samples/helloworld and samples/
>>> calculator? I
>>> > > >> didn't
>>> > > >> > > > > think Jim
>>> > > >> > > > > liked this way, from the previous thread - "In other
>>> > > >> words, each
>>> > > >> > > > > sample
>>> > > >> > > > > project should not be a sibling to the project
>>> containing
>>> > > >> extension
>>> > > >> > > > > code but
>>> > > >> > > > > should go under a samples folder in separate
>>> projects".
>>> > > >> > > > I was thinking samples for particular extensions
>>> would go
>>> > > >> under the
>>> > > >> > > > particular extension's directory. For samples that used
>>> > > >> multiple
>>> > > >> > > > extensions, they would go under the master samples
>>> folder. I
>>> > > >> liked
>>> > > >> > > > what was done with the calculator where stuff is shared
>>> between
>>> > > >> > > > projects (component reuse) so if that structuring
>>> won't work
>>> > > >> for re-
>>> > > >> > > > use I would be fine with what Ant just outlined. My
>>> preference,
>>> > >
>>> > > >> > > > though, would be to group samples with individual
>>> extensions.
>>>
>>> > > >> > > >
>>> > > >> > > > Jim
>>> > > >> > > >
>>> > > >> > > > >
>>> > > >> > > > > ...ant
>>> > > >> > > >
>>> > > >> > > >
>>> > > >> > > >
>>> > > >>
>>> --------------------------------------------------------------------
>>> -
>>> > > >> > > > To unsubscribe, e-mail: tuscany-dev-
>>> unsubscribe@ws.apache.org
>>> > > >> > > > For additional commands, e-mail: tuscany-dev-
>>> help@ws.apache.org
>>>
>>> > > >> > > >
>>> > > >> > > >
>>> > > >> > >
>>> > > >> > >
>>> > > >> >
>>> > > >> >
>>> > > >>
>>> --------------------------------------------------------------------
>>> -
>>> > > >> > To unsubscribe, e-mail: tuscany-dev-
>>> unsubscribe@ws.apache.org
>>> > > >> > For additional commands, e-mail: tuscany-dev-
>>> help@ws.apache.org
>>> > > >> >
>>> > > >> >
>>> > > >>
>>> > > >>
>>> > >
>>> > >
>>> > >
>>> --------------------------------------------------------------------
>>> -
>>> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>> > >
>>> > >
>>> >
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by Rick <cr...@gmail.com>.
What is the reasoning behind not wanting to build samples? You can always go in
a subdir while developing and only re-build a particular extension or the core.
I'm worried that this will lead the samples to go out of date.
ant elder wrote:
> A final part of this is how the samples get built. One thing Jim wanted was
> for the samples to not get built with a regular build. If there's a (or
> some?) sample in
> sca/services/containers/container.javascript/src/samples/calculator how
> does
> that fit in with the maven build?
>
> ...ant
>
> On 10/9/06, Venkata Krishnan <fo...@gmail.com> wrote:
>>
>> Hi,
>>
>> So can we finalize on this and start moving the samples. While doing
>> this
>>
>> can we also do the following: -
>>
>> - Go up to the wiki
>> http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2Tasks#preview and update
>> the
>> samples section
>> - If the sample is tried and includes a readme that explains how to go
>> about
>> setting it up and running it mark the sample as complete.
>> - If there are issues related to the sample, please update the issues
>> that
>>
>> are pending or being worked upon.
>>
>> Thoughts ?
>>
>> - Venkat
>>
>> On 10/8/06, Venkata Krishnan <fo...@gmail.com> wrote:
>> >
>> > Yes Jim.. so that the pattern is clear to the user. i.e the user
>> would
>> > see and feel in the samples at a particular level, only those features
>> that
>> > exist at that level.
>> >
>> > For example a user could get a feel of individual extensions from the
>> > various samples, be able to digest them and then move out to the SCA
>> level
>> > to get a feel of how the extensions could be combined. Then moving
>> futher
>> > out to the base wherein the samples there demonstrate the roles of SCA,
>> SDO
>> > and DAS in providing uniform service access, data proecessing and data
>> > access mechanism for SOA based applications.
>> >
>> > - Venkat
>> >
>> > On 10/8/06, Jim Marino < jmarino@myromatours.com> wrote:
>> > >
>> > >
>> > > On Oct 7, 2006, at 10:01 AM, Venkata Krishnan wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > I'd prefer to have business samples under 'samples' itself. I
>> > > > perceive that
>> > > > technology samples will go to the respective project directories
>> > > > and all
>> > > > others are to demonstrate the cool things of combining containers,
>> > > > transports - the integration story and they would all get under
>> > > > samples i.e.
>> > > > samples/BigBang, samples/SupplyChain .. and so on.
>> > > >
>> > > I want to check that we are saying the same thing. Here is what I
>> > > understand the proposed structuring to be:
>> > >
>> > > > samples/bingbank
>> > > > > > das/samples/companyweb
>> > > > > > sca/samples/calculator
>> > > > > > sca/services/containers/container.javascript/src/samples/
>> > > > calculator
>> > >
>> > > To me this means:
>> > >
>> > > 1. Samples which are designed to illustrate multiple Tuscany sub-
>> > > projects (SCA/SDO/DAS) working together go under java/samples. These
>> > > are generally "applications" or as some people like to refer to them
>> > > "business samples"
>> > >
>> > > 2. Samples which are applications that are designed to illustrate one
>> > > Tuscany sub-project go under their respective sub-project samples
>> > > directory. For example, das/samples/companyweb or sca/samples/bigbank
>> > > for a version of BigBank that only uses SCA.
>> > >
>> > > 3. SCA samples that illustrate a particular Java SCA runtime
>> > > extension go in a samples folder under the extension, e.g. sca/
>> > > services/containers/container.javascript/src/samples/calculator. SDO
>> > > and DAS may choose to follow a similar scheme if it makes sense for
>> > > those projects.
>> > >
>> > > Does that align with what you are saying?
>> > >
>> > > Jim
>> > >
>> > >
>> > > > - Venkat
>> > > >
>> > > >
>> > > >
>> > > > On 10/7/06, ant elder <an...@gmail.com> wrote:
>> > > >>
>> > > >> I guess I was thinking that the technology type samples would be
>> > > >> the ones
>> > > >> that are now moved further down into the folder hierarchy so the
>> only
>> > > >> thing
>> > > >> left up at the top would be the business samples so there wasn't
>> > > >> the need
>> > > >> for the two folders 'samples' and 'sampleapps' so sampleapps might
>> > > >> as well
>> > > >> just be renamed to samples to keep everything consistent.
>> > > >>
>> > > >> Please anyone say if they disagree with that. I'd also still like
>> > > >> to hear
>> > > >> comments or suggestions on all this from others who've
>> expressed an
>> > > >> interest
>> > > >> in the samples in the past before I make the changes - Jim ,
>> > > >> Rick, Simon?
>> > > >>
>> > > >> ...ant
>> > > >>
>> > > >> On 10/6/06, Brent Daniel <br...@gmail.com> wrote:
>> > > >> >
>> > > >> > Previously we had discussed having a "sampleapps" directory to
>> > > >> > distinguish "business samples" from technology samples.[1] Do we
>> > > >> want
>> > > >> > to continue this distinction?
>> > > >> >
>> > > >> > Brent
>> > > >> >
>> > > >> >
>> > > >> > [1] -
>> > > >>
>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01812.html
>> > > >> >
>> > > >> > On 10/6/06, ant elder < ant.elder@gmail.com> wrote:
>> > > >> > > Ok I think we're getting some agreement but I'd like to be
>> clear
>> > > >> > everyone
>> > > >> > > agrees and is happy before I make any changes. Sounds like for
>> > > >> things
>> > > >> > like
>> > > >> > > the Groovy/JavaScript/etc helloworld and calculator type
>> > > >> samples they
>> > > >> > would
>> > > >> > > go with the extension, I'm guessing samples that use just sca
>> > > >> and java
>> > > >> > would
>> > > >> > > go in an sca/samples directory. Samples that use multiple
>> > > >> extensions
>> > > >> but
>> > > >> > > still just SCA would also go in the sca/samples directory, and
>> > > >> there'd
>> > > >> > be a
>> > > >> > > top level samples directory for things like bigbank that use
>> > > >> > sca/sdo/das.
>> > > >> > >
>> > > >> > > So:
>> > > >> > >
>> > > >> > > samples/bingbank
>> > > >> > > das/samples/companyweb
>> > > >> > > sca/samples/calculator
>> > > >> > > sca/services/containers/container.javascript/src/samples/
>> > > >> calculator
>> > > >> > >
>> > > >> > > Comments?
>> > > >> > >
>> > > >> > > ...ant
>> > > >> > >
>> > > >> > > On 10/5/06, Jim Marino <jmarino@myromatours.com > wrote:
>> > > >> > > >
>> > > >> > > >
>> > > >> > > > On Oct 5, 2006, at 7:14 AM, ant elder wrote:
>> > > >> > > >
>> > > >> > > > > On 10/5/06, Jeremy Boynes < jboynes@apache.org> wrote:
>> > > >> > > > >>
>> > > >> > > > >> I think organizing the samples like this is a good idea.
>> I'd
>> > > >> > suggest
>> > > >> > > > >> going one step further and place each sample with the
>> > > >> > implementation
>> > > >> > > > >> of the service that it is illustrating. That way it
>> > > >> becomes much
>> > > >> > > > >> easier to tag/release each module on its own.
>> > > >> > > > >
>> > > >> > > > >
>> > > >> > > > > I'm not sure I follow "place each sample with the
>> > > >> implementation
>> > > >> of
>> > > >> > > > > the
>> > > >> > > > > service that it is illustrating" , do you mean something
>> > > >> like:
>> > > >> > > > >
>> > > >> > > > > samples/helloworld/java
>> > > >> > > > > samples/helloworld/javascript
>> > > >> > > > > samples/calculator/java
>> > > >> > > > > samples/calculator/javascript
>> > > >> > > > >
>> > > >> > > > > Or do you mean include them with the extension so the
>> > > >> JavaScript
>> > > >> > > > > folder
>> > > >> > > > > would include samples/helloworld and samples/calculator? I
>> > > >> didn't
>> > > >> > > > > think Jim
>> > > >> > > > > liked this way, from the previous thread - "In other
>> > > >> words, each
>> > > >> > > > > sample
>> > > >> > > > > project should not be a sibling to the project containing
>> > > >> extension
>> > > >> > > > > code but
>> > > >> > > > > should go under a samples folder in separate projects".
>> > > >> > > > I was thinking samples for particular extensions would go
>> > > >> under the
>> > > >> > > > particular extension's directory. For samples that used
>> > > >> multiple
>> > > >> > > > extensions, they would go under the master samples folder. I
>> > > >> liked
>> > > >> > > > what was done with the calculator where stuff is shared
>> between
>> > > >> > > > projects (component reuse) so if that structuring won't work
>> > > >> for re-
>> > > >> > > > use I would be fine with what Ant just outlined. My
>> preference,
>> > >
>> > > >> > > > though, would be to group samples with individual
>> extensions.
>>
>> > > >> > > >
>> > > >> > > > Jim
>> > > >> > > >
>> > > >> > > > >
>> > > >> > > > > ...ant
>> > > >> > > >
>> > > >> > > >
>> > > >> > > >
>> > > >>
>> ---------------------------------------------------------------------
>> > > >> > > > To unsubscribe, e-mail:
>> tuscany-dev-unsubscribe@ws.apache.org
>> > > >> > > > For additional commands, e-mail:
>> tuscany-dev-help@ws.apache.org
>>
>> > > >> > > >
>> > > >> > > >
>> > > >> > >
>> > > >> > >
>> > > >> >
>> > > >> >
>> > > >>
>> ---------------------------------------------------------------------
>> > > >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > > >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> > > >> >
>> > > >> >
>> > > >>
>> > > >>
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> > >
>> > >
>> >
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by ant elder <an...@gmail.com>.
A final part of this is how the samples get built. One thing Jim wanted was
for the samples to not get built with a regular build. If there's a (or
some?) sample in
sca/services/containers/container.javascript/src/samples/calculator how does
that fit in with the maven build?
...ant
On 10/9/06, Venkata Krishnan <fo...@gmail.com> wrote:
>
> Hi,
>
> So can we finalize on this and start moving the samples. While doing this
>
> can we also do the following: -
>
> - Go up to the wiki
> http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2Tasks#preview and update
> the
> samples section
> - If the sample is tried and includes a readme that explains how to go
> about
> setting it up and running it mark the sample as complete.
> - If there are issues related to the sample, please update the issues that
>
> are pending or being worked upon.
>
> Thoughts ?
>
> - Venkat
>
> On 10/8/06, Venkata Krishnan <fo...@gmail.com> wrote:
> >
> > Yes Jim.. so that the pattern is clear to the user. i.e the user would
> > see and feel in the samples at a particular level, only those features
> that
> > exist at that level.
> >
> > For example a user could get a feel of individual extensions from the
> > various samples, be able to digest them and then move out to the SCA
> level
> > to get a feel of how the extensions could be combined. Then moving
> futher
> > out to the base wherein the samples there demonstrate the roles of SCA,
> SDO
> > and DAS in providing uniform service access, data proecessing and data
> > access mechanism for SOA based applications.
> >
> > - Venkat
> >
> > On 10/8/06, Jim Marino < jmarino@myromatours.com> wrote:
> > >
> > >
> > > On Oct 7, 2006, at 10:01 AM, Venkata Krishnan wrote:
> > >
> > > > Hi,
> > > >
> > > > I'd prefer to have business samples under 'samples' itself. I
> > > > perceive that
> > > > technology samples will go to the respective project directories
> > > > and all
> > > > others are to demonstrate the cool things of combining containers,
> > > > transports - the integration story and they would all get under
> > > > samples i.e.
> > > > samples/BigBang, samples/SupplyChain .. and so on.
> > > >
> > > I want to check that we are saying the same thing. Here is what I
> > > understand the proposed structuring to be:
> > >
> > > > samples/bingbank
> > > > > > das/samples/companyweb
> > > > > > sca/samples/calculator
> > > > > > sca/services/containers/container.javascript/src/samples/
> > > > calculator
> > >
> > > To me this means:
> > >
> > > 1. Samples which are designed to illustrate multiple Tuscany sub-
> > > projects (SCA/SDO/DAS) working together go under java/samples. These
> > > are generally "applications" or as some people like to refer to them
> > > "business samples"
> > >
> > > 2. Samples which are applications that are designed to illustrate one
> > > Tuscany sub-project go under their respective sub-project samples
> > > directory. For example, das/samples/companyweb or sca/samples/bigbank
> > > for a version of BigBank that only uses SCA.
> > >
> > > 3. SCA samples that illustrate a particular Java SCA runtime
> > > extension go in a samples folder under the extension, e.g. sca/
> > > services/containers/container.javascript/src/samples/calculator. SDO
> > > and DAS may choose to follow a similar scheme if it makes sense for
> > > those projects.
> > >
> > > Does that align with what you are saying?
> > >
> > > Jim
> > >
> > >
> > > > - Venkat
> > > >
> > > >
> > > >
> > > > On 10/7/06, ant elder <an...@gmail.com> wrote:
> > > >>
> > > >> I guess I was thinking that the technology type samples would be
> > > >> the ones
> > > >> that are now moved further down into the folder hierarchy so the
> only
> > > >> thing
> > > >> left up at the top would be the business samples so there wasn't
> > > >> the need
> > > >> for the two folders 'samples' and 'sampleapps' so sampleapps might
> > > >> as well
> > > >> just be renamed to samples to keep everything consistent.
> > > >>
> > > >> Please anyone say if they disagree with that. I'd also still like
> > > >> to hear
> > > >> comments or suggestions on all this from others who've expressed an
> > > >> interest
> > > >> in the samples in the past before I make the changes - Jim ,
> > > >> Rick, Simon?
> > > >>
> > > >> ...ant
> > > >>
> > > >> On 10/6/06, Brent Daniel <br...@gmail.com> wrote:
> > > >> >
> > > >> > Previously we had discussed having a "sampleapps" directory to
> > > >> > distinguish "business samples" from technology samples.[1] Do we
> > > >> want
> > > >> > to continue this distinction?
> > > >> >
> > > >> > Brent
> > > >> >
> > > >> >
> > > >> > [1] -
> > > >> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01812.html
> > > >> >
> > > >> > On 10/6/06, ant elder < ant.elder@gmail.com> wrote:
> > > >> > > Ok I think we're getting some agreement but I'd like to be
> clear
> > > >> > everyone
> > > >> > > agrees and is happy before I make any changes. Sounds like for
> > > >> things
> > > >> > like
> > > >> > > the Groovy/JavaScript/etc helloworld and calculator type
> > > >> samples they
> > > >> > would
> > > >> > > go with the extension, I'm guessing samples that use just sca
> > > >> and java
> > > >> > would
> > > >> > > go in an sca/samples directory. Samples that use multiple
> > > >> extensions
> > > >> but
> > > >> > > still just SCA would also go in the sca/samples directory, and
> > > >> there'd
> > > >> > be a
> > > >> > > top level samples directory for things like bigbank that use
> > > >> > sca/sdo/das.
> > > >> > >
> > > >> > > So:
> > > >> > >
> > > >> > > samples/bingbank
> > > >> > > das/samples/companyweb
> > > >> > > sca/samples/calculator
> > > >> > > sca/services/containers/container.javascript/src/samples/
> > > >> calculator
> > > >> > >
> > > >> > > Comments?
> > > >> > >
> > > >> > > ...ant
> > > >> > >
> > > >> > > On 10/5/06, Jim Marino <jmarino@myromatours.com > wrote:
> > > >> > > >
> > > >> > > >
> > > >> > > > On Oct 5, 2006, at 7:14 AM, ant elder wrote:
> > > >> > > >
> > > >> > > > > On 10/5/06, Jeremy Boynes < jboynes@apache.org> wrote:
> > > >> > > > >>
> > > >> > > > >> I think organizing the samples like this is a good idea.
> I'd
> > > >> > suggest
> > > >> > > > >> going one step further and place each sample with the
> > > >> > implementation
> > > >> > > > >> of the service that it is illustrating. That way it
> > > >> becomes much
> > > >> > > > >> easier to tag/release each module on its own.
> > > >> > > > >
> > > >> > > > >
> > > >> > > > > I'm not sure I follow "place each sample with the
> > > >> implementation
> > > >> of
> > > >> > > > > the
> > > >> > > > > service that it is illustrating" , do you mean something
> > > >> like:
> > > >> > > > >
> > > >> > > > > samples/helloworld/java
> > > >> > > > > samples/helloworld/javascript
> > > >> > > > > samples/calculator/java
> > > >> > > > > samples/calculator/javascript
> > > >> > > > >
> > > >> > > > > Or do you mean include them with the extension so the
> > > >> JavaScript
> > > >> > > > > folder
> > > >> > > > > would include samples/helloworld and samples/calculator? I
> > > >> didn't
> > > >> > > > > think Jim
> > > >> > > > > liked this way, from the previous thread - "In other
> > > >> words, each
> > > >> > > > > sample
> > > >> > > > > project should not be a sibling to the project containing
> > > >> extension
> > > >> > > > > code but
> > > >> > > > > should go under a samples folder in separate projects".
> > > >> > > > I was thinking samples for particular extensions would go
> > > >> under the
> > > >> > > > particular extension's directory. For samples that used
> > > >> multiple
> > > >> > > > extensions, they would go under the master samples folder. I
> > > >> liked
> > > >> > > > what was done with the calculator where stuff is shared
> between
> > > >> > > > projects (component reuse) so if that structuring won't work
> > > >> for re-
> > > >> > > > use I would be fine with what Ant just outlined. My
> preference,
> > >
> > > >> > > > though, would be to group samples with individual extensions.
>
> > > >> > > >
> > > >> > > > Jim
> > > >> > > >
> > > >> > > > >
> > > >> > > > > ...ant
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >>
> ---------------------------------------------------------------------
> > > >> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > >> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> >
> > > >> >
> > > >>
> ---------------------------------------------------------------------
> > > >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >> >
> > > >> >
> > > >>
> > > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
>
>
Re: SCA Java samples for M2
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
So can we finalize on this and start moving the samples. While doing this
can we also do the following: -
- Go up to the wiki
http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2Tasks#preview and update the
samples section
- If the sample is tried and includes a readme that explains how to go about
setting it up and running it mark the sample as complete.
- If there are issues related to the sample, please update the issues that
are pending or being worked upon.
Thoughts ?
- Venkat
On 10/8/06, Venkata Krishnan <fo...@gmail.com> wrote:
>
> Yes Jim.. so that the pattern is clear to the user. i.e the user would
> see and feel in the samples at a particular level, only those features that
> exist at that level.
>
> For example a user could get a feel of individual extensions from the
> various samples, be able to digest them and then move out to the SCA level
> to get a feel of how the extensions could be combined. Then moving futher
> out to the base wherein the samples there demonstrate the roles of SCA, SDO
> and DAS in providing uniform service access, data proecessing and data
> access mechanism for SOA based applications.
>
> - Venkat
>
> On 10/8/06, Jim Marino <jm...@myromatours.com> wrote:
> >
> >
> > On Oct 7, 2006, at 10:01 AM, Venkata Krishnan wrote:
> >
> > > Hi,
> > >
> > > I'd prefer to have business samples under 'samples' itself. I
> > > perceive that
> > > technology samples will go to the respective project directories
> > > and all
> > > others are to demonstrate the cool things of combining containers,
> > > transports - the integration story and they would all get under
> > > samples i.e.
> > > samples/BigBang, samples/SupplyChain .. and so on.
> > >
> > I want to check that we are saying the same thing. Here is what I
> > understand the proposed structuring to be:
> >
> > > samples/bingbank
> > > > > das/samples/companyweb
> > > > > sca/samples/calculator
> > > > > sca/services/containers/container.javascript/src/samples/
> > > calculator
> >
> > To me this means:
> >
> > 1. Samples which are designed to illustrate multiple Tuscany sub-
> > projects (SCA/SDO/DAS) working together go under java/samples. These
> > are generally "applications" or as some people like to refer to them
> > "business samples"
> >
> > 2. Samples which are applications that are designed to illustrate one
> > Tuscany sub-project go under their respective sub-project samples
> > directory. For example, das/samples/companyweb or sca/samples/bigbank
> > for a version of BigBank that only uses SCA.
> >
> > 3. SCA samples that illustrate a particular Java SCA runtime
> > extension go in a samples folder under the extension, e.g. sca/
> > services/containers/container.javascript/src/samples/calculator. SDO
> > and DAS may choose to follow a similar scheme if it makes sense for
> > those projects.
> >
> > Does that align with what you are saying?
> >
> > Jim
> >
> >
> > > - Venkat
> > >
> > >
> > >
> > > On 10/7/06, ant elder <an...@gmail.com> wrote:
> > >>
> > >> I guess I was thinking that the technology type samples would be
> > >> the ones
> > >> that are now moved further down into the folder hierarchy so the only
> > >> thing
> > >> left up at the top would be the business samples so there wasn't
> > >> the need
> > >> for the two folders 'samples' and 'sampleapps' so sampleapps might
> > >> as well
> > >> just be renamed to samples to keep everything consistent.
> > >>
> > >> Please anyone say if they disagree with that. I'd also still like
> > >> to hear
> > >> comments or suggestions on all this from others who've expressed an
> > >> interest
> > >> in the samples in the past before I make the changes - Jim ,
> > >> Rick, Simon?
> > >>
> > >> ...ant
> > >>
> > >> On 10/6/06, Brent Daniel <br...@gmail.com> wrote:
> > >> >
> > >> > Previously we had discussed having a "sampleapps" directory to
> > >> > distinguish "business samples" from technology samples.[1] Do we
> > >> want
> > >> > to continue this distinction?
> > >> >
> > >> > Brent
> > >> >
> > >> >
> > >> > [1] -
> > >> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01812.html
> > >> >
> > >> > On 10/6/06, ant elder < ant.elder@gmail.com> wrote:
> > >> > > Ok I think we're getting some agreement but I'd like to be clear
> > >> > everyone
> > >> > > agrees and is happy before I make any changes. Sounds like for
> > >> things
> > >> > like
> > >> > > the Groovy/JavaScript/etc helloworld and calculator type
> > >> samples they
> > >> > would
> > >> > > go with the extension, I'm guessing samples that use just sca
> > >> and java
> > >> > would
> > >> > > go in an sca/samples directory. Samples that use multiple
> > >> extensions
> > >> but
> > >> > > still just SCA would also go in the sca/samples directory, and
> > >> there'd
> > >> > be a
> > >> > > top level samples directory for things like bigbank that use
> > >> > sca/sdo/das.
> > >> > >
> > >> > > So:
> > >> > >
> > >> > > samples/bingbank
> > >> > > das/samples/companyweb
> > >> > > sca/samples/calculator
> > >> > > sca/services/containers/container.javascript/src/samples/
> > >> calculator
> > >> > >
> > >> > > Comments?
> > >> > >
> > >> > > ...ant
> > >> > >
> > >> > > On 10/5/06, Jim Marino <jmarino@myromatours.com > wrote:
> > >> > > >
> > >> > > >
> > >> > > > On Oct 5, 2006, at 7:14 AM, ant elder wrote:
> > >> > > >
> > >> > > > > On 10/5/06, Jeremy Boynes < jboynes@apache.org> wrote:
> > >> > > > >>
> > >> > > > >> I think organizing the samples like this is a good idea. I'd
> > >> > suggest
> > >> > > > >> going one step further and place each sample with the
> > >> > implementation
> > >> > > > >> of the service that it is illustrating. That way it
> > >> becomes much
> > >> > > > >> easier to tag/release each module on its own.
> > >> > > > >
> > >> > > > >
> > >> > > > > I'm not sure I follow "place each sample with the
> > >> implementation
> > >> of
> > >> > > > > the
> > >> > > > > service that it is illustrating" , do you mean something
> > >> like:
> > >> > > > >
> > >> > > > > samples/helloworld/java
> > >> > > > > samples/helloworld/javascript
> > >> > > > > samples/calculator/java
> > >> > > > > samples/calculator/javascript
> > >> > > > >
> > >> > > > > Or do you mean include them with the extension so the
> > >> JavaScript
> > >> > > > > folder
> > >> > > > > would include samples/helloworld and samples/calculator? I
> > >> didn't
> > >> > > > > think Jim
> > >> > > > > liked this way, from the previous thread - "In other
> > >> words, each
> > >> > > > > sample
> > >> > > > > project should not be a sibling to the project containing
> > >> extension
> > >> > > > > code but
> > >> > > > > should go under a samples folder in separate projects".
> > >> > > > I was thinking samples for particular extensions would go
> > >> under the
> > >> > > > particular extension's directory. For samples that used
> > >> multiple
> > >> > > > extensions, they would go under the master samples folder. I
> > >> liked
> > >> > > > what was done with the calculator where stuff is shared between
> > >> > > > projects (component reuse) so if that structuring won't work
> > >> for re-
> > >> > > > use I would be fine with what Ant just outlined. My preference,
> >
> > >> > > > though, would be to group samples with individual extensions.
> > >> > > >
> > >> > > > Jim
> > >> > > >
> > >> > > > >
> > >> > > > > ...ant
> > >> > > >
> > >> > > >
> > >> > > >
> > >> ---------------------------------------------------------------------
> > >> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > >> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >> >
> > >> >
> > >>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
Re: SCA Java samples for M2
Posted by Venkata Krishnan <fo...@gmail.com>.
Yes Jim.. so that the pattern is clear to the user. i.e the user would see
and feel in the samples at a particular level, only those features that
exist at that level.
For example a user could get a feel of individual extensions from the
various samples, be able to digest them and then move out to the SCA level
to get a feel of how the extensions could be combined. Then moving futher
out to the base wherein the samples there demonstrate the roles of SCA, SDO
and DAS in providing uniform service access, data proecessing and data
access mechanism for SOA based applications.
- Venkat
On 10/8/06, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Oct 7, 2006, at 10:01 AM, Venkata Krishnan wrote:
>
> > Hi,
> >
> > I'd prefer to have business samples under 'samples' itself. I
> > perceive that
> > technology samples will go to the respective project directories
> > and all
> > others are to demonstrate the cool things of combining containers,
> > transports - the integration story and they would all get under
> > samples i.e.
> > samples/BigBang, samples/SupplyChain .. and so on.
> >
> I want to check that we are saying the same thing. Here is what I
> understand the proposed structuring to be:
>
> > samples/bingbank
> > > > das/samples/companyweb
> > > > sca/samples/calculator
> > > > sca/services/containers/container.javascript/src/samples/
> > calculator
>
> To me this means:
>
> 1. Samples which are designed to illustrate multiple Tuscany sub-
> projects (SCA/SDO/DAS) working together go under java/samples. These
> are generally "applications" or as some people like to refer to them
> "business samples"
>
> 2. Samples which are applications that are designed to illustrate one
> Tuscany sub-project go under their respective sub-project samples
> directory. For example, das/samples/companyweb or sca/samples/bigbank
> for a version of BigBank that only uses SCA.
>
> 3. SCA samples that illustrate a particular Java SCA runtime
> extension go in a samples folder under the extension, e.g. sca/
> services/containers/container.javascript/src/samples/calculator. SDO
> and DAS may choose to follow a similar scheme if it makes sense for
> those projects.
>
> Does that align with what you are saying?
>
> Jim
>
>
> > - Venkat
> >
> >
> >
> > On 10/7/06, ant elder <an...@gmail.com> wrote:
> >>
> >> I guess I was thinking that the technology type samples would be
> >> the ones
> >> that are now moved further down into the folder hierarchy so the only
> >> thing
> >> left up at the top would be the business samples so there wasn't
> >> the need
> >> for the two folders 'samples' and 'sampleapps' so sampleapps might
> >> as well
> >> just be renamed to samples to keep everything consistent.
> >>
> >> Please anyone say if they disagree with that. I'd also still like
> >> to hear
> >> comments or suggestions on all this from others who've expressed an
> >> interest
> >> in the samples in the past before I make the changes - Jim ,
> >> Rick, Simon?
> >>
> >> ...ant
> >>
> >> On 10/6/06, Brent Daniel <br...@gmail.com> wrote:
> >> >
> >> > Previously we had discussed having a "sampleapps" directory to
> >> > distinguish "business samples" from technology samples.[1] Do we
> >> want
> >> > to continue this distinction?
> >> >
> >> > Brent
> >> >
> >> >
> >> > [1] -
> >> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01812.html
> >> >
> >> > On 10/6/06, ant elder <an...@gmail.com> wrote:
> >> > > Ok I think we're getting some agreement but I'd like to be clear
> >> > everyone
> >> > > agrees and is happy before I make any changes. Sounds like for
> >> things
> >> > like
> >> > > the Groovy/JavaScript/etc helloworld and calculator type
> >> samples they
> >> > would
> >> > > go with the extension, I'm guessing samples that use just sca
> >> and java
> >> > would
> >> > > go in an sca/samples directory. Samples that use multiple
> >> extensions
> >> but
> >> > > still just SCA would also go in the sca/samples directory, and
> >> there'd
> >> > be a
> >> > > top level samples directory for things like bigbank that use
> >> > sca/sdo/das.
> >> > >
> >> > > So:
> >> > >
> >> > > samples/bingbank
> >> > > das/samples/companyweb
> >> > > sca/samples/calculator
> >> > > sca/services/containers/container.javascript/src/samples/
> >> calculator
> >> > >
> >> > > Comments?
> >> > >
> >> > > ...ant
> >> > >
> >> > > On 10/5/06, Jim Marino <jm...@myromatours.com> wrote:
> >> > > >
> >> > > >
> >> > > > On Oct 5, 2006, at 7:14 AM, ant elder wrote:
> >> > > >
> >> > > > > On 10/5/06, Jeremy Boynes <jb...@apache.org> wrote:
> >> > > > >>
> >> > > > >> I think organizing the samples like this is a good idea. I'd
> >> > suggest
> >> > > > >> going one step further and place each sample with the
> >> > implementation
> >> > > > >> of the service that it is illustrating. That way it
> >> becomes much
> >> > > > >> easier to tag/release each module on its own.
> >> > > > >
> >> > > > >
> >> > > > > I'm not sure I follow "place each sample with the
> >> implementation
> >> of
> >> > > > > the
> >> > > > > service that it is illustrating" , do you mean something
> >> like:
> >> > > > >
> >> > > > > samples/helloworld/java
> >> > > > > samples/helloworld/javascript
> >> > > > > samples/calculator/java
> >> > > > > samples/calculator/javascript
> >> > > > >
> >> > > > > Or do you mean include them with the extension so the
> >> JavaScript
> >> > > > > folder
> >> > > > > would include samples/helloworld and samples/calculator? I
> >> didn't
> >> > > > > think Jim
> >> > > > > liked this way, from the previous thread - "In other
> >> words, each
> >> > > > > sample
> >> > > > > project should not be a sibling to the project containing
> >> extension
> >> > > > > code but
> >> > > > > should go under a samples folder in separate projects".
> >> > > > I was thinking samples for particular extensions would go
> >> under the
> >> > > > particular extension's directory. For samples that used
> >> multiple
> >> > > > extensions, they would go under the master samples folder. I
> >> liked
> >> > > > what was done with the calculator where stuff is shared between
> >> > > > projects (component reuse) so if that structuring won't work
> >> for re-
> >> > > > use I would be fine with what Ant just outlined. My preference,
> >> > > > though, would be to group samples with individual extensions.
> >> > > >
> >> > > > Jim
> >> > > >
> >> > > > >
> >> > > > > ...ant
> >> > > >
> >> > > >
> >> > > >
> >> ---------------------------------------------------------------------
> >> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >
> >> >
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: SCA Java samples for M2
Posted by Jim Marino <jm...@myromatours.com>.
On Oct 7, 2006, at 10:01 AM, Venkata Krishnan wrote:
> Hi,
>
> I'd prefer to have business samples under 'samples' itself. I
> perceive that
> technology samples will go to the respective project directories
> and all
> others are to demonstrate the cool things of combining containers,
> transports - the integration story and they would all get under
> samples i.e.
> samples/BigBang, samples/SupplyChain .. and so on.
>
I want to check that we are saying the same thing. Here is what I
understand the proposed structuring to be:
> samples/bingbank
> > > das/samples/companyweb
> > > sca/samples/calculator
> > > sca/services/containers/container.javascript/src/samples/
> calculator
To me this means:
1. Samples which are designed to illustrate multiple Tuscany sub-
projects (SCA/SDO/DAS) working together go under java/samples. These
are generally "applications" or as some people like to refer to them
"business samples"
2. Samples which are applications that are designed to illustrate one
Tuscany sub-project go under their respective sub-project samples
directory. For example, das/samples/companyweb or sca/samples/bigbank
for a version of BigBank that only uses SCA.
3. SCA samples that illustrate a particular Java SCA runtime
extension go in a samples folder under the extension, e.g. sca/
services/containers/container.javascript/src/samples/calculator. SDO
and DAS may choose to follow a similar scheme if it makes sense for
those projects.
Does that align with what you are saying?
Jim
> - Venkat
>
>
>
> On 10/7/06, ant elder <an...@gmail.com> wrote:
>>
>> I guess I was thinking that the technology type samples would be
>> the ones
>> that are now moved further down into the folder hierarchy so the only
>> thing
>> left up at the top would be the business samples so there wasn't
>> the need
>> for the two folders 'samples' and 'sampleapps' so sampleapps might
>> as well
>> just be renamed to samples to keep everything consistent.
>>
>> Please anyone say if they disagree with that. I'd also still like
>> to hear
>> comments or suggestions on all this from others who've expressed an
>> interest
>> in the samples in the past before I make the changes - Jim ,
>> Rick, Simon?
>>
>> ...ant
>>
>> On 10/6/06, Brent Daniel <br...@gmail.com> wrote:
>> >
>> > Previously we had discussed having a "sampleapps" directory to
>> > distinguish "business samples" from technology samples.[1] Do we
>> want
>> > to continue this distinction?
>> >
>> > Brent
>> >
>> >
>> > [1] -
>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01812.html
>> >
>> > On 10/6/06, ant elder <an...@gmail.com> wrote:
>> > > Ok I think we're getting some agreement but I'd like to be clear
>> > everyone
>> > > agrees and is happy before I make any changes. Sounds like for
>> things
>> > like
>> > > the Groovy/JavaScript/etc helloworld and calculator type
>> samples they
>> > would
>> > > go with the extension, I'm guessing samples that use just sca
>> and java
>> > would
>> > > go in an sca/samples directory. Samples that use multiple
>> extensions
>> but
>> > > still just SCA would also go in the sca/samples directory, and
>> there'd
>> > be a
>> > > top level samples directory for things like bigbank that use
>> > sca/sdo/das.
>> > >
>> > > So:
>> > >
>> > > samples/bingbank
>> > > das/samples/companyweb
>> > > sca/samples/calculator
>> > > sca/services/containers/container.javascript/src/samples/
>> calculator
>> > >
>> > > Comments?
>> > >
>> > > ...ant
>> > >
>> > > On 10/5/06, Jim Marino <jm...@myromatours.com> wrote:
>> > > >
>> > > >
>> > > > On Oct 5, 2006, at 7:14 AM, ant elder wrote:
>> > > >
>> > > > > On 10/5/06, Jeremy Boynes <jb...@apache.org> wrote:
>> > > > >>
>> > > > >> I think organizing the samples like this is a good idea. I'd
>> > suggest
>> > > > >> going one step further and place each sample with the
>> > implementation
>> > > > >> of the service that it is illustrating. That way it
>> becomes much
>> > > > >> easier to tag/release each module on its own.
>> > > > >
>> > > > >
>> > > > > I'm not sure I follow "place each sample with the
>> implementation
>> of
>> > > > > the
>> > > > > service that it is illustrating" , do you mean something
>> like:
>> > > > >
>> > > > > samples/helloworld/java
>> > > > > samples/helloworld/javascript
>> > > > > samples/calculator/java
>> > > > > samples/calculator/javascript
>> > > > >
>> > > > > Or do you mean include them with the extension so the
>> JavaScript
>> > > > > folder
>> > > > > would include samples/helloworld and samples/calculator? I
>> didn't
>> > > > > think Jim
>> > > > > liked this way, from the previous thread - "In other
>> words, each
>> > > > > sample
>> > > > > project should not be a sibling to the project containing
>> extension
>> > > > > code but
>> > > > > should go under a samples folder in separate projects".
>> > > > I was thinking samples for particular extensions would go
>> under the
>> > > > particular extension's directory. For samples that used
>> multiple
>> > > > extensions, they would go under the master samples folder. I
>> liked
>> > > > what was done with the calculator where stuff is shared between
>> > > > projects (component reuse) so if that structuring won't work
>> for re-
>> > > > use I would be fine with what Ant just outlined. My preference,
>> > > > though, would be to group samples with individual extensions.
>> > > >
>> > > > Jim
>> > > >
>> > > > >
>> > > > > ...ant
>> > > >
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>> >
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
I'd prefer to have business samples under 'samples' itself. I perceive that
technology samples will go to the respective project directories and all
others are to demonstrate the cool things of combining containers,
transports - the integration story and they would all get under samples i.e.
samples/BigBang, samples/SupplyChain .. and so on.
- Venkat
On 10/7/06, ant elder <an...@gmail.com> wrote:
>
> I guess I was thinking that the technology type samples would be the ones
> that are now moved further down into the folder hierarchy so the only
> thing
> left up at the top would be the business samples so there wasn't the need
> for the two folders 'samples' and 'sampleapps' so sampleapps might as well
> just be renamed to samples to keep everything consistent.
>
> Please anyone say if they disagree with that. I'd also still like to hear
> comments or suggestions on all this from others who've expressed an
> interest
> in the samples in the past before I make the changes - Jim , Rick, Simon?
>
> ...ant
>
> On 10/6/06, Brent Daniel <br...@gmail.com> wrote:
> >
> > Previously we had discussed having a "sampleapps" directory to
> > distinguish "business samples" from technology samples.[1] Do we want
> > to continue this distinction?
> >
> > Brent
> >
> >
> > [1] -
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01812.html
> >
> > On 10/6/06, ant elder <an...@gmail.com> wrote:
> > > Ok I think we're getting some agreement but I'd like to be clear
> > everyone
> > > agrees and is happy before I make any changes. Sounds like for things
> > like
> > > the Groovy/JavaScript/etc helloworld and calculator type samples they
> > would
> > > go with the extension, I'm guessing samples that use just sca and java
> > would
> > > go in an sca/samples directory. Samples that use multiple extensions
> but
> > > still just SCA would also go in the sca/samples directory, and there'd
> > be a
> > > top level samples directory for things like bigbank that use
> > sca/sdo/das.
> > >
> > > So:
> > >
> > > samples/bingbank
> > > das/samples/companyweb
> > > sca/samples/calculator
> > > sca/services/containers/container.javascript/src/samples/calculator
> > >
> > > Comments?
> > >
> > > ...ant
> > >
> > > On 10/5/06, Jim Marino <jm...@myromatours.com> wrote:
> > > >
> > > >
> > > > On Oct 5, 2006, at 7:14 AM, ant elder wrote:
> > > >
> > > > > On 10/5/06, Jeremy Boynes <jb...@apache.org> wrote:
> > > > >>
> > > > >> I think organizing the samples like this is a good idea. I'd
> > suggest
> > > > >> going one step further and place each sample with the
> > implementation
> > > > >> of the service that it is illustrating. That way it becomes much
> > > > >> easier to tag/release each module on its own.
> > > > >
> > > > >
> > > > > I'm not sure I follow "place each sample with the implementation
> of
> > > > > the
> > > > > service that it is illustrating" , do you mean something like:
> > > > >
> > > > > samples/helloworld/java
> > > > > samples/helloworld/javascript
> > > > > samples/calculator/java
> > > > > samples/calculator/javascript
> > > > >
> > > > > Or do you mean include them with the extension so the JavaScript
> > > > > folder
> > > > > would include samples/helloworld and samples/calculator? I didn't
> > > > > think Jim
> > > > > liked this way, from the previous thread - "In other words, each
> > > > > sample
> > > > > project should not be a sibling to the project containing
> extension
> > > > > code but
> > > > > should go under a samples folder in separate projects".
> > > > I was thinking samples for particular extensions would go under the
> > > > particular extension's directory. For samples that used multiple
> > > > extensions, they would go under the master samples folder. I liked
> > > > what was done with the calculator where stuff is shared between
> > > > projects (component reuse) so if that structuring won't work for re-
> > > > use I would be fine with what Ant just outlined. My preference,
> > > > though, would be to group samples with individual extensions.
> > > >
> > > > Jim
> > > >
> > > > >
> > > > > ...ant
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
Re: SCA Java samples for M2
Posted by ant elder <an...@gmail.com>.
I guess I was thinking that the technology type samples would be the ones
that are now moved further down into the folder hierarchy so the only thing
left up at the top would be the business samples so there wasn't the need
for the two folders 'samples' and 'sampleapps' so sampleapps might as well
just be renamed to samples to keep everything consistent.
Please anyone say if they disagree with that. I'd also still like to hear
comments or suggestions on all this from others who've expressed an interest
in the samples in the past before I make the changes - Jim , Rick, Simon?
...ant
On 10/6/06, Brent Daniel <br...@gmail.com> wrote:
>
> Previously we had discussed having a "sampleapps" directory to
> distinguish "business samples" from technology samples.[1] Do we want
> to continue this distinction?
>
> Brent
>
>
> [1] - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01812.html
>
> On 10/6/06, ant elder <an...@gmail.com> wrote:
> > Ok I think we're getting some agreement but I'd like to be clear
> everyone
> > agrees and is happy before I make any changes. Sounds like for things
> like
> > the Groovy/JavaScript/etc helloworld and calculator type samples they
> would
> > go with the extension, I'm guessing samples that use just sca and java
> would
> > go in an sca/samples directory. Samples that use multiple extensions but
> > still just SCA would also go in the sca/samples directory, and there'd
> be a
> > top level samples directory for things like bigbank that use
> sca/sdo/das.
> >
> > So:
> >
> > samples/bingbank
> > das/samples/companyweb
> > sca/samples/calculator
> > sca/services/containers/container.javascript/src/samples/calculator
> >
> > Comments?
> >
> > ...ant
> >
> > On 10/5/06, Jim Marino <jm...@myromatours.com> wrote:
> > >
> > >
> > > On Oct 5, 2006, at 7:14 AM, ant elder wrote:
> > >
> > > > On 10/5/06, Jeremy Boynes <jb...@apache.org> wrote:
> > > >>
> > > >> I think organizing the samples like this is a good idea. I'd
> suggest
> > > >> going one step further and place each sample with the
> implementation
> > > >> of the service that it is illustrating. That way it becomes much
> > > >> easier to tag/release each module on its own.
> > > >
> > > >
> > > > I'm not sure I follow "place each sample with the implementation of
> > > > the
> > > > service that it is illustrating" , do you mean something like:
> > > >
> > > > samples/helloworld/java
> > > > samples/helloworld/javascript
> > > > samples/calculator/java
> > > > samples/calculator/javascript
> > > >
> > > > Or do you mean include them with the extension so the JavaScript
> > > > folder
> > > > would include samples/helloworld and samples/calculator? I didn't
> > > > think Jim
> > > > liked this way, from the previous thread - "In other words, each
> > > > sample
> > > > project should not be a sibling to the project containing extension
> > > > code but
> > > > should go under a samples folder in separate projects".
> > > I was thinking samples for particular extensions would go under the
> > > particular extension's directory. For samples that used multiple
> > > extensions, they would go under the master samples folder. I liked
> > > what was done with the calculator where stuff is shared between
> > > projects (component reuse) so if that structuring won't work for re-
> > > use I would be fine with what Ant just outlined. My preference,
> > > though, would be to group samples with individual extensions.
> > >
> > > Jim
> > >
> > > >
> > > > ...ant
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: SCA Java samples for M2
Posted by Brent Daniel <br...@gmail.com>.
Previously we had discussed having a "sampleapps" directory to
distinguish "business samples" from technology samples.[1] Do we want
to continue this distinction?
Brent
[1] - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01812.html
On 10/6/06, ant elder <an...@gmail.com> wrote:
> Ok I think we're getting some agreement but I'd like to be clear everyone
> agrees and is happy before I make any changes. Sounds like for things like
> the Groovy/JavaScript/etc helloworld and calculator type samples they would
> go with the extension, I'm guessing samples that use just sca and java would
> go in an sca/samples directory. Samples that use multiple extensions but
> still just SCA would also go in the sca/samples directory, and there'd be a
> top level samples directory for things like bigbank that use sca/sdo/das.
>
> So:
>
> samples/bingbank
> das/samples/companyweb
> sca/samples/calculator
> sca/services/containers/container.javascript/src/samples/calculator
>
> Comments?
>
> ...ant
>
> On 10/5/06, Jim Marino <jm...@myromatours.com> wrote:
> >
> >
> > On Oct 5, 2006, at 7:14 AM, ant elder wrote:
> >
> > > On 10/5/06, Jeremy Boynes <jb...@apache.org> wrote:
> > >>
> > >> I think organizing the samples like this is a good idea. I'd suggest
> > >> going one step further and place each sample with the implementation
> > >> of the service that it is illustrating. That way it becomes much
> > >> easier to tag/release each module on its own.
> > >
> > >
> > > I'm not sure I follow "place each sample with the implementation of
> > > the
> > > service that it is illustrating" , do you mean something like:
> > >
> > > samples/helloworld/java
> > > samples/helloworld/javascript
> > > samples/calculator/java
> > > samples/calculator/javascript
> > >
> > > Or do you mean include them with the extension so the JavaScript
> > > folder
> > > would include samples/helloworld and samples/calculator? I didn't
> > > think Jim
> > > liked this way, from the previous thread - "In other words, each
> > > sample
> > > project should not be a sibling to the project containing extension
> > > code but
> > > should go under a samples folder in separate projects".
> > I was thinking samples for particular extensions would go under the
> > particular extension's directory. For samples that used multiple
> > extensions, they would go under the master samples folder. I liked
> > what was done with the calculator where stuff is shared between
> > projects (component reuse) so if that structuring won't work for re-
> > use I would be fine with what Ant just outlined. My preference,
> > though, would be to group samples with individual extensions.
> >
> > Jim
> >
> > >
> > > ...ant
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by ant elder <an...@gmail.com>.
Ok I think we're getting some agreement but I'd like to be clear everyone
agrees and is happy before I make any changes. Sounds like for things like
the Groovy/JavaScript/etc helloworld and calculator type samples they would
go with the extension, I'm guessing samples that use just sca and java would
go in an sca/samples directory. Samples that use multiple extensions but
still just SCA would also go in the sca/samples directory, and there'd be a
top level samples directory for things like bigbank that use sca/sdo/das.
So:
samples/bingbank
das/samples/companyweb
sca/samples/calculator
sca/services/containers/container.javascript/src/samples/calculator
Comments?
...ant
On 10/5/06, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Oct 5, 2006, at 7:14 AM, ant elder wrote:
>
> > On 10/5/06, Jeremy Boynes <jb...@apache.org> wrote:
> >>
> >> I think organizing the samples like this is a good idea. I'd suggest
> >> going one step further and place each sample with the implementation
> >> of the service that it is illustrating. That way it becomes much
> >> easier to tag/release each module on its own.
> >
> >
> > I'm not sure I follow "place each sample with the implementation of
> > the
> > service that it is illustrating" , do you mean something like:
> >
> > samples/helloworld/java
> > samples/helloworld/javascript
> > samples/calculator/java
> > samples/calculator/javascript
> >
> > Or do you mean include them with the extension so the JavaScript
> > folder
> > would include samples/helloworld and samples/calculator? I didn't
> > think Jim
> > liked this way, from the previous thread - "In other words, each
> > sample
> > project should not be a sibling to the project containing extension
> > code but
> > should go under a samples folder in separate projects".
> I was thinking samples for particular extensions would go under the
> particular extension's directory. For samples that used multiple
> extensions, they would go under the master samples folder. I liked
> what was done with the calculator where stuff is shared between
> projects (component reuse) so if that structuring won't work for re-
> use I would be fine with what Ant just outlined. My preference,
> though, would be to group samples with individual extensions.
>
> Jim
>
> >
> > ...ant
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: SCA Java samples for M2
Posted by Jim Marino <jm...@myromatours.com>.
On Oct 5, 2006, at 7:14 AM, ant elder wrote:
> On 10/5/06, Jeremy Boynes <jb...@apache.org> wrote:
>>
>> I think organizing the samples like this is a good idea. I'd suggest
>> going one step further and place each sample with the implementation
>> of the service that it is illustrating. That way it becomes much
>> easier to tag/release each module on its own.
>
>
> I'm not sure I follow "place each sample with the implementation of
> the
> service that it is illustrating" , do you mean something like:
>
> samples/helloworld/java
> samples/helloworld/javascript
> samples/calculator/java
> samples/calculator/javascript
>
> Or do you mean include them with the extension so the JavaScript
> folder
> would include samples/helloworld and samples/calculator? I didn't
> think Jim
> liked this way, from the previous thread - "In other words, each
> sample
> project should not be a sibling to the project containing extension
> code but
> should go under a samples folder in separate projects".
I was thinking samples for particular extensions would go under the
particular extension's directory. For samples that used multiple
extensions, they would go under the master samples folder. I liked
what was done with the calculator where stuff is shared between
projects (component reuse) so if that structuring won't work for re-
use I would be fine with what Ant just outlined. My preference,
though, would be to group samples with individual extensions.
Jim
>
> ...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by ant elder <an...@gmail.com>.
On 10/5/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> I think organizing the samples like this is a good idea. I'd suggest
> going one step further and place each sample with the implementation
> of the service that it is illustrating. That way it becomes much
> easier to tag/release each module on its own.
I'm not sure I follow "place each sample with the implementation of the
service that it is illustrating" , do you mean something like:
samples/helloworld/java
samples/helloworld/javascript
samples/calculator/java
samples/calculator/javascript
Or do you mean include them with the extension so the JavaScript folder
would include samples/helloworld and samples/calculator? I didn't think Jim
liked this way, from the previous thread - "In other words, each sample
project should not be a sibling to the project containing extension code but
should go under a samples folder in separate projects".
...ant
Re: SCA Java samples for M2
Posted by Jeremy Boynes <jb...@apache.org>.
I think organizing the samples like this is a good idea. I'd suggest
going one step further and place each sample with the implementation
of the service that it is illustrating. That way it becomes much
easier to tag/release each module on its own.
Also, the samples that are in "java" and "echo" need the "standalone"
installation to run so how about grouping them with that?
The web-app based ones ("webapp" and potentially "bigbank") don't
need the user to download/install the standalone installation at all
and we could package those as a separate unit as well.
--
Jeremy
On Oct 5, 2006, at 5:04 AM, ant elder wrote:
> There was a discussion on the samples a while back [1] where i
> think there
> was some agreement to restructure the samples based on the
> extension they
> are demonstrating. It wasn't so clear what the out come of that
> discussion
> was so how about the following (for now ignoring whats in/out/works/
> broken):
>
> sampleapps/bigbank
> bigbank
>
> samples/echo
> - echo.binding
> - echo.databinding
>
> samples/javascript
> helloworld
>
> samples/axis2
> helloworldws
> helloworldwsclient
> helloworldwsclientOM
> helloworldwsOM
>
> samples/celtix
> helloworldws-celtix
>
> samples/spring
> spring.simple
> spring
>
> samples/rmi
> helloworld.rmiReference
> helloworld.rmiService
>
> samples/jsonrpc
> helloworldjsonrpc
>
> samples/java?
> calculator
> eagerinit
> inner.composite
> local.wire
> local.wire.cdi
> simplecallback
> supplychain
> webapp
>
> In the same thread there was the suggestion about using a
> calculator sample
> instead of or as well as helloworld so I'll also add a javascript
> calculator
> sample and look at doing both for the other script languages as well.
>
> If we can reach some consensus about what this should look like I
> can do the
> changes.
>
> ...ant
>
> [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
> msg06572.html
>
> On 10/4/06, Simon Nash <na...@hursley.ibm.com> wrote:
>>
>> I'm planning to go through all the SCA Java samples, building them
>> and runnning them, to make sure that they work. We also need to
>> consider whether this is the right set of samples to introduce
>> users to the capabilities of SCA and Tuscany.
>>
>> Right now we have the following in the samples/sca directory.
>>
>> Samples that are currently building:
>> bigbank
>> calculator
>> eagerinit
>> echo.binding
>> echo.databinding
>> helloworldJavaScript
>> helloworldws
>> helloworldws-celtix
>> helloworldwsclient
>> local.wire
>> local.wire.cdi
>> spring.simple
>> supplychain
>> webapp
>>
>> Samples that are not currently building:
>> helloworld.rmiReference
>> helloworld.rmiService
>> helloworldjsonrpc
>> helloworldwsclientOM
>> helloworldwsOM
>> inner.composite
>> simplecallback
>> spring
>>
>> For a first pass I would assume that we are intending to deliver the
>> former list in our M2 binary release but not the latter. Is this
>> a correct assumption? Should any of the "not building" samples be
>> included? Should any of the "building" samples be excluded?
>> Should we be adding any more samples that are currently not in
>> either list?
>>
>> From a quick look through these lists, I have the following
>> questions.
>>
>> 1. It is my understanding that we are including RMI, so presumably
>> we need the RMI samples.
>>
>> 2. It is my understanding that we are not including celtix in the
>> binary release, so presumably we don't need the celtix sample.
>>
>> 3. I don't know whether we will be including Spring, so I'm not
>> whether we will need the spring.simple sample.
>>
>> Simon
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA Java samples for M2
Posted by ant elder <an...@gmail.com>.
There was a discussion on the samples a while back [1] where i think there
was some agreement to restructure the samples based on the extension they
are demonstrating. It wasn't so clear what the out come of that discussion
was so how about the following (for now ignoring whats in/out/works/broken):
sampleapps/bigbank
bigbank
samples/echo
- echo.binding
- echo.databinding
samples/javascript
helloworld
samples/axis2
helloworldws
helloworldwsclient
helloworldwsclientOM
helloworldwsOM
samples/celtix
helloworldws-celtix
samples/spring
spring.simple
spring
samples/rmi
helloworld.rmiReference
helloworld.rmiService
samples/jsonrpc
helloworldjsonrpc
samples/java?
calculator
eagerinit
inner.composite
local.wire
local.wire.cdi
simplecallback
supplychain
webapp
In the same thread there was the suggestion about using a calculator sample
instead of or as well as helloworld so I'll also add a javascript calculator
sample and look at doing both for the other script languages as well.
If we can reach some consensus about what this should look like I can do the
changes.
...ant
[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06572.html
On 10/4/06, Simon Nash <na...@hursley.ibm.com> wrote:
>
> I'm planning to go through all the SCA Java samples, building them
> and runnning them, to make sure that they work. We also need to
> consider whether this is the right set of samples to introduce
> users to the capabilities of SCA and Tuscany.
>
> Right now we have the following in the samples/sca directory.
>
> Samples that are currently building:
> bigbank
> calculator
> eagerinit
> echo.binding
> echo.databinding
> helloworldJavaScript
> helloworldws
> helloworldws-celtix
> helloworldwsclient
> local.wire
> local.wire.cdi
> spring.simple
> supplychain
> webapp
>
> Samples that are not currently building:
> helloworld.rmiReference
> helloworld.rmiService
> helloworldjsonrpc
> helloworldwsclientOM
> helloworldwsOM
> inner.composite
> simplecallback
> spring
>
> For a first pass I would assume that we are intending to deliver the
> former list in our M2 binary release but not the latter. Is this
> a correct assumption? Should any of the "not building" samples be
> included? Should any of the "building" samples be excluded?
> Should we be adding any more samples that are currently not in
> either list?
>
> From a quick look through these lists, I have the following questions.
>
> 1. It is my understanding that we are including RMI, so presumably
> we need the RMI samples.
>
> 2. It is my understanding that we are not including celtix in the
> binary release, so presumably we don't need the celtix sample.
>
> 3. I don't know whether we will be including Spring, so I'm not
> whether we will need the spring.simple sample.
>
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>