If you only need it occasionally, you can always just add it to the xml of the definition and read that xml file when needed and get the specific attribute/element. No need to adapt the database for this.

http://planetjbpm.wordpress.com/2009/07/05/73/

Why wont that be helpful? Maybe the usage of 'occasionally' confused you. It did me when I re-read it. I meant to say that if you don't need to query based on these attributes you can just put it in the xml. If you do need to query on them, you can always when starting a task or process, read it from the xml and store it in a process/task variable.

Works perfectly for me

'all' ? 40? 6000? to query it every now and then... Still way easier than adding a table to jBPM, changing the deployer etc... or was that not what you meant?

If you meant creating your own table fully outside jBPM and when the deployer returns without an error you update your table, then I agree. One way or another I did not think you meant this.

You can also create additional columns in the existing jbpm tables ..so whenever a process and task is updated it will fill these columns with the meta data you want. You might need to declare this columns in your hibernate config and write a custom handler class..I have done this and it works brilliantly..

Also if you have a look at the ProcessDefinitionQuery there is no way one can use to query such meta information.

Personally, I would avoid adding columns to the existing tables themselves, again this rule DOES not apply to all, but if anything were to change within jbpm you could be potentially impacted. Which could be a fairly big problem for some.

So coupling one's own data with jbpm is a little riskier. It is best if we can isolate them architecturally. Put the data in a custom table, then associate the entry in the custom table with the id from jbpm. Open to as much extension as you want. But only couples minimally,

For us this low coupling is fairly important, so we go in that direction, your needs might vary, but be aware of the tradeoffs before you commit to either approach,.