| Re: [ve-dev] Border Layout implementation not working |
>I have added a class path container.
Remembering the above passage for class path from one of the previous
mails .I tried to add a proxy.jars. But I am not able to understanding
the phenomenon of proxy.jars. Can you please >explain the swt proxy.
jars? , So that I would be able to replicate the same for my project. I
have attached the proxy. jars document from the org.eclipse.ve.swt plug-in
.
The Visual Editor starts a JVM for each
editor part. This contains all of the runtime code required to be
able to host the JavaBeans, so it includes everything in the Java project's
Java build path, and it also contains any additional code that you might
want to put there. This can include helper classes to assist with
things like retrieving images. Usually for most JavaBeans providers
they wouldn't need to put anything in the target JVM.
If you do decide you want to put some
helper classes on the target VM this is going to be because you have a
custom BeanProxyAdapter (this runs inside the IDE and is responsible for
mediating between the IDE and your live JavaBean on the target) and you
decide perhaps that rather than making lots of API calls over to the target
VM you want to delegate this to a helper class that can run alongside your
JavaBean.
When the Visual Editor starts the target
VM it needs to know about your code you want to include in the target VM's
-classpath. At runtime this will be packaged by you as a .jar file.
There are two ways it can be specified so the .jar can be included
in the target VM. The first is to name a container and this is the
technique used in the plugin org.eclipse.ve.examples that you can check
out of CVS to see how it's done. For example, in this plugin, the
target VM supporting code is built into the file javaexamplebeans.jar.
The plugin.xml looks like
<extension
point="org.eclipse.ve.java.core.registrations">
<registration
container="org.eclipse.ve.examples.JavaExample"
description="%visualExamples">
<library
runtime="vm/javaexamplebeans.jar"
source="vm/javaexamplebeanssrc.zip">
</library>
</registration>
</extension>
The problem with this is that it assumes that you have the target VM code
packaged into a .jar file each time you do Run As>Eclipse Application.
During development this tends not to be the case, because you usually
work with the classes and iterate on them each time you test and then do
a final build and .jar creation when you're happy with them. To allow
for this you can tell the VE that if it can't find a particular .jar file
then it instead should substitute this -classpath entry with a folder.
The folder contains the .class binaries from the Eclipse project
where you're doing your work. In the org.eclipse.ve.examples project
this is the /bin folder of the project itself, so proxy.jars loooks like
this.
vm/javaexamplebeaninfo.jar=/org.eclipse.ve.examples/bin/
In summary, if a .jar file can't be
found when the target VM is launched that has been specified to be included
in the -classpath, the VE then looks for a proxy.jars file and if one is
found looks for a line that says what should be used instead of the .jar.
It allows .class files present in a /bin folder during development
to be used, and when you do a final build you just supply the .jar file
and this will get used instead.
Best regards,
Joe Winchester