Here are the consolidated design notes for the plugin. It's in maven APT format, so if you like to read the html version better, just cut and past into a maven project and run mvn site.
------------------------------------------- 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>//[EMAIL PROTECTED]'runtime']</jpp:depends> </jpp:specmapping> <jpp:specmapping> <jpp:header>BuildRequires</jpp:header> <jpp:depends>//[EMAIL PROTECTED]'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> ------------------------------------------------------------------------- ____________________________________________________________________________________ Low, Low, Low Rates! Check out Yahoo! Messenger's cheap PC-to-Phone call rates (http://voice.yahoo.com)