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 Mon, 06 Apr 2009 16:43:47 GMT

On 6-Apr-09, at 9:13 AM, David Jencks wrote:

> On Apr 4, 2009, at 11:15 AM, Jason van Zyl wrote:
>> 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.
> Thinking about this a bit more I'm even more confused about how to  
> proceed.  In my case the "lot of java code" is about half of geronimo.

Ok, you've lost me. I don't understand what it is you're trying to do.

> So, I need the archetype to have the same classloader setup/ 
> classloading capabilities as a plugin.  So it seems like one choice  
> would be to simply write a plugin that happens to use the archetype  
> common code.  But this wouldn't fit nicely into the m2eclipse  
> ability to run the archetype plugin.  Is there a  reasonably simple  
> way to have an archetype be a whole plugin whose pom sets up the  
> classloader for the archetype's code and to have the arechetype  
> plugin manage this?  Is there another approach I haven't thought of?

I think you need to write something up, I honestly have no idea what  
you're talking about now.

> thanks
> david jencks
>>> 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:
>> Thanks,
>> Jason
>> ----------------------------------------------------------
>> 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  
>> examples
>> 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:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:



Jason van Zyl
Founder,  Apache Maven

Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.

  -- Eric Hoffer, Reflections on the Human Condition

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

View raw message