maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marckx_G...@emc.com
Subject RE: [PROPOSAL] Maven POM re-org to address deps + test issues
Date Fri, 06 Jun 2003 06:35:56 GMT
What I like in particular is that you change the element 'build' into set.
The name build gives the impression it is an action that is described, while
it is actually a structure of a project, upon which the generic actions are
based.

Gino.

> -----Original Message-----
> Hi,
> 
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message