You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by David Jencks <da...@yahoo.com> on 2009/04/04 19:13:32 UTC
Archetype capabilities/limitations?
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.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Archetype capabilities/limitations?
Posted by David Jencks <da...@yahoo.com>.
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
pom
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.
m2eclipse.
Hopefully this is a little bit clearer...
thanks
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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> ----------------------------------------------------------
>>>
>>> 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: 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
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
> 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: 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
Re: Archetype capabilities/limitations?
Posted by Jason van Zyl <jv...@sonatype.com>.
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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>>
>> 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: 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
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Archetype capabilities/limitations?
Posted by David Jencks <da...@yahoo.com>.
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. 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?
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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
> 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: 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
Re: Archetype capabilities/limitations?
Posted by Jason van Zyl <jv...@sonatype.com>.
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org