JEP 0.8.3 seems to work fine with Java 1.4.2
Update 2, except for one (relatively minor)
problem -- a botched version check in JEP 0.8.3
disables the Java Control Panel's "runtime
parameters".
My current version of the Java Embedding Plugin
fixes this problem. I should be able to release
it as version 0.8.4 in the next few days.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-09-26
Hi,
I look forward to the release of JEP 0.8.4 for Java 1.4.2 Update 2!
BTW, are you considering to integrate JEP into the official Mozilla release?
I think a lot of Mac OS X users will benefit from that, since it is not very easy to find JEP and not technical users may have difficulties to install it.
Keep up the great work!
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I look forward to the release of JEP 0.8.4 for Java
> 1.4.2 Update 2!
It just came out today.
> BTW, are you considering to integrate JEP into the
> official Mozilla release?
>
> I think a lot of Mac OS X users will benefit from
> that, since it is not very easy to find JEP and not
> technical users may have difficulties to install it.
The JEP isn't yet ready for non-technical users :-)
I don't plan for it to become part of the Mozilla tree.
Once the JEP is out of beta, I'd like to see a snapshot
included in the Mozilla, Firefox and Camino distros
(like what Mozilla does with libjpeg) ... but the exact
terms will need to be negotiated with Mozilla.org.
> Keep up the great work!
>
> Thanks.
You're most welcome!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like at least for the updated version of the MRJ plug-in to become a standard component of Mozilla and to be included in the standard release.
Do you see any reason for there be a problem with that ? I think your updates to MRJ are just modification of the original files, so are under the MPL ? I didn't seem to see the source in the sourceforge cvs.
I have apparently found that I needed to remove the apple plug-in to be able to use the updated MRJ.
Do you know if it can be corrected ? (there is an old bugzilla entry about how they made sure the old version of the MRJ would be used as the Java plug-in so I think the same applies)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I would like at least for the updated version of
> the MRJ plug-in to become a standard component
> of Mozilla and to be included in the standard
> release.
I was talking about the Java Embedding Plugin as a
whole.
What I call the "MRJ Plugin JEP" does include lots
of bug fixes (particularly LiveConnect fixes) that
aren't specific to the Java Embedding Plugin, and
can stand on their own. (Though if you use the
"MRJ Plugin JEP" by itself, without
JavaEmbeddingPlugin.bundle, you'll only have
access to Java 1.3.1.) I'd be happy to see these
bug fixes included in the Mozilla tree.
I want the Java Embedding Plugin project to keep
its separate identity, and for the
JavaEmbeddingPlugin.bundle code to keep its
MIT-style license -- not least because it might
get used by other, non-Mozilla-family browsers.
Though once again I'd be happy for Mozilla distros
to include a snapshot, as they do with libjpeg.
The JEP-specific code in the "MRJ Plugin JEP"
falls into a grey area -- I've stuck an MIT-style
license on files that contain only JEP-specific
code, but I put plenty of other JEP-specific code
in files that have Mozilla.org's latest MPL
license. The lawyers can decide the ultimate
status of this code. And I really don't care all
that much. But I'd prefer that the MRJ Plugin in
the Mozilla tree not contain any JEP-specific code
until the JEP is out of beta -- and ready for tens
of thousands of naive users :-)
> I have apparently found that I needed to remove
> the apple plug-in to be able to use the updated
> MRJ. Do you know if it can be corrected ?
> (there is an old bugzilla entry about how they
> made sure the old version of the MRJ would be used
> as the Java plug-in so I think the same applies)
I don't understand what you're saying here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I've stuck an MIT-style
> license on files that contain only JEP-specific
> code, but I put plenty of other JEP-specific code
> in files that have Mozilla.org's latest MPL
> license. The lawyers can decide the ultimate
> status of this code. And I really don't care all
> that much.
Changes to the file that have Mozilla MPL licence fall under the MPL.
The files you added are under the MIT licence, you use the exact text of the licence approved by OSI, so it's compatible with the GPL/LGPL/MPL the other file are under.
Even if my personnal feeling is that it would be cleaner to use only one licence scheme for all the source file of one executable/dnamic library.
> But I'd prefer that the MRJ Plugin in
> the Mozilla tree not contain any JEP-specific code
> until the JEP is out of beta
Is this really important to you ?
The most interesting part of updating the MRJ Plugin code in the tree with your change would be to compile the plugin by default again, and have it override Apple's plugin when running, so that users use that version without having to change anything in their system configuration.
But then, if they need a different version of the MRJ Plugin to use the JEP, it would be confusing, and the installation might be made more difficult.
As I see it, the JEP specific code would not change anything for them as long as the JEP is not really installed, so it's not really a problem to have it even if JEP is beta.
Maybe, the problem is that this would force you to freeze the "JEP <-> MRJ Plugin JEP" interface.
Could you find a find a way to put as much of the JEP specific code as possible inside the JEP ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Maybe, the problem is that this would force you
> to freeze the "JEP <-> MRJ Plugin JEP"
> interface.
Exactly :-) I don't want to freeze this interface
until I release version 1.0. I doubt that I'll
actually change it much from now to then ... but I
think it's better to be safe than sorry.
> Could you find a find a way to put as much of
> the JEP specific code as possible inside the
> JEP?
I already have.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anyone tried this is JEP 0.8.3?
I have :-)
JEP 0.8.3 seems to work fine with Java 1.4.2
Update 2, except for one (relatively minor)
problem -- a botched version check in JEP 0.8.3
disables the Java Control Panel's "runtime
parameters".
My current version of the Java Embedding Plugin
fixes this problem. I should be able to release
it as version 0.8.4 in the next few days.
Hi,
I look forward to the release of JEP 0.8.4 for Java 1.4.2 Update 2!
BTW, are you considering to integrate JEP into the official Mozilla release?
I think a lot of Mac OS X users will benefit from that, since it is not very easy to find JEP and not technical users may have difficulties to install it.
Keep up the great work!
Thanks.
> I look forward to the release of JEP 0.8.4 for Java
> 1.4.2 Update 2!
It just came out today.
> BTW, are you considering to integrate JEP into the
> official Mozilla release?
>
> I think a lot of Mac OS X users will benefit from
> that, since it is not very easy to find JEP and not
> technical users may have difficulties to install it.
The JEP isn't yet ready for non-technical users :-)
I don't plan for it to become part of the Mozilla tree.
Once the JEP is out of beta, I'd like to see a snapshot
included in the Mozilla, Firefox and Camino distros
(like what Mozilla does with libjpeg) ... but the exact
terms will need to be negotiated with Mozilla.org.
> Keep up the great work!
>
> Thanks.
You're most welcome!
I would like at least for the updated version of the MRJ plug-in to become a standard component of Mozilla and to be included in the standard release.
Do you see any reason for there be a problem with that ? I think your updates to MRJ are just modification of the original files, so are under the MPL ? I didn't seem to see the source in the sourceforge cvs.
I have apparently found that I needed to remove the apple plug-in to be able to use the updated MRJ.
Do you know if it can be corrected ? (there is an old bugzilla entry about how they made sure the old version of the MRJ would be used as the Java plug-in so I think the same applies)
> I would like at least for the updated version of
> the MRJ plug-in to become a standard component
> of Mozilla and to be included in the standard
> release.
I was talking about the Java Embedding Plugin as a
whole.
What I call the "MRJ Plugin JEP" does include lots
of bug fixes (particularly LiveConnect fixes) that
aren't specific to the Java Embedding Plugin, and
can stand on their own. (Though if you use the
"MRJ Plugin JEP" by itself, without
JavaEmbeddingPlugin.bundle, you'll only have
access to Java 1.3.1.) I'd be happy to see these
bug fixes included in the Mozilla tree.
I want the Java Embedding Plugin project to keep
its separate identity, and for the
JavaEmbeddingPlugin.bundle code to keep its
MIT-style license -- not least because it might
get used by other, non-Mozilla-family browsers.
Though once again I'd be happy for Mozilla distros
to include a snapshot, as they do with libjpeg.
The JEP-specific code in the "MRJ Plugin JEP"
falls into a grey area -- I've stuck an MIT-style
license on files that contain only JEP-specific
code, but I put plenty of other JEP-specific code
in files that have Mozilla.org's latest MPL
license. The lawyers can decide the ultimate
status of this code. And I really don't care all
that much. But I'd prefer that the MRJ Plugin in
the Mozilla tree not contain any JEP-specific code
until the JEP is out of beta -- and ready for tens
of thousands of naive users :-)
> I have apparently found that I needed to remove
> the apple plug-in to be able to use the updated
> MRJ. Do you know if it can be corrected ?
> (there is an old bugzilla entry about how they
> made sure the old version of the MRJ would be used
> as the Java plug-in so I think the same applies)
I don't understand what you're saying here.
> I've stuck an MIT-style
> license on files that contain only JEP-specific
> code, but I put plenty of other JEP-specific code
> in files that have Mozilla.org's latest MPL
> license. The lawyers can decide the ultimate
> status of this code. And I really don't care all
> that much.
Changes to the file that have Mozilla MPL licence fall under the MPL.
The files you added are under the MIT licence, you use the exact text of the licence approved by OSI, so it's compatible with the GPL/LGPL/MPL the other file are under.
Even if my personnal feeling is that it would be cleaner to use only one licence scheme for all the source file of one executable/dnamic library.
> But I'd prefer that the MRJ Plugin in
> the Mozilla tree not contain any JEP-specific code
> until the JEP is out of beta
Is this really important to you ?
The most interesting part of updating the MRJ Plugin code in the tree with your change would be to compile the plugin by default again, and have it override Apple's plugin when running, so that users use that version without having to change anything in their system configuration.
But then, if they need a different version of the MRJ Plugin to use the JEP, it would be confusing, and the installation might be made more difficult.
As I see it, the JEP specific code would not change anything for them as long as the JEP is not really installed, so it's not really a problem to have it even if JEP is beta.
Maybe, the problem is that this would force you to freeze the "JEP <-> MRJ Plugin JEP" interface.
Could you find a find a way to put as much of the JEP specific code as possible inside the JEP ?
> I didn't seem to see the source in the
> sourceforge cvs.
There's a single distro with both binaries and
source.
> Maybe, the problem is that this would force you
> to freeze the "JEP <-> MRJ Plugin JEP"
> interface.
Exactly :-) I don't want to freeze this interface
until I release version 1.0. I doubt that I'll
actually change it much from now to then ... but I
think it's better to be safe than sorry.
> Could you find a find a way to put as much of
> the JEP specific code as possible inside the
> JEP?
I already have.