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 <[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] > >
