maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject [PROPOSAL] Maven POM re-org to address deps + test issues
Date Fri, 06 Jun 2003 00:33:50 GMT

Based on the discussions about "test levels" and about isolating test, 
runtime and compile time dependencies, I thought about some changes to 
the POM that might help, and got a bit carried away ;)
This is a work in progress with a few limitations discussed later, but I 
thought it might be a good starting point for a discussion to address 
some of the issues. Bear in mind I wrote this on the train at 7am this 
morning ;)

What I propose is remove <build/> and everything in it. Move 
<nagEmailAddress/> to that level, and then add the following elements:

       <!-- as before -->
       <!-- as before -->
       <!-- Default is include all -->
       <!-- Actually put these into Jelly context (or Ant?) during 
processing of plugin -->
   <!-- repeat for test set, java set, JAXB set, cactus test set, 
performance test set, ... -->

Finally, you can includes/exclude sets from the command line to avoid 
processing certain sets:
maven -Dexclude.sets=perf-test,integ-test
maven -Dinclude.sets=gen-jaxb,default

Now the problems I see with it:
* Not that comfortable with the extends syntax - bit too similar to POM 
inheritance. Could be used to fold subprojects. However, need a way to 
include deps and classpath built sources of other sets without 
duplication. Any thoughts on this?
* This pattern allows multiple source trees. It does takes care of 
generated source (antlr, jaxb) more cleanly (source would be the 
descriptor files, then plugin uses addPath for java sources). However, 
could be used to have multiple java source trees for a real project. 
Maybe this is ok - let those who've demanded it have it, but perhaps 
display a warning every run that it is a bad practice :)
* The specification of plugins does worry me a bit, but I don't see 
alternatives. Certain things should make use of new plugins 
automatically (some site related plugin should apply to all source 
trees), but others must be blocked out.

Also, how does this fit with maven-new's structure?


Web Developer
f2 network ~ everything essential
02 8596 4437

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message