On Tue, Mar 11, 2008 at 4:01 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
> Rajini Sivaram wrote: > > itest/osgi-tuscany contains tests for an OSGi-based Tuscany runtime. I > > haven't included the tests in itests/pom.xml because they need to create > > bundles corresponding to Tuscany, and hence require around 100 > megabytes. > > Since we currently dont have other tests for a multi-classloader Tuscany > > environment, and because it is very difficult to ensure that changes to > > Tuscany dont add more problems for an OSGi-based Tuscany, I would like > to > > add itest/osgi-tuscany to the main build if there are no objections. > > > > There are still many outstanding issues with running Tuscany under OSGi, > but > > the test directory contains a harness to enable Tuscany samples to be > run > > using an OSGi-based Tuscany runtime, and hence provides test cases for > all > > the known outstanding issues (the broken tests are currently commented > out, > > but can be turned on as each problem is fixed). > > > > Thoughts? Objections? > > > > Thank you... > > > > Regards, > > > > Rajini > > > I am already pushing the limits of available disk space. Would it be > possible to provide an alternate profile that would exclude this test? > > In fact we could go further and generalize this principle by defining > a "basic regression" bucket and a "full test" bucket, selected by > profile. The Continuum build would run the "full test" bucket. > Developer builds could use "basic regression" or "full test" at the > individual developer's discretion. > > As a first step towards defining what tests go into what bucket, I'd > suggest that tests that consume a lot of disk space or take a long time > to run should only be part of the "full test" bucket. > > Simon > I'm starting to really like the look of this osgi work and think it would be good to try to make it more tightly integrated with the existing runtimes and distributions we have. I don't have any concrete proposal for this yet, I can understand the disk space issues but when you look at the rest of the build there's a lot we can do to clean up and reduce the size requirements of the rest of the code. ...ant
