maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: Archtypeng - summary of features
Date Mon, 21 May 2007 05:58:03 GMT
I think the key thing is to focus on a stable code base that can be  
released as more functional than the last. With the addition of  
create-from-project, I'm more than happy with the feature-set of  
archetype and we should focus on a 1.0 that is properly documented,  
API stable, and all those good things.

In your list, it all sounds good. I didn't see anything in there that  
needed to be done for 1.0 that wasn't already being done, myself  
(except perhaps the integration testing and documentation which are  
both important).

More feedback below:

On 15/05/2007, at 12:06 AM, Raphaël Piéroni wrote:

> 3 sample properties mojo
>   It will be a mojo that takes an archetype definition (groupId,
>   artifactId, version) and that gives an file  
> loaded
> with
>   the archetype definition an the required properties of that  
> archetype
> filled
>   with the archetype's default values or 'Not Defined' when the  
> archetype
> don't
>   defines any default value for a property.

I don't really understand this one still, and am generally unsure  
about the approach taken with

> 4 add, remove, show mojos for groups, repositories, langiages and  
> filtered
> extensions
>   It will be a set of mojos that reads or modify the content of the
> archetype
>   registry, for convenience instead of hand-edit the ~/.m2/ 
> archetype.xml
> file

Cautious about "overdoing" the archetype registry (see past mistakes  
with the plugin registry).

> A refactor the common module to have each of the component packaged in
>   a directory containing the name of the component (it could be  
> usefull,
>   as plexus components located in the same package as a mojo usin  
> them, but
>   in another module are not correctly resolved in the plugin.xml  
> file).

This sounds like a problem of coupling the archetype API to it's use  
as a mojo. Couldn't we have DTO's in the plugin instead?

> B refactor the pom management during archetype creation or project  
> creation.
>   As both should be taken care about the removing of the parent of the
> project
>   that will be used to create an archetype from or that the pom of a
> project
>   in which we create a module from an archetype or use a partial  
> archetype
> on it.

I'm not sure I understand this, could you explain with an example?

> C provide default values for the common required properties of each
> archetypes
>   (groupId, artifactId, version, packageName) during the project  
> generation
> process.

Is this to provide backwards compatibility with how archetype:create  
used to work, or something different?

> D load the Velocity context during the project generation with  
> velocity
> tools
>   in order to provide date formating and other features for files  
> that are
> filtered.

Seems straightforward and useful?

> E hooking some behaviour during project generation (as the merge of  
> a file
> like web.xml)
>   when using a partial archetype.

How are partial archetypes working now? They must already merge into  

In this case, we should definitely reuse other XML merging tools that  
keep popping up - but I'm not sure this feature is needed for 1.0.

> F having a packaging for archetype projects
>   This will permit to upload group-metadata for the interactive  
> selection

I think this is important.

> G creating empty directories

Not sure this is so important, maybe just a post-1.0 feature request  
and let people vote on it.

> I also have some open questions (i don't have answers)
> - Are archetypes first class artifacts or are they clasifiers of a  
> project?

First class.

>   This question raise when you try to create a complicated  
> archetype from a
> project
>   and defining the mojo properties in the plugin configuration in the
> project's pom.

I don't think the created archetype is in any way associated with the  
project it was created from.

>   Should the archetype resulting be a project on itself?

Yes, I think so.

> Could any despot, please, create a first jira wih one of the scheduled
> features in the
> ARCHETYPE project as an example for me to create the others. I had  
> been
> reluctant to use
> it, for now, because, i never have used jira with admin karma, and  
> don't
> want to make
> a mistake and becaus they are currently jiras for the actual  
> archetype. THe
> point that
> leave me uncertain are: which version assign the jiras for  
> archetypeng, do i
> need
> a specific wording in the jiras' titles?

The 1.0 version is already there, and in my mind that is what we are  
working towards. I'd like to unify the efforts around one codebase.

I'd say create issues in ARCHETYPE under 1.0 which already exists  
(there's nothing currently scheduled for that). I've removed the  
unused 1.1-alpha-1 and 2.0-alpha-1 versions which seemed to be  
getting quite a bit ahead of ourselves.

Thanks again!

- Brett

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

View raw message