[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Classpathx-javamail] Re: [Fwd: Re: [JPackage-discuss] Re: Status of cla
From: |
Thomas Fitzsimmons |
Subject: |
[Classpathx-javamail] Re: [Fwd: Re: [JPackage-discuss] Re: Status of classpathx-mail, classpath-inetlib, gnu-crypto] |
Date: |
Thu, 12 Aug 2004 18:01:11 -0400 |
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
- [Classpathx-javamail] [Fwd: Re: [JPackage-discuss] Re: Status of classpathx-mail, classpath-inetlib, gnu-crypto], Fernando Nasser, 2004/08/12
- [Classpathx-javamail] Re: [Fwd: Re: [JPackage-discuss] Re: Status of classpathx-mail, classpath-inetlib, gnu-crypto], Chris Burdess, 2004/08/12
- [Classpathx-javamail] Re: [Fwd: Re: [JPackage-discuss] Re: Status of classpathx-mail, classpath-inetlib, gnu-crypto],
Thomas Fitzsimmons <=
- [Classpathx-javamail] Re: [Fwd: Re: [JPackage-discuss] Re: Status of classpathx-mail, classpath-inetlib, gnu-crypto], Ville Skyttä, 2004/08/12