The Next Generation of the GPD

[koen.aers]

Hi Guys,

I may be addressing the wrong crowd here but anyway :-))

I am currently investigating the different options for creating the next generation of our GPD.

At this point I am inclined to make use of the Eclipse GMF project. I have spent some time experimenting with the tools support and generators, and was a bit disappointed as they still seem immature. I am anyhow not a big fan of generators... OTOH I am fairly enthusiastic about the GMF runtime. It offers a lot of advantages and nifty features we are currently lacking because of not enough time and it seems to have all the right extension points to be a good fit for our GPD. For those of you interested, here is a short overview article on the GMF runtime.

The most apparent drawback I have at this point is the use of EMF as the model for the editor. There is still an unknown part for me that is the integration/adaption of the EMF model and the persistence mechanism to serialize this model as plain XML. I know that there is some support for doing this in the form of an EMF-to-DOM-adapter, but I did not (yet) investigate this.

Anyways, if anyone of you has experience with GMF, knows about additional advantages/drawbacks or has additional thoughts about this, feel free to step in and comment...

Regards,
Koen

[kukeltje]

I may be addressing the wrong crowd here but anyway :-))

Yep, just GPD users here ;-)

[koen.aers]

"idris yuce" wrote:
Hi Mr. Koen,
We are using both jbpm and its graphical process designer in our project.
So far we have extended both project according to our needs, and we chose to extend both projects, not to change their implementated code in order to have minimal problems when migrating new versions or releases.

For jbpm we have implemented many custom actions, nodes etc and we have implemented their gpd counterparts.
As we follow the forum and keep track of gpd related topics we realized that you will make many changes to next generation of gpd. So i want to ask a few questions about your plans on design and implementation of next generation gpd.

- When do you think to release the next generation of gpd? Because as you guess we have due time for our projects. if we can get even an enough approximate answer we may reorganize our roadmap and timelines.
- Do you think our extensions to gpd (Custom nodes,actions, property pages etc...) will be affected and must be reimplemented if we migrate to nex generation gpd. Because in forum topic( http://www.jboss.org/index.html?module=bb&op=viewtopic&t=81223 ) you have said that you may use eclipse GMF projects apis for infrastructure of next generation gpd.

best regards,

idris yuce.

The next generation is currently still in its inception phase. It is to me still unclear wether to go the GMF route or let the current codebase evolve. Both options will finally break API and cause certain extensions to be reimplemented. If we choose the former option, you should not expect the first releases before the end of the year. For the latter option, the way is much more evolutionary, so I cannot say very accurately at what point in time API breaks will occur.
Btw. I am interested in the extensions you implemented. What kind of extensions are they exactly? Would they make sense as contributions?

Regards,
Koen

[idyuce]

Hi Koen,
The extensions we have implemented (Nodes,actions,handlers etc...) are more specific to our needs and our own j2ee framework. So at this time i dont think they make sense as contributions. But whenever we think that an extension or implementation could be a contribution we will contact related people asap.

thanks
idris yuce

[koen.aers]

Hi Idris,

That is nice. Anyway, we are also interested in the ways you use and embed jBPM in your own systems. We are always eager to have additional (public) references about the use of our product. It allows us to get funding more easily, which is in turn good for further feature development and quality improvement...

Regards,
Koen

[idyuce]

Hi Koen,
sorry for late response,
As i mentioned before, we have done some extension to jbpm and gpd for our necessities. i will summarize what we have done so far later in that topic as you wanted. Now i dont have so much time but i will write asap.

[idyuce]

Hi ,
well i will write shortly about what we have done about jbpm in our project so far.
- We have implemented;
- custom nodes and actions as i mentioned. For integrating jbpm with our own j2EE framework and some specific needs for exmaple compensating,authentication etc...
- custom task assignments handlers with special assigment configurations.
- Custom decision handlers.
- custom taskcontroller.
- custom process definition ( subclass of moduledefinition) for needed process definition fields.
- custom process instance (subclass of module instance) for needed process instance fields.
- Custom variable converters for variable persistence.
- Custom TaskInstance class (subclass of TaskInstance) with its related factory clasess.
- custom log classes related to process instance, task instance etc...(subclasses of processlog)

As i mentioned before, we havent changed jbpm api but there were some points that we couldnt extend classes of jbpm. Therefore, in that points we have used aop interceptors (for expample reading process definitions extra fields, adding custom logs as jbpm logs process etc...). We used jboss aop api as aop framework and it worked fine so far. We used compile time class instrumentation.

Well, that was the summary of our jbpm related works. But our process continues because we havent finished integrating jbpm fully with our project yet. There are some more jobs to do.

regards,

idris yuce

[koen.aers]

Idris,

This looks really great. It would make a great presentation on the JBoss World conference...
Make sure to send an abstract for the next conference, I would say.
Or if you write an article about it, we can maybe link to it from our product page.

Cheers,
Koen

[jvdam]

Hello Koen,

At this point I am inclined to make use of the Eclipse GMF project.
........
The most apparent drawback I have at this point is the use of EMF as the model for the editor. There is still an unknown part for me that is the integration/adaption of the EMF model and the persistence mechanism to serialize this model as plain XML. I know that there is some support for doing this in the form of an EMF-to-DOM-adapter, but I did not (yet) investigate this.

Anyways, if anyone of you has experience with GMF, knows about additional advantages/drawbacks or has additional thoughts about this, feel free to step in and comment...

We would very much welcome a move to GMF, because it will make it easier to extend and integrate with other EMF based tooling. Our experience in using specialized resource handlers and adapters (to adapt to existing formats like you would like to do I suppose) is also very positive. There is quite a strong backup for GMF within the Eclipse Modelling project and they are going forward rapidly.
I would certainly be willing to contribute if GMF will be the basis for the next GPD version.

Regards,

Jim