Open Xchange for FC5 with GCJ 4.1

[Erwin Rol]

Hey David,

Please keep in mind the first priority is to figure out how it can be
compiled, after that it can be cleaned up.

On Wed, 2006-02-22 at 11:42 -0500, David Hollis wrote:
> On Mon, 2006-02-20 at 00:33 +0100, Erwin Rol wrote:

> It would be nice to be able to keep the html docs out of /var/www/html.
> It may be a bit debatable as to where the best location would be,
> possibly /var/www/open-xchange, /usr/share/open-xchange/.... or
> something.  Then just add a open-xchange.conf to /etc/httpd/conf.d/ that
> aliases the directory appropriately.  Knowing how OX is, that may not be
> possible without totally dorking stuff up.

Hmmm maybe the files in /usr/share/open-xchange/bla and a symlink
from /var/www/html/ to that dir?

> I really don't like having to have database names, passwords, LDAP dns
> and such specified at build time, but I don't think OX gives any
> alternatives.... sigh....

Yes that is a pain, and i plan to fix it. The database and LDAP-DN names
are needed now because Open Xchange uses autoconf to generate scripts
with the names in them, and thats just a bit stupid i think. For the
passwords i guess there is not much choice but to leave them, problably
as a easy grep-able something like CHANGEME. The install docu should
take care of the rest.

> Javamail - couldn't you have the OX spec depend on javamail >= 1.3.0 and
> have the ox_javamail.spec have a "Provides: javamail 1.3.0" or whatnot?
> That would allow newer javamail rpms to replace the ox_javamail when the
> time comes and everything can continue playing nice.

This was just one big hack, to not destroy a working javamail install.
It falls under the "it was quick and worked for me" :-) The reall fix is
ofcourse to provide patches to the javamail ppl and to wait for the next
release of javamail (which will probably sooner than a real stable
OX :-)

> You really don't have to extract the WAR files during RPM build do you?
> Can't you just plop the .war in the /var/lib/tomcat5/webapps dir and it
> will take care of everything?  Though I suppose you lose the RPM owning
> those files... hmm, I don't know enough about tomcat app deployment to
> know which way is best.

Yeah the reason was that i wanted to have the RPM own those files, maybe
some tomcat/rpm guru knows the correct way to do this.


> The gcj.patch file seems to hard code some .jars that can be specfied
> with configure.  This could bite you later.  It looks like that patch
> tackles a bunch of different issues, so it would be best to split it
> out.  

The gcj.patch is currently nothing more than a diff between a original
and hacked tree. It has a lot of whitespace changes too that are not
really needed but sneaked in. 

> A lot of things might be useful to send upstream, some may be
> specific to getting the package to build with Fedora, etc.  Check out
> the kernel RPMS for examples of breaking out patches.  As things get
> merged upstream, become outdated, etc, it's very easy to remove them
> from the spec.  You probably don't want to have to maintain a parallel
> source tree to generate patches.

Yep that was the plan, but since this is a serious trail and error
debugging the two tree thing was faster for now. And since OX is in RC
stage no patches will be accepted anyway at the moment.

Thank you for your reply, ideas and hints, which are certainly useful.

- Erwin