directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: [COLLABORATION] James
Date Tue, 13 Feb 2007 02:23:17 GMT
Hey Guys,

Alex - Thanks for the terrific elaboration on the

I'll make sure I get it into the design documents.

I decided to part ways with JPackage pretty much.  The
only thing I'm taking away from how they do things is
the FHS file system layout convention for server and
library installs.

I'll just do a quick approach summary here, since I'm
going to put more info in a detailed design document.

[RPM Factory]
A) Create an RPM Mirror of the Entire Maven Ibiblio
B) Create a Server Installer RPM
C) Yum will automatically pull the Server Installer
RPM's dependencies and place them in 


Thus James and ApacheDS would both load their classes
from there.

So once this is done for RPM, parallel efforts can be
started to create a similar installers for the other
Debian, Solaris, etc.

Windows is a slightly different animal.  I'll have a
better idea what needs to be done with that once I'm
done with the full blown RPM stuff.

So as soon as the RPM Factory piece is done, I'll
start  dive headfirst into the Bootstrappers, like
Alex is recommending.

More to come very soon :-)

- Ole

--- Alex Karasulu <> wrote:

> Stefano Bagnara wrote:
> > Ole Ersoy ha scritto:
> [SNIP]
> Once that's done, I
> >> need to start looking at the
> >> Daemon installer for ApacheDS, so that the main
> server
> >> RPM installer containing all the package
> dependencies
> >> and the Daemon running code can be generated.
> [SNIP]
> > Unfortunately (imho ;-) ) James still uses ant for
> its main goals. We 
> > have a working pom.xml but we are only using
> maven2 for site generation 
> > purpose (e.g: the pom does not use our real
> dependencies, but tests 
> > passes). We are just moving to modularised build
> and splitting our 
> > repository/sources into modules but we are
> sticking to ant-1.7 (even if 
> > I will probably keep the poms updated for this).
> We don't have james 
> > artifacts under any maven repository.
> That's fine we can use a combination of approaches
> to make the Maven 
> daemon installer generator plugin work for ANT.  We
> could easily wrap it 
> or use the ANT Maven plugin (that's an ant task for
> running maven).
> > I just looked at a local source snapshot from some
> months ago and I see 
> > you have a bootstrappers and a plugin sub-modules.
> The plugin module 
> > seems mostly Directory agnostic I guess most of
> that resources could be 
> > directly used in James too.
> Yes the plugin and the bootstrappers are totally
> Directory agnostic. 
> Let me explain these in some detail:
> General Summary
> ===============
> This is a (mini) framework for automatically
> generating installers for 
> servers to target any platform supporting
> potentially many kinds of 
> daemon/service launcher.  Right now there is only
> support for Jsvc and 
> Procrun from commons-daemon.  We could easily add
> the Tanuki wrapper as 
> well but Procrun has worked really well so there was
> no need.
> Bootstrappers
> =============
> The bootstrapper jar contains a simple interface for
> daemon services 
> along with an InstallationLayout class.  A number of
> bootstrapper 
> implementations exist:
>   o A simple one for a main() based Java application
>   o One for Procrun for a service based on windows
>   o One for Jsvc for a daemon based on *NIX and
> MacOSX
> These Bootstrappers utilize a basic footprint common
> to many 
> applications to initialize a ClassLoader by locating
> all the needed jars 
> and making them available to the Daemon application.
>  Each 
> implementation knows how to handle the semantics of
> the daemon/service 
> launcher is uses.  For example to integrate the
> Tanuki Wrapper you'd 
> implement a TanukiBootstrapper for it.
> The InstallationLayout class is used by the
> bootstrapper to locate 
> various libraries to include in the classpath and to
> locate for example 
> the var directory and directories for logging etc. 
> There might need to 
> be some tweaking needed here to extend this class
> for specific servers 
> but generally with a conf, var, logs, lib, and bin
> directory pointers in 
> the InstallationLayout you cannot go too far off.
> Installer Plugin
> ================
> The installer plugin does the work of assembling all
> the required 
> artifacts and other files for the installation
> footprint.  Within it's 
> configuration you tell it to produce different kinds
> of installers for 
> different target platforms.  You can also give it
> custom directives to 
> gather other miscellaneous files like for example
> the LICENSE.txt and 
> the NOTICE.txt file: anything really.
> The plugin knows how to generate installers using
> this configuration and 
> information about which launcher to use for a target
> platform.  It 
> currently can generate:
>    o an RPM for various Linux platforms (ppc &
> intel)
>    o IzPack java installers for *NIX and MacOSX on
> sparc, intel and ppc
>    o Inno native (.exe) installer for Windows
> Platforms on intel
> So it's very easy to produce a quick product with
> installers for a 
> server application that has nice OS integration as a
> daemon or a service 
> with a professional look and feel.
> Short Comings
> =============
> There are several short comings:
>    o No Bootstrapper for Tanuki or JavaService (from
> ObjectWeb)
>    o How do we make it work like or in conjunction
> with JPackage?
>    o Better InstallationLayout to comply with proper
> file system layouts
>    o Need installers for
> 	- solaris pkgs
> 	- debian
>    	- simple zip and tarballs
> > In current trunk we added support for jscv to be
> able to use 
> > commons-daemon to run James as unpriviledged user.
> From Directory's 
> > sources I guess you use jscv too, right?
> Exactly.  The only difference with what we have is
> we generate 
> installers for this same configuration.  The
> installation and 
> daemon/service wrapper go hand in hand.
> > We also use "Tanuki Software" Wrapper to run as a
> service under windows. 
> > I guess we could probably rely on jscv_win and
> installer tools (from 
> > plugin folder) to do the same, right?
> I suspect you're referring to procrun.  But yes we
> use that and can 
> write a Bootstrapper easilly for the Tanuki wrapper.
>  However Procrun 
> does a really good job IMO.
> > I don't know if I can help in any way, but I'm
> interested in following 
> > your action and eventually work on the needed
> steps to create a proposal 
> > to have james to use the same installer/daemon
> code. Can you point to 
> > the repository where I can look at what you are
> doing?
> I have no clue what Ole is up to but it seems to
> involve merging some 
> things in JPackage with what we have.
> Ole perhaps you can take a deeper look at what this
> does.  Or at least 
> give it a try to make installers for some dummy
> server application.  At 
> some point you have to dive into the code.  JPackage
> I don't think will 
> be the solution; rather I think y0u have to see how
> to generalize this 
> installation layout to support the layout formats
> for various *NIX 
> distributions.
> Alex
=== message truncated ===> begin:vcard
> fn:Alex Karasulu
> n:Karasulu;Alex
> org:Apache Software Foundation;Apache Directory
> adr:;;1005 N. Marsh Wind Way;Ponte Vedra
> ;FL;32082;USA
> email;
> title:Member, V.P.
> tel;work:(904) 791-2766
> tel;fax:(904) 808-4789
> tel;home:(904) 808-4789
> tel;cell:(904) 315-4901
> note;quoted-printable:AIM: alexokarasulu=0D=0A=
> 	MSN:
> 	Yahoo!: alexkarasulu=0D=0A=
> 	IRC: aok=0D=0A=
> 	PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4
> 014A 3662 F96F 4E13 70F8=0D=0A=
> x-mozilla-html:FALSE
> url:
> version:2.1
> end:vcard

Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.

View raw message