Maven Archetype

Better Archetype template processing support

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Trivial Trivial
  • Resolution: Won't Fix
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    1

Description

I really love the maven 2 archetype concept and have developed an enhanced version that utilizes the velocity templating engine to a greater degree. While the code is fully functionality it needs to be cleaned up and the documentation enhanced. Please feel to incorporate any part of this back into maven 2 if any of it is appealing. If desired I could also enhance the code to make it a better contribution as well.

To test out the archetype functionallity, run mvn install in both archetype (new plugin) and jbi-component (sample archetype)

to execute the new archetype, run
C:\temp\maventest> mvn com.javaforge.bobber:bobber-archetype:1.0-SNAPSHOT:create -DarchetypeGroupId=com.javaforge.bobber -DarchetypeArtifactId=maven-archetype-jbi-component -DarchetypeVersion=1.0-SNAPSHOT -DgroupId=com.newarchetype -DartifactId=test

in the same way the default archeype functionality works.

Issue Links

Activity

Hide
Jason van Zyl added a comment -

Can you explain what it is exactly you changed. You either have to comment or provide a patch so I can see the differences.

Show
Jason van Zyl added a comment - Can you explain what it is exactly you changed. You either have to comment or provide a patch so I can see the differences.
Hide
Aaron Anderson added a comment -

To elaborate, I have enhanced the functionality of the archetype implementation to better harness the versatility of the velocity templating engine. This enhancement could be used to address ARCHETYPE-23 and ARCHETYPE-26. This enhancement involved creating a new Archetype implementation and tweaking the existing ArchetypeMojo.

The ArchetypeMojo was only enhanced to take in a packageName value such as com.mypackage and compute a package value such as com/mypackage. This could probably be rolled into the new Archetype implementation.

The real meat of the modification takes place in the new archetype implementation BobberArchetype. It is slightly refactored and adds the following functionality:

1. Unzips the archetype as is to the destination directory
2. it reads in a archetype descriptor that contains variables and templates
3. For each variable, it reads in the default value and the value from the System properties
4. If maven is run in interactive mode, it prompts for each value
5. After all the values are determined, it process all the macros in the archetype descriptor
6. After it process the archetype, for each template in the descriptor that ends in .vm, it process the template using the variables specified earlier.

Here is an example archetype I have created:

<archetype>
<id>maven-archetype-jbi-component</id>
<variables>
<variable>
<name>ComponentName</name>
<description>JBI Component Name</description>
<defvalue>JBI</defvalue>
</variable>
<variable>
<name>ServiceName</name>
<description>service-name value used to read endpoint name from the SU deployment descriptor</description>
<defvalue>JBI</defvalue>
</variable>
<variable>
<name>ServiceEngine</name>
<description>Boolean flag if JBI Component is a service engine</description>
<defvalue>false</defvalue>
</variable>
</variables>
<templates>
<template>
<file>pom.vm</file>
<output>pom.xml</output>
</template>
<template>
<file>component/pom.vm</file>
<output>component/pom.xml</output>
</template>
<template>
<file>component/src/main/jbi/META-INF/jbi.vm</file>
<output>component/src/main/jbi/META-INF/jbi.xml</output>
</template>
<template>
<file>component/src/main/jbi/ping.vm</file>
<output>component/src/main/jbi/ping.wsdl</output>
</template>
<template>
<file>boot/pom.vm</file>
<output>boot/pom.xml</output>
</template>
<template>
<file>boot/src/main/java/Bootstrap.vm</file>
<output>boot/src/main/java/${packagePath}/${ComponentName}Bootstrap.java</output>
</template>
<template>
<file>runtime/pom.vm</file>
<output>runtime/pom.xml</output>
</template>
<template>
<file>runtime/src/main/java/SUManager.vm</file>
<output>runtime/src/main/java/${packagePath}/${ComponentName}SUManager.java</output>
</template>
<template>
<file>runtime/src/main/java/Component.vm</file>
<output>runtime/src/main/java/${packagePath}/${ComponentName}Component.java</output>
</template>
<template>
<file>runtime/src/main/java/Lifecycle.vm</file>
<output>runtime/src/main/java/${packagePath}/${ComponentName}LifeCycle.java</output>
</template>
</templates>
</archetype>

When the custom archetype plugin runs and calls the archetype implementation, It first extracts the archetype files as is from the zip. Next it iterates through the variables and sets their values to the default value and then sets them from the System properties in case they were set at the command line. In interactive mode, it iterates through the variables and displays the description and default value and prompts the user for new values if desired. After all the values are read in and their values set, the archetype implementation iterates through the templates and processes them, outputing the template output to the interpreted output path and then deletes the .vm template.

This implementation allows greater flexability by:

1. Unziping all files in the archetype to the destination directory. Typically one would not put files in the archetype unless they are expected to be used.
2. Introduces the concept of variables that may be used in templates, allowing archetype creators expanded capabilities when creating templates
3. Allows interactive prompts to confirm default values or override them
4. Customizable template output files so Java files can be generated to correct package paths.

Show
Aaron Anderson added a comment - To elaborate, I have enhanced the functionality of the archetype implementation to better harness the versatility of the velocity templating engine. This enhancement could be used to address ARCHETYPE-23 and ARCHETYPE-26. This enhancement involved creating a new Archetype implementation and tweaking the existing ArchetypeMojo. The ArchetypeMojo was only enhanced to take in a packageName value such as com.mypackage and compute a package value such as com/mypackage. This could probably be rolled into the new Archetype implementation. The real meat of the modification takes place in the new archetype implementation BobberArchetype. It is slightly refactored and adds the following functionality: 1. Unzips the archetype as is to the destination directory 2. it reads in a archetype descriptor that contains variables and templates 3. For each variable, it reads in the default value and the value from the System properties 4. If maven is run in interactive mode, it prompts for each value 5. After all the values are determined, it process all the macros in the archetype descriptor 6. After it process the archetype, for each template in the descriptor that ends in .vm, it process the template using the variables specified earlier. Here is an example archetype I have created: <archetype> <id>maven-archetype-jbi-component</id> <variables> <variable> <name>ComponentName</name> <description>JBI Component Name</description> <defvalue>JBI</defvalue> </variable> <variable> <name>ServiceName</name> <description>service-name value used to read endpoint name from the SU deployment descriptor</description> <defvalue>JBI</defvalue> </variable> <variable> <name>ServiceEngine</name> <description>Boolean flag if JBI Component is a service engine</description> <defvalue>false</defvalue> </variable> </variables> <templates> <template> <file>pom.vm</file> <output>pom.xml</output> </template> <template> <file>component/pom.vm</file> <output>component/pom.xml</output> </template> <template> <file>component/src/main/jbi/META-INF/jbi.vm</file> <output>component/src/main/jbi/META-INF/jbi.xml</output> </template> <template> <file>component/src/main/jbi/ping.vm</file> <output>component/src/main/jbi/ping.wsdl</output> </template> <template> <file>boot/pom.vm</file> <output>boot/pom.xml</output> </template> <template> <file>boot/src/main/java/Bootstrap.vm</file> <output>boot/src/main/java/${packagePath}/${ComponentName}Bootstrap.java</output> </template> <template> <file>runtime/pom.vm</file> <output>runtime/pom.xml</output> </template> <template> <file>runtime/src/main/java/SUManager.vm</file> <output>runtime/src/main/java/${packagePath}/${ComponentName}SUManager.java</output> </template> <template> <file>runtime/src/main/java/Component.vm</file> <output>runtime/src/main/java/${packagePath}/${ComponentName}Component.java</output> </template> <template> <file>runtime/src/main/java/Lifecycle.vm</file> <output>runtime/src/main/java/${packagePath}/${ComponentName}LifeCycle.java</output> </template> </templates> </archetype> When the custom archetype plugin runs and calls the archetype implementation, It first extracts the archetype files as is from the zip. Next it iterates through the variables and sets their values to the default value and then sets them from the System properties in case they were set at the command line. In interactive mode, it iterates through the variables and displays the description and default value and prompts the user for new values if desired. After all the values are read in and their values set, the archetype implementation iterates through the templates and processes them, outputing the template output to the interpreted output path and then deletes the .vm template. This implementation allows greater flexability by: 1. Unziping all files in the archetype to the destination directory. Typically one would not put files in the archetype unless they are expected to be used. 2. Introduces the concept of variables that may be used in templates, allowing archetype creators expanded capabilities when creating templates 3. Allows interactive prompts to confirm default values or override them 4. Customizable template output files so Java files can be generated to correct package paths.
Hide
Andrew Perepelytsya added a comment -

This contribution is exactly what I was struggling for a while. The current m2 templating mechanism is weak, as it targets poms mostly, not project artifacts. This new template worked well for me. The following 2 minor notes (which do not affect the contribution code, however):

  • JBI component artifact's pom declares a dependency on the parent (one of bobber ones). This is not required to run the sample, just comment it out.
  • There are minor typos in jbi.xml Velocity template (jbi.vm), namely missing dot after a package placeholder, slash in a package name (while others are dots). This is just a template tweak, so if anyone tries this, that's not the fault of the plugin, but just a simple VM file

I would really love this one to be put eventually under standard maven-plugins groupId so there's no need to fully qualify the archetype name. And, if possible, target the inclusion for Maven 2.0.5

Show
Andrew Perepelytsya added a comment - This contribution is exactly what I was struggling for a while. The current m2 templating mechanism is weak, as it targets poms mostly, not project artifacts. This new template worked well for me. The following 2 minor notes (which do not affect the contribution code, however):
  • JBI component artifact's pom declares a dependency on the parent (one of bobber ones). This is not required to run the sample, just comment it out.
  • There are minor typos in jbi.xml Velocity template (jbi.vm), namely missing dot after a package placeholder, slash in a package name (while others are dots). This is just a template tweak, so if anyone tries this, that's not the fault of the plugin, but just a simple VM file
I would really love this one to be put eventually under standard maven-plugins groupId so there's no need to fully qualify the archetype name. And, if possible, target the inclusion for Maven 2.0.5
Hide
Casey Butterworth added a comment -

Any idea when this might happen? I'd love to provide a multi module maven archetype for our projects and at this stage am unable to.

Show
Casey Butterworth added a comment - Any idea when this might happen? I'd love to provide a multi module maven archetype for our projects and at this stage am unable to.
Hide
Jason van Zyl added a comment -

Addressed in ArchetypeNG.

Show
Jason van Zyl added a comment - Addressed in ArchetypeNG.

People

Vote (6)
Watch (7)

Dates

  • Created:
    Updated:
    Resolved: