aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holly Cummins <>
Subject Re: blueprint itest failures...
Date Tue, 17 Dec 2013 06:26:29 GMT

On 16 Dec 2013, at 22:01, Daniel Kulp <> wrote:

> On Dec 13, 2013, at 7:48 PM, Holly Cummins <>


>> It should be that the main build tests the released versions, so über-1.0 and its
back-level constituents. Then the snapshot build tests the latest code, which is uber-snapshot
and snapshots of each included bundle - ie, the latest code of everything.
> Personally, I don’t think the itests should ever be testing the released versions.
 That doesn’t make a whole lot of sense.   As soon as I add a new test, that would cause
the build to break.   The purpose of the itests is to make sure the stuff we’re working
on doesn’t break anything.   

Yeah, I mostly agree. The idea with the main 'release' build is that as soon as something
needs the snapshot level of a dependency, it bumps the version in the pom - but it doesn't
bump it before then just to get coverage (doing so would actually worsen coverage, as well
as messing up the import version ranges in the manifests).

So for itests, as soon as we add a new test, we 'need' the latest version of the thing we're
testing. Transitive dependencies probably want to stay at the released level, though, so that
we cover more combinations across the two builds.

>> If the snapshot build is actually getting that coverage I think it is, and things
are failing anyway with individual bundles, I wonder if we need to run tests with both uber
and individual bundles?
> Or get rid of the uber bundles.   That’s the direction I’d prefer going.  I’d certainly
prefer not having to do double the amount of release and test work

Certainly that would make things a lot easier and cleaner for us (at the possible of making
things harder for users who don't have a nice provisioning system in place). 

>> Holly
>> On 13 Dec 2013, at 20:36, Daniel Kulp <> wrote:
>>> While writing a test for ARIES-1141, I discovered that the blueprint-itests were
pulling in “org.apache.aries.blueprint/1.0.0” which is the older “big blueprint bundle”
instead of the individual “core”, “cm”, etc… bundles.   There are several issues:
>>> 1) Since karaf and everything has been updated to using the littler bundles,
this means we aren’t testing what people are using
>>> 2) We haven’t done a “release” of the big bundle since 1.0.0, but there
have been releases of the littler things.  This means the littler things haven’t had the
itests run with them. 
>>> 3) I flipped the itests to use the little bundles and now we have couple of test
>>> Running org.apache.aries.blueprint.itests.TestRegistrationListener
>>> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.968 sec <<<
>>> Running org.apache.aries.blueprint.itests.BlueprintContainerTest
>>> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 48.701 sec <<<
>>> org.apache.aries.blueprint.itests.ASMMultiBundleTest  also fails semi-randomly.
  That may be the sync vs non-sync startup issues.   Need to double check that.
>>> If you have some time, please try taking a look.   It looks like we may have
broken a bunch of things through the various releases and that obviously concerns me.   The
BlueprintContainerTest is in testScheduledExecMemoryLeak  which kind of scares me.   
>>> -- 
>>> Daniel Kulp
>>> -
>>> Talend Community Coder -
> -- 
> Daniel Kulp
> -
> Talend Community Coder -

View raw message