maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Archetype capabilities/limitations?
Date Mon, 06 Apr 2009 17:18:04 GMT

On Apr 6, 2009, at 9:43 AM, Jason van Zyl wrote:

> 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.

I want to write something that will generate a geronimo plugin maven  
project and fill in as much as possible of the pom.  When you write a  
geronimo plugin project, you need to include as maven dependencies the  
parts of geronimo that are needed to run your plugin.  If you are  
deploying a services plugin, these geronimo parts are most likely the  
maven dependencies of the java code that implements your service, so  
there's no problem.  However if your plugin is a javaee app, then you  
need to list the javaee bits that your app needs.  For instance, if  
its a web app with jsps and jsf, you need to list the geronimo parts  
for a web container (jetty/tomcat), jasper, and myfaces.  With the  
current geronimo plugin archetype you have to go in and figure all  
this out for yourself.  However, the geronimo deployment system has a  
lot of code devoted exactly to figuring this out for you.  I want to  
run that code when you use the geronimo plugin archetype.

In more detail what I want:

run the geronimo-plugin-archetype
specify a javaee app as the module to be turned into a geronimo plugin
geronimo-plugin-archetype runs (part of) the geronimo deployment  
system on the javaee app to figure out what it is and determine  
required dependencies
geronimo-plugin-archetype includes these dependencies in the generated  

We already have a plugin (car-maven-plugin) that can run the geronimo  
deployment system, so I can probably figure out a way to just write a  
plugin to do this fairly easily.  However it would be nice to have  
this functionality as an archetype so it can easily be run from e.g.  

Hopefully this is a little bit clearer...
david jencks

>> 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:
> Thanks,
> Jason
> ----------------------------------------------------------
> 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:

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

View raw message