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
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
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 [EMAIL PROTECTED] wrote:
On Oct 10, 2006, at
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
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
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
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
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
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
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
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
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
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
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 ?
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
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
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
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
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 -
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
Hi...
Yes this makes sense to me.
- Venkat
where I'd like to put component implementations
On 10/6/06, ant elder [EMAIL PROTECTED] 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
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
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
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 [EMAIL PROTECTED] wrote:
I think organizing the samples like this is a good idea. I'd suggest
going one step further
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 [EMAIL PROTECTED] wrote:
Ok I
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
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 [EMAIL PROTECTED] wrote:
There was a discussion on the samples a while back
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
On 10/5/06, Jeremy Boynes [EMAIL PROTECTED] 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
On Oct 5, 2006, at 7:14 AM, ant elder wrote:
On 10/5/06, Jeremy Boynes [EMAIL PROTECTED] 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
On Oct 5, 2006, at 7:14 AM, ant elder wrote:
On 10/5/06, Jeremy Boynes [EMAIL PROTECTED] 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
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
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
Hi Simon,
I shall get the RMI samples up by tomorrow for sure.
Thanks
- Venkat
On 10/4/06, Andy Piper [EMAIL PROTECTED] 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
34 matches
Mail list logo
