You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <bp...@f2network.com.au> on 2003/06/06 02:33:50 UTC

[PROPOSAL] Maven POM re-org to address deps + test issues

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


Re: [PROPOSAL] Maven POM re-org to address deps + test issues

Posted by dv...@clever-age.com.
Hi Bret,

IMHO, your proposal is the way maven should go. This is a generic way to
express any new kind of project topology.
I think Micha's proposal is just another extension that describe what
should be done, which is NOT good. I think maven's first essence was to
describe a project and not what should be done to build/document/... it!
So specifying what integration unit tests should be run is not the good
way. But specifying what is available for testing is a better way.
> <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>

[...]

> * 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?

Maybe you additionnaly need something like restriction, the other form of
specialization. But then we must find how we would process this ? But this
is not wasted time as I do think too that POM needs a redesign.
A+. Didier.




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