Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #25886 > unrolled thread

Re: Eclipse vs plugin.jar

Started byDaniele Futtorovic <da.futt.news@laposte.net.invalid>
First post2011-01-28 18:41 +0100
Last post2011-01-28 18:10 +0000
Articles 2 — 2 participants

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Eclipse vs plugin.jar Daniele Futtorovic <da.futt.news@laposte.net.invalid> - 2011-01-28 18:41 +0100
    Re: Eclipse vs plugin.jar Tom Anderson <twic@urchin.earth.li> - 2011-01-28 18:10 +0000

#25886 — Re: Eclipse vs plugin.jar

FromDaniele Futtorovic <da.futt.news@laposte.net.invalid>
Date2011-01-28 18:41 +0100
SubjectRe: Eclipse vs plugin.jar
Message-ID<ihuv37$3r7$1@news.eternal-september.org>
On 28/01/2011 17:23, Tom Anderson allegedly wrote:
> Good day!
>
> We're writing an applet. It does uses LiveConnect to talk to JavaScript
> on the page. The classes for that - JSObject and friends - are in
> plugin.jar, which can be found in the JRE lib directory.
>
> We're developing using Eclipse. Eclipse has no idea about plugin.jar.
>
> What's the right way to teach it?
>
> We could put a copy of plugin.jar in our project. That's easy, but means
> we're not using the installed version, which leaves us vulnerable to
> version mismatch if Sun decides to make changes to this decade-old piece
> of code.
>
> We could add an external jar reference. That's also easy, and uses the
> installed jar, but involves hardcoding the path to the JRE in the metadata.
>
> We could use a classpath variable for the JRE's location, and add an
> external JAR reference relative to that, which uses the installed jar
> and doesn't hardcode the location, but it means everyone has to add a
> new variable to their workspace (there isn't a predefined one for
> JAVA_HOME or JRE_HOME, annoyingly).
>
> We could define a 'library', which is some sort of bundle of jars, which
> has the disadvantages of all the above approaches, and none of the
> advantages.
>
> Any thoughts?
>
> tom

Firstly, I assume the problem is it doesn't compile, isn't it? Because
it should run fine.

I'm not using Eclipse anymore these days, so I don't know exactly, but
isn't there some point where you define your "platform", viz. the JDK
you're using? Wouldn't including the lib in question belong in that step?

df.

[toc] | [next] | [standalone]


#25999

FromTom Anderson <twic@urchin.earth.li>
Date2011-01-28 18:10 +0000
Message-ID<alpine.DEB.1.10.1101281804530.24197@urchin.earth.li>
In reply to#25886
On Fri, 28 Jan 2011, Daniele Futtorovic wrote:

> On 28/01/2011 17:23, Tom Anderson allegedly wrote:
>
>> We're developing using Eclipse. Eclipse has no idea about plugin.jar.
>> 
>> What's the right way to teach it?
>
> Firstly, I assume the problem is it doesn't compile, isn't it?

Yes, absolutely.

> Because it should run fine.

I would hope so.

> I'm not using Eclipse anymore these days, so I don't know exactly, but 
> isn't there some point where you define your "platform", viz. the JDK 
> you're using?

They come pre-packaged (you tell Eclipse where the JDK home directory is, 
and it searches out jars in it). It pulls jars from the JDK but not the 
JRE, so it doesn't include plugin.jar by default.

> Wouldn't including the lib in question belong in that step?

It is possible to edit the list, so yes, we could add plugin.jar there. 
That has roughly the same disadvantages as adding a new 'library', in that 
it has to be done individually on each machine, but it is rather neater. 
Definitely an option to consider.

tom

-- 
If god did exist, we would have to abolish him. -- Mikhail Bakunin

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.java.programmer


csiph-web