I understand that the sample refactoring is on the way, but I think this is a different subject from my original question. I was concerned that today we have the bigBank source in two places, but I'm afraid we are only maintaining the one in the sampleapps/bigbank. Hence my suggestion to create a JIRA and cleanup the one in the samples directory.
- Luciano On 10/18/06, Jim Marino <[EMAIL PROTECTED]> wrote:
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]
