On Fri, Mar 7, 2008 at 10:51 AM, Pierre-Arnaud Marcelot <pa@marcelot.net> wrote:
On Fri, Mar 7, 2008 at 6:25 PM, Alex Karasulu <akarasulu@apache.org> wrote:
I guess each instance can have it's own Windows service right?

I think so. Although, I'm not completely sure. Chris ?
Yes, the way it works in windows is that you create a new instance config file and run the apacheds (Tanuki wrapper native exe) with a special command line and it installs a service specifically for this instance.  We were going to create some little Windows native GUI for creating new instances from templates similar to the Cocoa config pane that Pierre-Arnaud is talking about.  This is fairly trivial to do, and it would be really awesome to do something as a lightweight Swing GUI or something that can be portable, but this will be a lot of work to account for platform differences in config stuff.  On another note, this is why I was looking at OpenInstaller, because you can create Java plugins for the installer that can run at install time (starting the server to pre-load data, etc.).

That's cool.  Also this might be totally off but is there any way we can have some kind of configuration thingy like the ones you see in the system configuration menus for ApacheDS or is that way hard to do?  Was wondering if we can control some things in ApacheDS through there.

Yeah I was thinking to do a little PreferencePane that could look like the MySQL prefpane -> http://people.apache.org/~pamarcelot/MySQL_PrefPane.png

In this prefpane you could see the status of the server (running or not), toggle between Start and Stop, and also choose to automatically launch the server when the machine boots.
I think we should have an init script for each instance.  Perhaps /etc/init.d/ads-${instanace-name} might be a good idea WDYT?
Yep, this is almost exactly what I was thinking.  The current method can't autostart on Linux because you have to name the instance as argument and that is a bad oversight on my part.  I was thinking that we can have a single script that gets symlinked for each instance ( apacheds_myinstance->/etc/init.d/apacheds) and the script can parse the symlink name and derive the instance name.  That way we can update the script on new releases without affecting the instances.  The config GUI or a script could be used to maintain these types of things.

Sounds like a good idea.

/etc/init.d/apacheds-${version}-${instance) or something to that effect.  WDYT?

Good idea. It's the cleanest solution I think.

Related to the above idea, I was wondering if it would be better to have the version tied to the target of the symlink... so that upgrading is just a matter of a new symlink to the script for the new apacheds version that was installed.  Another option is to make this part of the instance configuration (apacheds.conf for the instance could specify version=1.5.2 and we could use that in variable substitution within the scripts.  Just ideas here, I am sure there are other options.

Also I'd love to see a Solaris pkg so we can make some Apache folks who wanted to use ADS in zones here at the ASF happy.  That would be awesome but am just greatful to have what we have.

Thanks Pierre, this is so wonderful we finally have installers coming again and can do a real release.  We were stuck in the longest period ever without a release and for some reason with me it was due to knowing our installers were not up to par yet.  Thanks for picking this up. 

Well for now, I only added the Mac OS X installer and corrected a bug introduced in a refactoring which prevented the build of installers from working.
All the credits go to Chris who did an amazing job with the Windows installer and RPM package too.
I didn't touch them at all.

I think a good documentation on our installer is lacking. It was not easy at first to figure how they worked and how they were built.
I'm going to document them on the wiki so everyone interested can easily jump in and improve/fix the installers.

We can now be good with the 5 minute download install tests that are critical for how effective a project is considered.  This is a big exposure area.

Exactly, I think this is an important point and that's why I tend to prefer native installers instead of a unique multi-platform installer.
Users are really used to working with native installers. This is something they apprehend easily and they feel safe with it.
So I think that with a Windows installer, RPM package, DEB package, PKG package, Binary installer, Apache DS will really cover a large set of OSes and people.
As you say, maybe the remaining one could the Solaris one.