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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
