Working With Custom Maven Archetypes (Part 3)
In part 1 and part 2 of this series I was able to demonstrate how you can create a custom archetype and release it to a Maven repository. In this final part we’ll look at what you need to do to integrate it into your development process. This will involve the following steps:
- Uploading the archetype and its associated metadata to a Maven Repository Manager.
- Configuring an IDE to use the archetype.
- Generating a skeleton project from the archetype.
Step 1 – Upload your archetype
In part 2 we covered releasing and deploying the archetype. For reasons of brevity I simply demonstrated deploying a release to the local file system, but if we wish to share our archetype we must deploy it to a remote repository that can be accessed by other developers. A remote Maven repository, in its simplest form, can be served up using a Http server such as Apache or Nginx. However, these days I would recommend that you use a Maven Repository Manager (MRM) instead, as these tools are purpose-built for serving (and deploying) Maven artefacts. There are basically three options for your MRM – Nexus, Artifactory or Archiva. A features matrix comparision is available here. All are available in open source flavours and both Nexus and Artifactory in particular are great tools. However, currently Artifactory is the only one that supports a Cloud-based service option which, as you might expect, integrates very well with our hosted Continuous Integration service. This allows you to provision yourself a fully-fledged MRM in very short order.
So, how do we add our archetype to the repository? This is a simple
process using the built in Artifact Deployer of Artifactory which
allows you to upload a file and supply its Maven GAV co-ordinates.
Next, we need to add some additional metadata about our archetype in the form of a ‘catalog’:
<?xml version="1.0" encoding="UTF-8"?>
<description>Mike CI archetype for creating a Spring-Mvc web application.</description>
This file should ideally be placed into an appropriate folder of a Maven repository and it contains information about all of the archetypes that live within the repository. We can simply add this file to our ‘libs-releases’ repository using Artifactory’s REST API:
curl -u username:password -f -d @archetype-catalog.xml -X PUT "http://mikeci.artifactoryonline.com/mikeci/libs-releases/archetype-catalog.xml"
Step 2 – Configure your IDE
Now that our archetype is deployed remotely, we can start to use it from within our IDE – in my case – Eclipse. To get good Maven integration inside Eclipse, you really should be using the latest release (0.10.0) of m2eclipse. Once m2eclipse is installed, it provides a handy feature that allows you to add and remove archetype catalogs. You will need to add your deployed archetypes catalog to the list of catalogs accessible from within m2eclipse. This ensures that you can access your custom archetypes when you run the Create a Maven Project wizard in Eclipse as we will see shortly.
Choose the menu item, Windows>Preferences, to open the
Preferences dialog and drill down to the Maven>Archetypes
preferences, as shown.
Click Add Remote Catalog to bring up the Remote Archetype Catalog dialog. In the Catalog File text box, enter the path to your remote catalog file and in the Description text box, enter a name for your catalog:
Step 3 – Generate your project
You should now be ready to generate a skeleton Maven project inside
Eclipse. Choose the menu item, File>New>Other, to open the Select
a wizard dialog. From the scrollbox, select Maven Project and then
click Next. Follow the wizard to configure your project location.
Eventually, the wizard allows you to select the archetype to generate
your Maven project. From the Catalog drop-down list, select your custom
catalog. Then locate and select your archetype :
Click Next and enter the GAV values for your new project. Et voila – you should have just created a skeleton project based upon your custom archetype using a slick IDE wizard.
Pretty impressive, don’t you think?
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)