I think so. Here is what I proposed a while back:
<snip>
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).
</snip>
One question that was raised was why the samples would not be built
from the main checkin process. Basically, because:
1. Checking that they build will likely not verify if they work,
particularly if they presuppose a host environment such as a servlet
container (the integration and acceptance testing frameworks would
verify this)
2. Samples are not guaranteed to run (or build) against unstable
versions of trunk. They should only be guaranteed against tagged
versions or builds deemed stable. One way of looking at this is that
end users are not likely to checkout the trunk and build it just to
run samples; they are likely to download a distribution and the
samples they are interested. Another way of looking at this is that
core will introduce breaking changes moving forward as an inevitable
outgrowth of spec proposals. In addition, samples may be created
demonstrating certain features ahead of their availability in core.
We need to have this isolation between samples and core so that
people working in one area are minimally impacted by changes in another.
3. Samples should be buildable by end-users without the need to have
our build environment set up. In other words, samples should come
with a self-contained build.
Jim
On Oct 18, 2006, at 10:34 PM, Venkata Krishnan wrote:
Hi
As far as I remember there was a discussion on organization of
samples and
as per that the sampleapps directory is on its way out. We are
probably
going to do that once we are done with M2.
We are going to have one uniform pattern where samples at the root
will
demostrate SCA, SDO and DAS and then within SCA (or SDO or DAS)
there will
be samples that concern only SCA features such as different
containers,
bindings, etc. Then each module within SCA - say containers will
have
samples around just the container in question. So a user can start
from
deep down and move up to a broader perspective of SCA. (Hope I have
interpretted the discussion rightly :))
Here's that long thread around this
http://www.mail-archive.com/[email protected]/msg08911.html
- Venkat
On 10/19/06, Luciano Resende <[EMAIL PROTECTED]> wrote:
Hi
I noticed that we currently have BigBank source in two places :
- samples/sca/bigbank
- sampleapps/bigbank
Do we use both ? My understanding is that we are using
sampleApps/BigBank. If that is right one to keep, and we need to
remove
samples/sca/bigBank, please let me know and I'll create a JIRA to
remove
it.
- Luciano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
