classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Compiling OpenExchange with gcj and classpath


From: Mark Wielaard
Subject: Re: Compiling OpenExchange with gcj and classpath
Date: Fri, 08 Jul 2005 15:03:45 +0200

Hi,

On Fri, 2005-07-08 at 17:58 +0530, Soumyadip Modak wrote:
> Recently I've been looking at OpenExchange on Fedora Core 4. I was 
> hoping to utilise FC4's extensive free Java tools to build OX. OX 
> configure script didn't thorw up any problems but make failed witha lot 
> of errors. Can anyone please guide me how to rectify these problems to 
> get a completely free groupware solution ?
> 
> Errors :

I had a quick look at the errors. Below is an quick analysis, but no
real solutions yet. Hopefully others can give more specific suggestions.

- the servlet related warnings should be easy to solve.
  I am actually a Debian user. But I believe Fedora has a package called
  tomcat5-servlet (which you can use depending on the license of
  OpenExchange, unfortunately it isn't GPL compatible. There is a LGPL
  servlet implementation distributed with gnu paperclipse, but I don't
  know if Fedora ships that.). Try using "yum search servlet".
- the sun.misc.BASE64 usage. That one is nasty since that isn't a
  publicly documented class. It shouldn't be hard to replace that code
  since base64 en/decoding isn't actually that difficult.
  (For an examples see gnu/java/net/BASE64.java or
   gnu/java/io/Base64InputStream.java in GNU Classpath)
- ParserDelegator.parse() is missing in gcj4, but we have it in GNU
  Classpath. This should be backported to libgcj.
  Same for javax.swing.text.html.HTMLEditorKit.
  (Although it is mainly stubs at the moment.)
- The usage of com.sun.mail ImapFolder and Rights is another
  non-documented, non-free issue. Hopefully that can be fixed by using
  an appropriate class from GNU mail or inetlib.

It looks like this program was developed against a proprietary non-free
java platform implementation and the use of non-standard, undocumented
classes is a bit of a problem. The biggest issue is the imap and html
usage for which it might be some work to create free replacements. But
work is already been done on this, so it might not be that hard in the
end.

Cheers,

Mark
-- 
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html

Join the community at http://planet.classpath.org/

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]