"koen.aers(a)jboss.com" wrote : "barteljan" wrote : Yes I fear that's true, I thought of a situation where I give a customer just the editor to create processdefinitions without a possibility of testing or executing them. It could even happen that I want him to model a process with actions which have to be implemented in the future. | | In such a situation it would be a bit of annoying to provide java-classes or some stubs for him, but a config-file (even if this could be in the jbpm.config.xml) isn't really better .... | | | The only good solution in my opinion is a plugin-based solution. IE every node you want to contribute is an extension to the extension point that defines how to add new nodes to the editor. | Yes "koen.aers(a)jboss.com" wrote : | The different elements of information that are needed to do this in its most simplified form are: | - a description of the node that has to be added (the properties of the node) | - how to serialize the node | - how to deserialize the node | Additionally the following elements are optional: | - description of the figure representing the node | - the icon and/or text that have to appear in the palette | - the path in the palette where they have to be added | | Of course, you can even more generalize the possible extensions by defining a generic node type what is always serialized/deserialized in the same way and of which the properties are simple attributes and/or some well-known child elements. In this case the 'pure' xml solution comes in the picture. | Or one where you can implement a specific interface and/or annotations or both (not sure what is easier to find/parse classpath wise, maybe something like seam does) "koen.aers(a)jboss.com" wrote : | Nevertheless, I have a preference of describing these extensions in the plugin.xml of a plugin that adds these custom nodes instead of adding a jar file containing these xml files somewhere on the classpath (either by configuring a preference in the workspace or adding a jar file in a projet). | For the element-name based extensions I agree, for the generic (custom) node type extension I don't. Not having to know anything about eclipse plugins, distributing your own ones and still be able to create 'extensions' is a (u)sp "koen.aers(a)jboss.com" wrote : | The latter solution (including the xml config in a jar file) is a more specific case of the former one. The former solution is not yet completely implemented at present. Roughly the following things need to be done first: | - define an extension point for serialization/deserialization | - define an extension point for the palette items | | If you want to dive deeper into this, take a look at the Registry class in the package org.jboss.tools.flow.jpdl4.io and the JpdlPaletteFactory class in the org.jboss.tools.flow.jpdl4.editor package. The first step is to refactor these two classes and let them do their job based on information that is contributed in the plugin.xml by extensions of two new extension points. Another thing that you definitely want to look into is the already existing extension point for adding elements to the GPD (defined in the plugin.xml of the org.jboss.tools.flow.common plugin and used in the plugin.xml fo the org.jboss.tools.flow.jpdl4 plugin). It will show you how to create and use extension points. More in particular the class ElementRegistry in the package org.jboss.tools.flow.common.registry will be a good source of information. | I'll have a look to"koen.aers(a)jboss.com" wrote : | | I'll add a reference to this thread to GPD 292 and we can continue the discussion there. Also feel free to attach patches if you're fiddling around (or happen to define the extension points) so that i can test them. Make sure you sign the contributor's agreement if you're going to do this. | | Cheers, | Koen View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254536#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...