Notes on the JPackage version of Maven2 (2.0.10)

The maven2 version released with JPackage has extensive modifications to ensure that it works smoothly in off-line mode. In order to facilitate easier maintainability, minimal changes have been made, and most have been kept in separate source files rather than patching into maven code.

How to use it:
Previously, when one needed to create a new rpm, for the build part they needed to set up a depmap, run all poms in a project via an xsl transformation that used the depmap to rewrite groupid's/artifactid's/etc., supply repository locations, and then call maven. Most of that has now been done away with.

Starting with the 9jpp release, to invoke maven in jpp mode, simply type 'mvn-jpp' with the -Dmaven2.jpp.depmap.file="..." argument if a separate depmap is needed. The command action is almost the same as "mvn" -- only that it supplies '-Dmaven2.offline.mode -Dmaven2.ignore.versions -Dmaven2.usejppjars' prior to invoking maven.

Dependency maps/'depmaps':
To build a new project for a new JPackage rpm, a depmap still needs to be created so as to allow finding of the new jars. But this is not too different from the old way of using build-jar-repository with ant. The idea is the same -- tell the build tool where to find the required libraries.

The depmap has entries in the format:

<dependencies>
..
    <dependency>
        <maven>
            <groupId>OGROUPID</groupId>
            <artifactId>OARTIFACTID</artifactId>
            <version>OVERSION</version>
        </maven>
        <jpp>
            <groupId>NGROUPID</groupId>
            <artifactId>NARTIFACTID</artifactId>
            <version>NVERSION</version>
        </jpp>
    </dependency>
..
<dependencies>


Where OGROUPID, OARTIFACTID and OVERSION are old group/artifact/versions (as they exist in your project) and NGROUPID, NARTIFACTID, NVERSION are the new ones. For example:
    <dependency>
        <maven>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>3.8.1</version>
        </maven>
        <jpp>
            <groupId>JPP</groupId>
            <artifactId>junit</artifactId>
            <version>3.8.1</version>
        </jpp>
    </dependency>
The above mapping indicates that if any of the poms need an artifact with groupid=junit, artifactid=junit and version=3.8.1, it can be found at $REPOSITORY/JPP/junit.jar

Where $REPOSITORY is one of the active repositories with layout="jpp" ("jpp" is a new layout that has been added to our maven2 rpm).

If maven2.ignore.versions is specified, any requirement of groupid=junit, artifactid=junit will be satisfied with $REPOSITORY/JPP/junit.jar (i.e. version will be ignored even if mentioned in the depmap).

If only a <maven> element is supplied and no <jpp>, it is assumed that the dependency is to be discarded. For example, some projects depend on the 'velocity-dep' which has no equivalent jar in JPackage packages as velocity-dep is just a monolithic jar containing velocity dependencies. To remove velocity-dep then, you would add:
    <dependency>
        <maven>
            <groupId>velocity</groupId>
            <artifactId>velocity-dep</artifactId>
            <version>1.4</version>
        </maven>
    </dependency>
to the depmap.

There are two system depmaps. An unversioned one is located at: /etc/maven/maven2-versionless-depmap.xml. This is used when -Dmaven2-ignore-versions is specified. A versioned one is located at /etc/maven/maven2-depmap.xml. This is an autogenerated map which is rebuilt each time the update_maven_depmap macro is called by an rpm. Finally, a custom one can be specified via -Dmaven2.jpp.depmap.file="..."

The versionless one contains depmap entries for items whose poms are installed by maven2-common-poms (for now). As time passes, more and more packages will start using the add_to_maven_depmap and update_maven_depmap macros and hopefully, the versionless can be phased out completely. If your project needs a mapping that is not already in there, you will have to create a separate file and use it via the above mentioned property.

The custom depmap has highest preference, followed by the versioned depmap, followed by the versionless one

Packages adding their own depmaps:
Packages from now on should add their own depmap fragments when they get installed. This is achieved by calling the add_to_maven_depmap macro for each jar/artifact being installed, followed by calling update_maven_depmap in the post and postun sections (note: this means that there will have to be a jpackage-utils >= 0:1.7.2 post and postun requirement for all packages that do this, since jpackage-utils 1.7.2 provides the macros). Finally, %{_mavendepmapfragdir} (=/etc/maven/fragments) should be added in the %files section of the main package. The idea is as follows:

The %install section of each package uses the add_to_maven_depmap macro for each jar/pom that the main package and it's subpackages install. The macro puts the resulting data in $RPM_BUILD_ROOT%{_mavendepmapfragdir}/%{name}. update_maven_depmap in the post and postun then cat's /etc/maven/fragments/* into /etc/maven/maven2-depmap.xml which is read whenever mvn is run. See the plexus-cdc spec for a simple example, and maven-doxia for a more complex one.

New properties: