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

On Thu, 2004-08-12 at 17:31, Chris Burdess wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Fernando Nasser wrote:
> >>> > One new detail: classpathx-mail cannot be used as a drop-in 
> >>> replacement
> >>> > for javamail due to its dependency on inetlib. Sorry Ville, I am 
> >>> not sure I understood.  Wouldn't it be that as long as someone has 
> >>> the inetlib package then they could install classpathx-mail as a 
> >>> replacement for javamail?
> >>
> >> No, merely installing inetlib is not enough (and it's already taken 
> >> care
> >> of with the rpm dependency).  It needs to be included in CLASSPATH one
> >> way or another too when using classpathx-mail.
> >
> > We need to get this solved so we can get javamail  (and jaf) on Fedora 
> > as
> > replacements for the non-open source ones.
> >
> > Would it be possible to have a procedure of regularly importing 
> > inetlib sources and changing the packages with a script so we have a 
> > self contained javamail?
> >
> > It would still be using inetlib, so not duplicating development.  It 
> > would only give us a little bit of work here and there.  I believe 
> > that with CVS and vendor branch imports we can actually do this 
> > conversion only once (except for new files).
> 
> 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.
> 

Hi Chris,

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.  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.

> 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.

Tom