directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: RPM Plugin Conslidated Initial Design Notes
Date Sat, 28 Oct 2006 22:38:20 GMT
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>//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>
>
>-------------------------------------------------------------------------
>    
>
>
>
> 
>____________________________________________________________________________________
>Low, Low, Low Rates! Check out Yahoo! Messenger's cheap PC-to-Phone call rates 
>(http://voice.yahoo.com)
>
>
>  
>


Mime
View raw message