maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maczka Michal <>
Subject RE: Jason's lifecycle doco
Date Mon, 24 Jan 2005 09:17:10 GMT

> -----Original Message-----
> From: John Casey []
> Sent: Sunday, January 23, 2005 3:14 AM
> To: Maven 2 Developers List
> Subject: Re: Jason's lifecycle doco
> > Were you ok with the integration test stuff I brought up 
> too, making 
> > that phase essentially optional in some environments?
> what about something like:
> ...
> <phase>
>    <id>test</id>
>    <goal>
>      <id>surefire:test</id>
>    </goal>
>    <goal>
>      <id>cactus:test</id>
>      <environments>
>        <environment>CI</environment>
>      </environments>
>    </goal>
> </phase>
> ...
> then, we could invoke:
> m2 -Denv=CI test
> if we're running the build in/for the CI context, or
> m2 test
> for anywhere else (cactus:test doesn't run here).
> Thoughts?

I think we discuss it couple times and we all agreed that integration tests
should be kept in seperate projects
so this is really no need to make builds sensitive to command line switches

IMO our strategy can be sumarize with the colloquial rule, "There should be
one entry per project in continuum".
Which means that builds should not be dependent on any envinromental
settings - but any informations about the project and possible 
build scenarios should be rather static and contained in POMs.

I myslef am doing integration tests in two ways:

First way is similar to the strategy used in m2 - I have set of small
projects which I am using to validate use cases previewed for
some other project. This kind of iu testsing can be supported by ci systems.

Second strategy is bit different - I need to validate if the installation of
some platform which I made @customer is sane. 
For that I want to use binaries which contains my automated tests and some
sort of rutime envinronments  for running my tests.  

I am sure that there are more such scenarios. So it is kind of hard to
discuss how to support such voluminous term like iu testing 
in m2 in a generic way. 

[off topic]
iu tests of m2 are quite good examples of things, which need to be supported
by m2.
They can serve as good reference and we can think how to structure such
build, which is currently performed be mboot in m2 and 
how to support them contiunus integration systems. In other words at some
moment in time m2 should be fully self-contained.


View raw message