You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Ole Ersoy <ol...@yahoo.com> on 2006/10/29 00:17:29 UTC
RPM Plugin Conslidated Initial Design Notes
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)
Re: RPM Plugin Conslidated Initial Design Notes
Posted by Ole Ersoy <ol...@yahoo.com>.
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 <el...@gmail.com> 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)
Re: RPM Plugin Conslidated Initial Design Notes
Posted by Emmanuel Lecharny <el...@gmail.com>.
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)
>
>
>
>