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:
<sets>
<set>
<name>required-name</name>
<extends>
<extend>set-name</extend>
<extend>other-set-name</extend>
</extends>
<src>
<directory>...</directory>
<includes>
<include>...</include>
</includes>
<excludes>
<exclude>...</exclude>
</excludes>
</src>
<dependencies>
<!-- as before -->
</dependencies>
<resources>
<!-- as before -->
</resources>
<plugins>
<!-- Default is include all -->
<includes>
<include>...</include>
</includes>
<excludes>
<exclude>...</exclude>
</excludes>
</plugins>
<properties>
<!-- Actually put these into Jelly context (or Ant?) during processing of plugin -->
<property.name>value</property.name>
</properties>
</set>
<!-- repeat for test set, java set, JAXB set, cactus test set, performance test set, ... -->
</sets>
Finally, you can includes/exclude sets from the command line to avoid processing certain sets:
maven -Dexclude.sets=perf-test,integ-test
or
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?
Cheers, Brett
-- Web Developer f2 network ~ everything essential 02 8596 4437
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
