Ole,

seems pretty cool, and I must admit that it's somehow rare that somebody put some specs before coding !!! (unless you already coded it and retro-engineered it ;)

What about putting this doco on cwiki? We have a space for ADS 1.1 where we can put some doco, which will not been lost in the ML forever until the next google search, and on which anybody will be able to put some comments.

Here is a link on the wiki :
http://cwiki.apache.org/confluence/display/DIRxSRVx11/Index

Ok, right now, it's pretty crude, but we can reorganize the whole wiki latter.

wdyt ?

Ole Ersoy a écrit :

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)



Reply via email to