Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current ·  View Page History
<< Previous Version 5 Next >>

Overview

This guide will walk you through

  • downloading the latest source code from the trunk of a plugin
  • building the plugin
  • creating JIRA issues
  • modifying the plugin source code
  • deploying the plugin to an internal repository for use within your company
  • creating patches and attaching to JIRA
  • applying patches retrieved from JIRA

Downloading the latest source code from the trunk of a plugin

Maven uses Subversion as it's source control repository. The base subversion repository is located at http://svn.apache.org/repos/asf/maven. Within this structure there are a number of different directories of useful files:

Using your favourite subversion tool, check out the plugin you want (e.g. http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-assembly-plugin)

Building the plugin

Maven developers try to ensure that the trunk always builds via. To build your copy use mvn package.

However because the plugin may be using snapshot versions of other plugins, you will need to ensure you have setup your environment correctly to obtain any dependencies from the snapshot repositories. See the Maven Development Procedures for more details on how to configure your environment. You may also want to read Guide to Testing Development Versions of Plugin and
Guide to Plugin Snapshot Repositories (this guide contains the codehaus snapshot repository setup)

Creating JIRA issues

Find the project for the maven plugin at http://jira.codehaus.org/secure/BrowseProjects.jspa.

Before you create a new JIRA issue you should confirm that there is no existing issue already available.
If one already exists, check what other people have suggested for a suitable solution. If there is a patch already, try using that before making your own modifications.

Modifying the plugin source code

The first step should to create a unit test.

After the unit test has been created modify the code to pass the unit test.

Once the unit test is passing you can then build the plugin and attempt to use it locally via mvn install. You should check that the plugin works as expected in your project.

Deploying the plugin to an internal repository for use within your company

If you have an internal repository that is used by your company then you will want to deploy your patched versions to this repository until your patches have been applied to the plugin. If you don't have an internal repository you should consider setting one up, see Using Maven in a corporate environment for more details.

Before you start, ensure that your pom file does not depend upon any SNAPSHOT versions, if it does you for each SNAPSHOT version you will need to checkout the trunk for that artifact, build it and then follow the steps below to promote it to an internal release, otherwise you won't have any control over the build process. (For the dependencies that you are not modifying the code base for, you can skip the copy of the pom and just make the changes directly)

Copy the pom.xml to pom-internal.xml and make the following changes to the pom-internal.xml file. And add pom-interal.xml to the svn ignore list.

  • Set the version to be -INTERNAL instead of -SNAPSHOT. See Better Builds with Maven (June 2006) page 61 for an explanation of how version numbers are compared. e.g. if the version is 2.2-SNAPSHOT then set it to 2.2-INTERNAL when the plugin is officially released as 2.2 the released version will be considered newer than your patched version and supersede it.
  • Add a distributionManagement section:
  • Remove any snapshot repository definitions
  • Any SNAPSHOT dependencies need to be internally released by following the above instructions. The dependency version is then changed from -SNAPSHOT to -INTERNAL. This can be quite a long process of chasing the dragon's tail.
  • You will need to also chase parent definitions that are a SNAPSHOT version. Since you only need the pom definition use mvn -N to avoid recursing into the module directories (which you don't care about and don't need to checkout). There is a good chance there is already a distributionManagement section so just paste the new one over the top of the existing one. Parent poms are located one directory above the current pom, unless there is a relativePath declaration.

The changes can now be deploy to your internal repository via mvn -f pom-internal.xml deploy.

Creating patches and attaching to JIRA

In the root directory of the plugin you have been modifying use svn diff > ../JIRA COMPONENT-JIRA ID-patch.txt e.g. svn diff > ../MASSEMBLY-118-patch.txt.

Find the JIRA issue you previously created and click the Attach file link on the left side under the Operations links. In the comment text area provide a brief description of the patch contents and anything of interest that should be pointed out.

Applying patches retrieved from JIRA

Labels
  • None