-------------------------------------------
JPackage RPM Plugin Design
-------------------------------------------
Objective
The Objective of the JPackage Maven RPM Plugin
is to enable generation RPMs that comply
with JPacakge standards.
The plugin should enable the generation of
an RPM for all maven builds.
Initial priority has been the packaging of
daemons and libraries.
RPM Archetype
An RPM Archetype that
provides a plugin baseline
configuration will be distributed along side
the plugin. This way the amount of effort
required to generate JPackage compliant
RPM is minimized.
Creating a JPackage RPM Project
In order to have their project
packaged with the JPackage RPM
Plugin, a developer must first create
a JPackage RPM Project using
the Archetype provided with the plugin.
The JPackage RPM project created will then have
the main project that the developer is
working on as a dependency.
This is because we want all the test
and verification phases to be run prior
to packaging the project.
So for packaging Apache Directory Server
for instance, we would create the
an ApacheInstaller Project (With the JPackage
Archetype), and add
the ApacheDirectoryServer project
as a dependency.
In the configuration section for the JPackage
RPM plugin in the ApacheInstaller project
(Inside the pom.xml file) we would specify the
packaging target being the ApacheDirectoryServer
using the project's artifactId and group id.
If the ApacheDirectoryServer project that the
configuration points to is a parent project,
then the JPackage RPM Plugin will generate
RPMs for all the children of that project.
This does require further configuration
in terms of the types of projects
that the child projects are.
For instance some of them may just be libraries
and others may be servers.
JPackage RPM Plugin Configuration
The plugin will support specific
RPM generation cases.
For instance one case would be
the generation of an RPM for a
daemon project.
Another case would be the generation
of an RPM for a library projects.
Plugin Update Lifecycle
The plugin needs to be updated
under the following circumstances:
- To support further customization of
the generated spec file. - To support new configuration options.
Plugin Phase
The plugin will be invoked during the
package phase of the maven lifecycle.
Plugin Process
- Requirements
The plugin requires that
the project that is its target
generate a .gz source archive and
place it in the maven local maven
repository.
- Steps
The plugin pulls the source archive
from the repository and places it in the
rpm build environment's SOURCE folder.
It then generates the spec file
and puts it in the SPEC folder
of the RPM build environment.
It then builds the RPM according
to the instructions in the generated
spec file.
Plugin Architecture
- Spec file generation
A JET (Java Emitter Template) template supports
the generation of the spec file.
There will be one template for each RPM case.
Thus daemons will have a template specific
to daemon RPM generation, etc.
See http://www.eclipse.org/emft/projects/jet/
- POM 2 Spec mapping
The plugin sources as many parameters
as possible from the target project's
pom.xml file.
The parameters that it sources can
be overridden in the configuration
of the plugin.
In order to map the pom to the spec
annotations have been placed in the
maven pom xml schema indicating
how maven pom elements map to the
spec file.
Thus the plugin uses the schema
to for as the source of the pom 2 spec
map.
http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd
-------------------------------------------------------------------------
POM 2 Spec Mapping Start
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:jpp="http://jpackage.org/maven/plugins/">
<xsd:element name="name" type="xsd:string">
<xsd:annotation>
<xsd:appinfo>
<jpp:specmapping>
<jpp:header>name</jpp:header>
</jpp:specmapping>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="version" type="xsd:string">
<xsd:annotation>
<xsd:appinfo>
<jpp:specmapping>
<jpp:header>Version</jpp:header>
</jpp:specmapping>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="licenses" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
Maven supports many license elements,
so as a rule we could just grab the first one,
or concatenate the licenses into a string.
</xsd:documentation>
<xsd:appinfo>
<jpp:specmapping>
<jpp:header>License</jpp:header>
</jpp:specmapping>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="dependencies" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
Dependencies with the
scope attribute set to runtime
should map to the Requires Header.
Dependencies with
scope attribute set to compile
should map to the BuildRequires Header
TODO - Remember to put something
about the (post) thing on
Requires...
</xsd:documentation>
<xsd:appinfo>
<jpp:specmapping>
<jpp:header>Requires</jpp:header>
<jpp:depends>//dependency@scope='runtime'</jpp:depends>
</jpp:specmapping>
<jpp:specmapping>
<jpp:header>BuildRequires</jpp:header>
<jpp:depends>//dependency@scope='compile'</jpp:depends>
</jpp:specmapping>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="dependencies" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
</xsd:documentation>
<xsd:appinfo>
<jpp:specmapping>
<jpp:header>BuildRequires</jpp:header>
<jpp:depends>BuildRequires</jpp:depends>
</jpp:specmapping>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="url" type="xsd:string">
<xsd:annotation>
<xsd:appinfo>
<jpp:specmapping>
<jpp:header>url</jpp:header>
</jpp:specmapping>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:schema>
<xsd:element name="description" type="xsd:string">
<xsd:annotation>
<xsd:documentation source="version">
Maybe the Maven POM description should map to
to the Summary header.
</xsd:documentation>
<xsd:appinfo>
<jpp:specmapping>
<jpp:section>%description</jpp:section>
</jpp:specmapping>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:schema>
-------------------------------------------------------------------------