felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toni Menzel <t...@okidokiteam.com>
Subject Re: Continuous build updated to Maven 2.2.1
Date Mon, 23 Nov 2009 10:00:06 GMT
On Mon, Nov 23, 2009 at 10:42 AM, Felix Meschberger <fmeschbe@gmail.com>wrote:

> Hi,
>
> Toni Menzel schrieb:
> > On Mon, Nov 23, 2009 at 10:29 AM, Felix Meschberger <fmeschbe@gmail.com
> >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 <
> >>> marcel.offermans@luminis.nl> 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
toni@okidokiteam.com
http://www.ops4j.org     - New Energy for OSS Communities - Open
Participation Software.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message