| class not found by the run-time workbench [message #129571] |
Mon, 15 September 2003 14:59  |
Eclipse User |
|
|
|
Hi,
I create a minimal plugin and this plugin refer to classes in other Java
project.
I setup the project properties so that they compile correctly.
However, the run-time workbench can't locate the classes from other
project.
Is there a simple way to make it work insteadof import these classes into
the plugin project?
Thanks
|
|
|
|
|
|
|
|
|
|
| Re: class not found by the run-time workbench [message #131121 is a reply to message #129775] |
Wed, 17 September 2003 13:25  |
| Eclipse User |
|
|
|
Originally posted by: ThisisFake.Fakeness.xyz
On Mon, 15 Sep 2003 20:35:10 +0000, Jack Chi wrote:
> Richard L. Kulp wrote:
>
>> It is the whole concept of plugin development using the PDE that needs
>> to be reviewed. You are specifically missing the concept of required
>> plugins. To change the classpath of a plugin, you mustn't use the Java
>> Build Path, you need to use the plugin.xml and the build.properties.
>
> So the runtim-workbench will never find the classes located in other
> non-plugin Java project in the workspace unless these classes are stored
> in a plugin project or in a jar file that has been specified in the
> plugin run-time library path.
>
> To solve it, I need to convert this non plugin project to a plugin project
> or make a jar file so that the plugin can find it.
>
> Is it correct?
I just checked and it seems like you are correct. It makes sense. You
can add those classes to your 'build path' quite easily. And compile with
no problem. But when you deploy, those classes are not deployed with your
project.
I think you can make a new JRE entry, and put your classpath into that
entry. Then choose that JRE for your project. That should make the
runtime workbench use that JRE and it will then contain the classes you
want. If JRE selection is stored per-project, that will be even better as
it wont affect any of your other projects.
I think thats the best way without jarring.
I wonder why non-plugin projects don't have their class path's added to
the runtime classpath when they are used as reference. I can't see any
reason why not!? If its referenced, obviously its going to be needed.
Wonder if the PDE reference model needs to be updated. I havent tested
this myself.
CL
|
|
|
|
|
| Re: class not found by the run-time workbench [message #132018 is a reply to message #131071] |
Thu, 18 September 2003 10:13 |
| Eclipse User |
|
|
|
Mmm. My current eclipse with some extra plugins needs 29MB for
all jars together. Enter the out-of-the-box experiment.....
I extracted all of Eclipse's jars into one super-duper mega-jar (27MB)
and rewrote org.eclipse.core. I am able to run everything with one
single classloader just fine. There are no collisions, because everyone
uses package prefixes as they should.
If I remove useless symbolic debugging info, I can make the jar 22MB.
This is by no means the end. If I can track down all uses of reflection,
I can make the platform even smaller (think Rich Client Platform...).
Normal platform load time = 8 seconds. With single jar, one single
classloader and new core implementation = 6 seconds. Put the jar
on the bootclasspath = 4 seconds.
Of the 4 seconds, 2 seconds are spent in parsing the registry xml files.
So, I am currently removing the registry code and auto-generate a
registry compiled into bytecodes. I also need bytecode instrumentation
on the plugin class files to perform the nasty plugin startup magic.
Memory consumption (process/VM + heap) is also down by 10%.
My end target is 4x load time and 50% jar size.
Chris
"Richard L. Kulp" <richkulp@NO--SPAM.us.ibm.com> wrote in message
news:bka170$c08$1@eclipse.org...
> It allows for isolation of the plugins. Since Eclipse is a dynamic
> environment with all sorts of unrelated code being plugged into it, if
> they all used one classloader there would be conflicts galore. By each
> using a separate classloader, the plugin only sees classes from its
> plugin and from the plugins it depends upon. Other plugins that it
> doesn't know about won't be interfering with it.
>
> It also allows a plugin control of what is seen by a dependent plugin.
> If a plugin doesn't export something in the plugin.xml, the dependent
> plugin won't see it.
>
> Rich
>
|
|
|
|
| Re: class not found by the run-time workbench [message #132691 is a reply to message #132018] |
Thu, 18 September 2003 22:14 |
| Eclipse User |
|
|
|
Originally posted by: ThisisFake.Fakeness.xyz
On Thu, 18 Sep 2003 10:13:22 -0400, Chris Laffra wrote:
> Mmm. My current eclipse with some extra plugins needs 29MB for
> all jars together. Enter the out-of-the-box experiment.....
>
> I extracted all of Eclipse's jars into one super-duper mega-jar (27MB)
> and rewrote org.eclipse.core. I am able to run everything with one
> single classloader just fine. There are no collisions, because everyone
> uses package prefixes as they should.
> If I remove useless symbolic debugging info, I can make the jar 22MB.
> This is by no means the end. If I can track down all uses of reflection,
> I can make the platform even smaller (think Rich Client Platform...).
>
> Normal platform load time = 8 seconds. With single jar, one single
> classloader and new core implementation = 6 seconds. Put the jar
> on the bootclasspath = 4 seconds.
> Of the 4 seconds, 2 seconds are spent in parsing the registry xml files.
> So, I am currently removing the registry code and auto-generate a
> registry compiled into bytecodes. I also need bytecode instrumentation
> on the plugin class files to perform the nasty plugin startup magic.
>
> Memory consumption (process/VM + heap) is also down by 10%.
>
> My end target is 4x load time and 50% jar size.
>
> Chris
>
Yes, but then one poorly written plugin can hose another, and the end user
would not necessarily be aware of which plugin was behaving poorly.
Also, what does that do to security managers? now their would be just one
class loader?
CL
|
|
|
| Re: class not found by the run-time workbench [message #132729 is a reply to message #132691] |
Thu, 18 September 2003 23:54 |
| Eclipse User |
|
|
|
"CL [dnoyeB] Gilbert" <ThisisFake@Fakeness.xyz> wrote in message
news:pan.2003.09.19.02.14.35.920647@Fakeness.xyz...
> Yes, but then one poorly written plugin can hose another,
What "hosing" scenarios did you have in mind?
> and the end user
> would not necessarily be aware of which plugin was behaving poorly.
NOTHING CHANGES!!!!! Log file still works, registry is still there,
the actual location where the class files come from differs, that's all.
If you develop with a normal runtime workbench, and once in while
generate the mega-jar and test it, I don't see much going wrong here.
> Also, what does that do to security managers? now their would be just one
> class loader?
Security? What kind of security? It is just one big Java program, is it not?
I am thinking about a seriously well-controlled effort to package up
eclipse (and perhaps a few selected 'application' plugins) into a
package that works just as well as the old one, but takes less
memory and CPU to deploy. Someone who is willing to ship
their application in this manner of course will do testing on the
result.
The real problems are in the case of multiple versions of the same
plugin installed. Then you really need multiple classloaders.
Also, if people don't use package names for name spaces,
collisions will occur.
Again, think Rich Client Platform, shipping a closed-off Human
Resource application, for instance.
Chris
|
|
|
Powered by
FUDForum. Page generated in 0.25292 seconds
Home