Seam redeploying jBpm process definitions

[jcox1]

Is there a way to prevent Seam from redeploying jbpm processes definitions each time the application redeploys?

While this is handy the first time you change or define a process, it starts to fill the database tables with redundant process definitions.

Thanks,

Jack

[norman.richards]

The process deployment feature of Seam is a development tool. When you are to a stable point in your development, you should remove the jbpm process definition from your components.xml and use the jbpm tools to manage process deployment. You can also build process management into your application - take a look at the way the dvd store lets you change process definitions.

[jcox1]

Norman, thanks for the reply. I'll do that. I wonder if a simple component to check the file date of the process definition against that in the database and load the new definition if the file is newer would be worth putting together.

I've been very impressed with Seam and jBPM thus far.

[norman.richards]

The date in the database and the date in the file system are not necessarily in sync. I think you really need a process version number to solve the problem. It wouldn't hurt to whisper the the JBPM guys over in the forum that users want better control of process versioning. If JBPM supports a more sophisticated versioning strategy, we'll gladly support it. However, I really think they are more focussed on the tools capability because that's probably more what more what a BPM-minded person would tend to want.

That's not to say there isn't more we can do on our own though...

[kukeltje]

Even better... no need to whisper... just add a comment to the discussion on this subject. I'd like to add "vote for this jira issue" but I have to shamefully (?) admit that there is no issue related to the discussion on the jBPM forum. There is however one that seems related to what is mentioned in this topic: http://jira.jboss.org/jira/browse/JBPM-708. So maybe we should hijack this jira issue :-)

[norman.richards]

I love Tom's comment on that JIRA issue.

[avbentem]

Just for the archives: as for documenting this issue see JBSEAM-1034.