On Mon, Nov 23, 2009 at 10:42 AM, Felix Meschberger <[email protected]>wrote:
> Hi, > > Toni Menzel schrieb: > > On Mon, Nov 23, 2009 at 10:29 AM, Felix Meschberger <[email protected] > >wrote: > > > >> Hi, > >> > >> Toni Menzel schrieb: > >>> This is actually "home made" by placing integration tests in the > >> component > >>> under test. > >>> This way you create a chicken egg problem. The tests (executed before > >> bundle > >>> is being packaged, see maven lifecycle) grabs any older version of the > >>> component it finds (matching the group+artifact+version) wich usually > not > >>> what you want to test. > >> No, this is probably not a chicken/egg problem: the integration tests > >> run in the integration-test phase, which comes after packaging. Moreover > >> the SCR bundle under test is loaded from the local target folder and not > >> through maven to ensure using the correct version. > >> > > > > Always learning new things;) Actually i never use the integration-test > phase > > because of "prefer mvn install over mvn package". So I would never rely > in > > package builds when using a bigger reactor builds. > > Because of that you are back to the chicken-egg. - you cannot really > > "revoke" a install(ed) build. > > Point is that this is roughly the order of phases: > > process resources > compile > unit tests > package > integration-test > install > deploy > > So, the integration-test phase always comes _after_ the packaging but > before (locally) installing. So if an integration test fails, the local > install (and remote deployment) don't take place. > > See also > > http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html > > Quite nice ;-) Sure, i am aware of that but.. was more pointing to the fact of not trusting mvn package builds (rather than mvn install) when having a multi project build. However, was not aware that you (in SCR) use a self made provisioning system. Have you had trouble of fetching artifacts from local repo (instead of target) before ? > > Regards > Felix > > > > > > Anyway, if it works for scr, very good! Should have looked into it a bit > > deeper. ;) > > > > > >> So, it is rather related to test timing issues, I fear. > >> > >> I will look into hardening the tests ... until then there might be some > >> builds which fail due to SCR and/or configadmin -- especially since we > >> build everything at once. > >> > >>> Solution: put the integration tests into its own projects. Sounds nuts > >> but > >>> is just logical. > >>> Also it would be good to upgrade to exam 1.2.0 (currently 0.6). > >> Ok, thanks for pointing to this new release. Will update. > >> > >> Regards > >> Felix > >> > >>> Toni > >>> > >>> On Sat, Nov 21, 2009 at 5:52 PM, Marcel Offermans < > >>> [email protected]> wrote: > >>> > >>>> I just updated the continuous build, running on Bamboo, to Maven 2.2.1 > >>>> because I needed a feature (compiling tests against a different > >>>> source/target JVM than the bundle itself) which seemed to be broken in > >>>> earlier versions. > >>>> > >>>> Initially, after going to the new Maven, a test case failed, but > running > >>>> the build again made it succeed, so I'm assuming there is some kind of > >> race > >>>> condition in the test. See: > >>>> > >>>> > >>>> > >> > http://opensource.bamboo.atlassian.com/build/viewTestCaseHistory.action?buildKey=FELIX-DEF&testClassName=org.apache.felix.scr.integration.ServiceBindTest&testCaseName=test_optional_single_static > >>>> Perhaps one of the SCR guys could have a look at this? > >>>> > >>>> Greetings, Marcel > >>>> > >>>> > >>> > > > > > > > -- Toni Menzel Independent Software Developer Professional Profile: http://okidokiteam.com [email protected] http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software.
