GPD extension point changes

[koen.aers]

Hi all,

Because of the need to specify the icon and label in a more flexible manner and the inability of the JpdlLabelProvider class to handle this, I have done some work on the extension points the last two weeks. As I expected, this resulted in a lot of refactoring and even in a complete revision of the two plugins. I have merged the 'org.jbpm.gd.jpdl.core' and the 'org.jbpm.gd.ui' plugin in one single plugin that is called 'org.jbpm.gd.jpdl'.
If you checkout this project you will see that some extension points have changed and that I added some new ones.
The first big change is that you now are able to contribute DSLs by using the 'org.jbpm.gd.jpdl.dsl' extension point. This dsl will be associated with an editor that is contributed to the 'org.eclipse.ui.editors' extension point. The association between the dsl and the editor still needs a lot of work. The idea is that you will derive from a class which has already a lot of the glue defined.
After you defined the DSL and have associated it with the editor, you can start contributing the semantic elements of this dsl by using the 'org.jbpm.gd.jpdl.semanticElements' extension point. As you can see, you specify for each contributed semanticElement to what DSL it belongs. For jpdl, the semantic elements are actions, nodes, swimlanes, etc. You can specify a label and an icon and of course an implementing class in the extension definition.
The third novelty is to define a mapping to the generated xml by using the 'org.jbpm.gd.jpdl.xmlMappings' extension point. Here you specify the implementing xml adapter class and the xml element that corresponds to the semantic element.
I think these changes will improve the flexibility a lot and make the plugin ready for complete pluggability of DSLs. Things that still have to be reviewed are as already said the Editor class itself but also the palette and editparts which should also be made completely pluggable. I will first try to get back to my planned roadmap and finish the jPDL language support.
In the future you can also expect a split (again!) of the plugin to isolate the common base classes that are the same for each DSL in a 'org.jbpm.gd.common' plugin.
Thoughts?

Regards,
Koen

[kukeltje]

Sounds great (not that I will have the time to check these details out, let alone contribute :-) )

- Some questions though. DSL stands for domain specific language correct?
- Is the org.jbpm.gd.jpdl.xmlMappings for extending jpdl only? (I think yes)
- the is org.jbpm.gd.jpdl.dsl the correct package for adding DSLs? shouldn;t that be org.jbpm.gd.dsl or is this what you mean bty the last sentence?

btw now that there is a 'design of webconsole' forum, don't you think it is time for a 'design of gpd' as well?

[koen.aers]

"kukeltje" wrote:
- Some questions though. DSL stands for domain specific language correct?

Yes this is correct.

"kukeltje" wrote:
- Is the org.jbpm.gd.jpdl.xmlMappings for extending jpdl only? (I think yes)

The answer is no. I will use the same extension point to map pageflow elements to their corresponding xml. But the name will change once I isolate the common base classes in their own plugin to eliminate the 'jpdl' reference. The name of Eclipse extension points derives from their defining plugin in fact. So if the name of the plugin containing the common things is 'org.jbpm.gd.common' the name will be 'org.jbpm.gd.common.xmlMappings'. If the plugin name is 'org.jbpm.gd' than the extension point will be called 'org.jbpm.gd.xmlMappings'. I think I am inclined to use the latter.

"kukeltje" wrote:
- the is org.jbpm.gd.jpdl.dsl the correct package for adding DSLs? shouldn;t that be org.jbpm.gd.dsl or is this what you mean bty the last sentence?

Yes, following the rationale above, the name of the extension point would be 'org.jbpm.gd.dsl' or 'org.jbpm.gd.common.dsl'.

"kukeltje" wrote:
btw now that there is a 'design of webconsole' forum, don't you think it is time for a 'design of gpd' as well?

I am not in favour of this. At least not at this point. Maybe when there are a lot of extenders with issues that are not very jBPM related this would make sense. But for now I would keep things as they are. The bandwith of this forum is not huge anyway.

[kukeltje]

thanks,

oh btw, the bandwith is huge... the throughput is not :-)