[Classpathx-javamail] Re: [Fwd: Re: [JPackage-discuss] Re: Status of classpathx-mail, classpath-inetlib, gnu-crypto]

[Chris Burdess]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Fitzsimmons wrote:
> > When you say a "self-contained" javamail, you mean packaging all the
> > classes needed at runtime into one JAR file? This would include a JSSE
> > implementation, etc, as specified in the inetlib INSTALL file. It 
> > would
> > get messy, especially when people wanted to mix and match with
> > different VMs, library versions, etc.
>
> I think Fernando was suggesting that you could do this: import the
> inetlib source tree directly into the javamail repository and replace
> all references to gnu.inet with e.g. gnu.classpathx.mail.inet.

Well, there's no need to change the package names, these can remain the 
same: there aren't any conflicts, and that would just add confusion.

> It's
> ugly but from what Fernando tells me I think it's necessary that
> classpathx-mail be self-contained if it's going to be a drop-in
> replacement for javamail.

Note that Sun's JavaMail isn't self-contained in this way either as it 
depends on a separate JAF implementation plus a JSSE implementation if 
you use IMAP/SSL. This issue is going to resurface again and again with 
Java libraries and applications. However:

I have no problem with any distribution packaging the mail, activation, 
and inetlib modules and their dependencies as one package, as long as 
the chosen dependencies comply with the licence terms (i.e. you can't 
include Sun's JSSE implementation). I don't believe there's anything 
that prevents such repackaging, although obviously you have to provide 
documentation describing how to retrieve the source packages.

The simplest solution for the package manager would be to build each 
source package to a jar, then extract all the jars into one directory 
and create one jar from this directory. There's nothing specific yet in 
the manifest for mail, activation, or inetlib, so there should be no 
conflicts with e.g. gnu-crypto.

If you're asking me to merge the inetlib, JAF and JavaMail source 
packages, though, I'm afraid that isn't going to happen. inetlib is 
used independently of javamail (e.g. as URL stream handlers for 
classpath) and contains much functionality that is orthogonal to mail 
(http, ftp, etc), idem JAF.

> > A better solution would be to patch the manifest in the various jar
> > files (gnumail.jar, gnumail-providers.jar, activation.jar, 
> > inetlib.jar)
> > - - since the dependency jars have been installed to absolute 
> > locations
> > by the package manager, you can simply insert a Class-Path entry in 
> > the
> > manifest containing these absolute locations, and Java will locate the
> > dependencies without the user having to specify a classpath 
> > explicitly.
>
> Unfortunately, I don't think this will work for jpackage.  The jpackage
> policy document has this to say about classpath manifest entries:
>
> > Classpath references in MANIFEST files interfere with classpath, are
> > not configurable, and don't work in JDK 1.1.x. They must be removed.

That's a shame. They're not configurable, but in this particular 
situation (absolute pathnames dictated by the package manager) that 
doesn't matter. Also GNU JavaMail, inetlib, and JAF won't work with 
JDK1.1 anyway, they require Java 2.
- -- 
Chris Burdess
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBHG066dl1DEqHgrgRAtvJAJ41xj9nB8udFTzxQ5bUxySWxJtOyQCbBK6i
9NJ7CvoEZ7ARfquVSpd+L14=
=G4Kj
-----END PGP SIGNATURE-----