On Feb 21, 2007, at 12:50 PM, Luciano Resende wrote:
If we follow the pattern we have been using for SDO, DAS, once we
build the
project, the samples are built together to make sure changes on the
core
didn't break functionality used by the samples. In the case of
SCA, don't
we want to do the same, and when building sca, we would build the
samples as
well ? (e.g java/sca, java/samples/sca and java/distribution/
sca)... While
we still don't have the ideal unit/integration tests that would
exercise all
our scenarios, the sample applications have always a good source to
help as
improve quality in the project.
Maybe one solution would be to have those items moved to inside the
sca
project.
We decided a while back to move samples and tests into their modules.
There are two modules under sca already for testing the baseline:
integration-test
core-samples
I think the issue stems from the idea of "building sca" - "sca" isn't
a module or a distribution; instead we have a whole collection of
modules under there (kernel, runtime, etc.) that can be built and
distributed independently.
Integration testing is about testing integration - not just between
modules in the build but also about integration with platforms. When
doing a release we would want to verify that *identical*
distributions work in different environments. That means integration
testing is not about what was built on your local machine but that a
candidate distribution someone else built works in the environments
you are testing. The monolithic profile builds don't support this.
The same with samples. It's not enough to know that a sample runs,
it's important to know that it runs if the user follows the
instructions. Users typically don't have the source code on their
machine, they typically use a downloaded binary distribution; they
typically don't have artifacts in their local repo so its important
to know that the artifacts they will be downloading are consistent.
Again, the monolithic builds don't support this either.
Having the profiles there encourages bad behaviour on our part in
that the longer we keep building as a monolith the further away we
remain from the user experience.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
