Re: [ve-dev] Read/Write of complex LayoutManager values

[Rich Kulp <richkulp@xxxxxxxxxx>]

Hi,

Your's is not a usual situation. Typically
people are supplying both the runtime jar to compile against and use at
runtime, and separate editparts/VE code and beaninfo. 

First, your forms.jar internal one that
your plugin is supplying, does it have an actual FormsLayout class in it?
That could be a problem because the user would not be putting this jar
into their classpath in the project. They would be putting the external
forms.jar. So the FormsLayout from the external jar is the one that will
be compiled against and loaded in the remote vm, not your FormsLayout class.
Is that a problem?

Rich

Gerald Rosenberg <gerald@xxxxxxxxxx>
Sent by: ve-dev-bounces@xxxxxxxxxxx

06/12/2006 07:09 PM

Please respond to
Discussions people developing code for the Visual Editor project <ve-dev@xxxxxxxxxxx>

To	Discussions people developing code for the Visual Editor project <ve-dev@xxxxxxxxxxx>
cc
Subject	Re: [ve-dev] Read/Write of complex LayoutManager values

Ok, that filled in a bunch of blanks.  Bit of background
to hopefully focus/clarify things:

1) my plug-in will not be contributing the layout manager to the user's
project.  The forms.jar is a third-party jar, so I don't want to have
to manage/distribute multiple versions of the jar or get into the beta/release
cycle of jar upgrades.  I will have a forms.jar internal to my plug-in,
but it may be modified/instrumented.  So, I really don't want to make
that user visible.  Of course, my modified forms.jar needs to be the
one that is used in the remote VM.

I expect that a user will add an ordinary, stock forms.jar to their project
the old fashioned way.

So, I was not planning on registering a classpath entry for the users or
needing to initialize a classpath container; not implementing or using
any Wizard pages, so no need to specify "org.eclipse.jdt.ui.classpathContainerPage"
or "org.eclipse.jdt.core.classpathContainerInitializer".  Right?


2) my plug-in will not be contributing any beaninfo's or palette entries.
 It will just be a lowly layout manager with a simple layout.override
that will make it an available layout choice.

So, I was not planning on implementing any "org.eclipse.ve.java.core.registrations"
extension point.  Right?


3) I have used the "org.eclipse.jem.beaninfo.registrations" entry
point to register my layout.override.   That works using container="org.eclipse.jdt.launching.JRE_CONTAINER".

         <extension point="org.eclipse.jem.beaninfo.registrations">
                 <registration
container="org.eclipse.jdt.launching.JRE_CONTAINER">
                    
     <override package="java.awt" 
                    
               path="overrides/java/awt"
/> 
                    
     <override package="com.jgoodies.forms.layout"
                    
               path="overrides/com/jgoodies/forms/layout"
/> 
                  </registration>
         </extension>



4) I now see that I need to implement the "org.eclipse.jem.proxy.contributors"
extension point. 

In the org.eclipse.ve.swt package, the extension point used to indirectly
identify the remote VM adapter classes is defined as:

  <extension
         point=
"org.eclipse.jem.proxy.contributors"
>
      <contributor
            container=
"org.eclipse.jdt.launching.JRE_CONTAINER"
            class=
"net.certiv.ve.jfc.core.JFCVisualContributor"
>
      </contributor>
   </extension>

I will implement my own JFCVisualContributor class at the path location
indicated.  The question, however, is: Is using container= "org.eclipse.jdt.launching.JRE_CONTAINER"
correct?  

If not, how do I determine the correct container value?  Your explanation
of what a container is seems predicated on the use of Wizard pages for
user visible components in a user visible jar.  Do I need to fit into
that use pattern or do I point the container at my plug-in?  Base
it on the plug-in ID?

Thanks,
Gerald



At 07:51 AM 6/12/2006, you wrote:

Hi, 

It looks like your are close. This 

 container=
"net.certiv.ve.jfc.targetvm.formlayout.RemoteVMAdapter"

needs to be the container that you have that contains your "runtime"
code. It needs to be the container that supplies the jar that contains
the FormLayout class itself. You don't put your adapter class in that jar,
your put your runtime into that jar. 

The container is then added to a project that one of your customers would
be developing that would be using your FormLayout. The finding of the container
in a project does: 
1.        Supply
the FormLayout class to the project so that it can be referenced and used
(this is done through the <library runtime=...> of the "org.eclipse.ve.java.core.registrations"
and the org.eclipse.ve.internal.java.core.RegisteredClasspathContainerInitializer

2.        Tell
the VE that FormLayout is in the project path and that it should add the
palette contribution to the palette, and tells what runtime jar should
be added (the runtime=...). Through the "org.eclipse.ve.java.core.registrations".

3.        And
finally any development time code that needs to be available to the remote
vm (such as your RemoteVMAdapter) and supplied in a different jar. This
jar is not available to clients through the classpath container. It is
only available to the VE through the remote vm at development time. This
is contributed through a proxy contributor. _______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev