directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [COLLABORATION] James
Date Tue, 13 Feb 2007 01:31:54 GMT
Stefano Bagnara wrote:
> Ole Ersoy ha scritto:


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.


> 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.


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 


View raw message