Java Mail extension api
Created attachment 3289 [details]
javamail-1.3, installs demos by default with lots of doins lines. Is there a
better way to do this?
Created attachment 3290 [details]
ChangeLog for 1.3
Created attachment 3291 [details]
classpath file for javamail
Created attachment 3306 [details]
Changed so install env in /usr/share/javamail/package.env
Created attachment 3307 [details]
env file to be installed in /usr/share/javamail, this way user can choose
classpath with java-config
Created attachment 3310 [details]
updated for depend on jaf
Created attachment 3311 [details]
renamed env file
Depends on jaf in order to work
I only have bad experience with packaging stuff right off of Sun's web site.
They update their upstream packages without prior notice, rename stuff at whim,
relicense stuff under more restrictive licenses (ie, jaxp), and are generally
not nice to deal with.
Are there alternative implementations of this, or is it included in any of the
1.4 (ME, SE, EE) editions of Java ? If so, I'd rather we use that.
I'm slowly working on phasing out all stuff provided through Sun's web site,
finding workably alternatives instead. When we start marking packages as
"stable", none of the packages which download stuff from Sun will ever be marked
"stable", as we are not allowed to mirror the tarballs, and thus cannot ensure
that it will work for all our users 100% of the time.
I don't believe this or jaf is included in a 1.4 version of java, since they are
both optional extensions. I do agree that finding an alternate version of this
would be better, so if I do, I'll let you know. This is just what I found since
I need it for a project and figured I might as well make an ebuild for it. If
you'd rather not add it to portage, that's fine, and I'll see if I can find
alternates for both this and jaf.
While we of course appreciate your effort on this, I've had nothing but bad
experience with packaging Sun-provided stuff. We're gonna keep the sun-jdk (of
course), but I don't want to cram in more Sun-stuff than necessary.
As you're the only one who's requested (and even provided a solution to!) this,
I don't think it's necessary for our 1.4 release at least, so I'll leave you to
Please reopen the bug when (if?) you figure out some more.