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

[Gerald Rosenberg <gerald@xxxxxxxxxx>]

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.