maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: Archetype capabilities/limitations?
Date Sat, 04 Apr 2009 18:15:57 GMT

On 4-Apr-09, at 10:13 AM, David Jencks wrote:

> I'd like to write something.... I'll call it an archetype for  
> now.... that generates a maven project but needs to run a _lot_ of  
> java code in order to figure out what to put in the new pom.xml.

The basis of it is there given we have velocity templates in there. I  
think what you want is to be able to deploy a class along with the  
archetype that would execute and manipulate the velocity context  
before rendering the files of the archetype. Something like a delegate  
for each template that's rendered? For this template do some mumbo  
jumbo and set object and flags in the Velocity context.

For sophisticated POM manipulation we can just put a tool in the  
velocity context or provide a hook to write out your own POM completely.

95% of what you need is there already. You definitely don't need to  
start over.

> What's my best strategy here?  From a quick glance at the archetype  
> plugin stuff it looks like this is not currently supported but that  
> it might be possible to add a third kind of archetype, something  
> like "code-based" along with file-set and old. Is this interesting  
> to anyone else?  Is it likely to be simpler to just start over and  
> ignore the archetype plugin stuff?
> I'd also like it push dependencyManagement stuff and possibly some  
> properties into parent poms and check that it's not duplicating  
> stuff. Is there already code in the archetype plugin stuff that does  
> this or would I be adding a new capability?
> thanks
> david jencks
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:



Jason van Zyl
Founder,  Apache Maven

People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more  
you look at, the more general your framework will be.

   -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks

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

View raw message