oh thanks - I usually write up how I think it should work before I code...It helps me think through the design alot...just seeing my own thoughts on paper and walking myself through it...
Still a lot of stuff to add... Sure I'll get it up on the wiki. Hope to have some code to go along asap. Cheers, - Ole --- Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > 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"; > === message truncated === ____________________________________________________________________________________ Access over 1 million songs - Yahoo! Music Unlimited (http://music.yahoo.com/unlimited)
