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 2007/02/10 20:07:32 UTC
[COLLABORATION] James
Hi (Again) Stefano,
I'm almost done with this Maven RPM Factory thing.
It's going to produce RPMs of all the libraries in the
entire Maven Ibiblio Repository, so that both
ApacheDS and James can be installed with with Yum.
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.
I noticed that you were interested in having
installers generation capabilities for James similar
to those of ApacheDS, so please let me know if you
would like me to have a look at the James Daemon
process as well. I'm hoping there is a way to combine
the process for both ApacheDS and James.
Cheers,
- Ole
____________________________________________________________________________________
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html
Re: [COLLABORATION] James
Posted by Ole Ersoy <ol...@yahoo.com>.
Hey Guys,
Alex - Thanks for the terrific elaboration on the
goods.
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
Repository
B) Create a Server Installer RPM
C) Yum will automatically pull the Server Installer
RPM's dependencies and place them in
/usr/share/java/
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 :-)
Cheers,
- Ole
--- Alex Karasulu <ak...@apache.org> 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;internet:akarasulu@apache.org
> 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: aok123@bellsouth.net=0D=0A=
> 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:http://people.apache.org/~akarasulu
> version:2.1
> end:vcard
>
>
____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/
Re: [COLLABORATION] James
Posted by Alex Karasulu <ak...@apache.org>.
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
Re: [COLLABORATION] James
Posted by Ole Ersoy <ol...@yahoo.com>.
Hey Stefano,
I still need to check in the RPM Factory stuff :-)
but will point you too it as soon as I do.
I'm writing a ApacheDS Contributor Guide first. Then
I'm going to use the checklists in there to make sure
I dotted all the T's.
It's an eclipse documentation plugin, so should be
easy to use for James as well in case you are
interested.
So once that's done I'll double check the RPM factory
stuff, and check it in. I'll let you know as soon as
I do.
I'm also planning to write a similar guide around the
Bootstrappers/Daemon, so that there is a design
document that all of apache can refer to, in case
other projects like Tomcat, etc. might be interested
as well. Ideally there would be one project to
improve on that's common to all the servers,
regardless of container, etc.
> From Directory's
> sources I guess you use jscv too, right?
Let me get back to you on that one, once the initial
draft of the design document is finished. I like
having that as a context for everything, so that there
is something upfront to add to :-)
Ideally the RPM factory will grow into a "Apache
Server Installer Factory" and will be capable of
generating installers for all Apache Servers using a
general framework across RPMs, MS$, Debian, Solaris,
etc.
OK - back to the installer guide. I'll copy you when
I subversion it, sometime later today hopefully :-)
Cheers,
- Ole
--- Stefano Bagnara <ap...@bago.org> wrote:
> Ole Ersoy ha scritto:
> > Hi (Again) Stefano,
> >
> > I'm almost done with this Maven RPM Factory thing.
>
> > It's going to produce RPMs of all the libraries in
> the
> > entire Maven Ibiblio Repository, so that both
> > ApacheDS and James can be installed with with Yum.
>
> > 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.
>
> Hi Ole,
>
> I don't have any knowledge of the current Directory
> installer/daemon module.
>
> 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.
>
> 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.
>
> 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?
>
> 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 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?
>
> Thank you for the synergy :-)
> Stefano
>
> > I noticed that you were interested in having
> > installers generation capabilities for James
> similar
> > to those of ApacheDS, so please let me know if you
> > would like me to have a look at the James Daemon
> > process as well. I'm hoping there is a way to
> combine
> > the process for both ApacheDS and James.
> >
> > Cheers,
> > - Ole
>
>
>
____________________________________________________________________________________
The fish are biting.
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
Re: [COLLABORATION] James
Posted by Stefano Bagnara <ap...@bago.org>.
Ole Ersoy ha scritto:
> Hi (Again) Stefano,
>
> I'm almost done with this Maven RPM Factory thing.
> It's going to produce RPMs of all the libraries in the
> entire Maven Ibiblio Repository, so that both
> ApacheDS and James can be installed with with Yum.
> 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.
Hi Ole,
I don't have any knowledge of the current Directory installer/daemon module.
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.
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.
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?
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 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?
Thank you for the synergy :-)
Stefano
> I noticed that you were interested in having
> installers generation capabilities for James similar
> to those of ApacheDS, so please let me know if you
> would like me to have a look at the James Daemon
> process as well. I'm hoping there is a way to combine
> the process for both ApacheDS and James.
>
> Cheers,
> - Ole