maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raphaël Piéroni" <raphaelpier...@gmail.com>
Subject Archtypeng - summary of features
Date Mon, 14 May 2007 14:06:42 GMT
Hi,

Here comes my current feature list on the archetypeng development.

-1 archetype groups in archetype registry

   Archetype groups are the known groupIds of archetypes. THey are defined
   in a file (~/.m2/archetype.xml) and are used during the interactive
   archetype selection to prompt the user a list to choose from. The
   defaults groups are org.apache.maven.archetypes and
org.codehaus.mojo.archetypes

-2 archetype repositories in archetype registry

   Archetype repositories are the mavenrepositories in which the archetypes
   reside. The list of repositories are located in the archetype registry
   file and can be communicated to the mojos using the -D option (both are
   merged at runtime).

1 languages directories and filtered extensions in archetype registry

   Languages directories are directories in which reside a project's
   files that needs to be 'packaged' (like src/main/java). Files in
   other directories will be seen as 'unpackaged'

   Filtered extensions are the files extensions that permit to
   separate in two, the files that will be merged as Velocity templates
   and the files that will be copied only.

   Both options can be defined as mojo properties (-D or pom configuration)
   or in the archetype registry file (~/.m2/archetype.xml) which
   also contains the list of known archetype groups and the list of
   maven repositories in which archetypes are located.

   I will need default values for both when the neither the registry nor
   the mojo property are set.

2 comprehensive logs

   Current logs are somehow not really usable and should be more informative

3 sample properties mojo

   It will be a mojo that takes an archetype definition (groupId,
   artifactId, version) and that gives an archetype.properties 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.

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

5 integration tests of mojos

   Basic integration test of mojo should checks that taking a maven project,
   the archetype creation process using the project followed by the project
   generation process using the resulting archetype gives the same project.

   Another basic integration test will take an archetype and process the
project
   generation on it then process the archetype creation on the resulting
project
   and will ensure both archetypes are equivalent.

   Integration tests of mojos should be located in the plugin module or in
an
   ad hoc module.

6 integration test of sample archetypes

   The archetypeng project (as its predecessor archetype project) comes with
   a set of sample archetypes for basic usage. these archetypes should be
   integration tested.

7 documentation plugin

   The archetypeng project should provide a comprehensive documentation on
using
   the usage of the mojos. The current documentation at mojo is a bit
outdated
   as the archetypeng descriptor has changed since i wrote it.

8 documentation components and api

   The archetypeng project should provide a comprehsive documentation
   of its architecture for the archetype developers and for the ide
   embedment.


Based on a previous email in which i said i saw the current revision (r4054)
of
archetypeng as the first alpha.
I have schedules the above features in:
-1, -2 (both are coded but not committed), 1, 2 in the second alpha
3, 4 in the third alpha
5, 6 in the second beta
7, 8 int first beta


I also have an unsheduled list of features (because i don't envision
a simple solution or don't envision a real need, or don't envision the
feature but its name)

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

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.

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

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.

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

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

G creating empty directories


I also have some open questions (i don't have answers)

- Are archetypes first class artifacts or are they clasifiers of a project?

   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.

   Should the archetype resulting be a project on itself?
   I see it as a question that leads to different solutions when taking
account
   of the interactive selection and the fact that repositories metadata
(group and artifact)
   are used to prompt the user.

   If the archetypes are first class, it will be easy to attach metadata for

   the install/deploy phases (Brett, thanks for the plugin-plugin link)

   If the archetypes are classifiers, it will be easy to create them as part
of
   a project build.



During the current week, i have only sporadic internet acces so feel free
to test the current (first alpha) archetypeng.

Please send any though about the above features.
I am particularly insterested in discuting the unscheduled features and open
question
and also in a example (or link) for an answer to features 5 and 6.

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?

I hope to make sense with this email.

Regards,

Raphaël
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message