maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Casey <>
Subject Re: Jason's lifecycle doco
Date Mon, 24 Jan 2005 17:19:34 GMT
> 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 don't want to get distracted from my original point here. Perhaps my 
example was poorly thought-out, but what I'm really getting at is 
whether we should provide for the ability to add/suppress certain goals 
for certain targets in the development model. For example, most places 
have some concept of DEV, TESTING, PROD, etc. If that's the case, you 
may want to weave performance analysis aspects into the build for 
TESTING-targetted builds, or trace aspects for DEV...things you'd never 
want to deploy in production.

I guess from my point of view, maven is all about providing a 
development model for places producing software. If we see that many, 
many places have these needs, maybe we should try to address them in 
some coherent manner, rather than enforcing an artificial construct 

Another tangential issue with testing-subprojects: Are we increasing the 
complexity of a multiproject/reactor plugin suite in doing this? I mean, 
if my project would rationally have sub-projects (complementary 
libraries, etc.) and I want to build these along with the core product, 
the reactor all of a sudden has to account for subprojects that aren't 
*real* products, only that the best solution?

I understand the goals of single-project->single-artifact, but I also 
believe that to some extent it has become a doctrine that carries with 
it an unreasonably high price for maven developers and for maven users.


View raw message