The forum (or my browser) ate my post, trying again... "bill.burke(a)jboss.com" wrote : I'm reworking the JBoss+jBPM configuration and deployment structure: | (...) | 2. Getting up and started with jBPM is painful in a JBoss environment. | (...) | b) You need to modify your ant build to save your .jpdl into the database so that the jBPM server can pick things up. OR you do some other manual or programmatic process to get your process definitions in the database. | You can deploy process definitions using the web console or graphical process designer as well, but yeah... "bill.burke(a)jboss.com" wrote : I want to create a ProcessDefinitionDeployer for jboss. This will work like the SAR, EJB, EAR, etc... deployers. Users would be able to deploy a .jar file named "xxx.bpm" or a foo.jpdl.xml file. The jar file would contain a "META-INF/jbpm.jpdl.xml" file within it and any classes that could possibily be used by the process definition. | | At deployment time, the JBPM deployer would calculate a hash for hte .xml file. If this hash matches a previously deployed .xml file nothing is done. If it is a new hash, a new version of the process definition is saved to the database. I think this is a good idea. Though I've always disagreed with storing the process archive (especially the classes) in the database. If you're going to make a file-based deployer, it would be much better to just load the archive's classes the normal way in my opinion. The database ought to hold just enough of the graph structure to define the structure of the process and provide relations with its instances, and that's it. Also this is something that has always bothered me a bit - process versioning. If the user has a process that is deployed into production, and there is a bug discovered after deployment, say a coding error like an NPE, the user cannot deploy a replacement process. They must deploy a new version, and manually (because there is no automated way) convert each running process instance over to the new process version. Your method of hashing the xml file would improve that substantially since coding bugs can be corrected. I'm not so sure that hashing the XML file would be the best solution though - I think it might be better generate a hash off of the actual semantic graph structure (since it's really changes in the graph structure that would *require* a new version), and also an (optional?) user-supplied version number (in case they want to deploy a new version of a process that has the same structure but maybe different java code behind it, so the XML file would otherwise be unchanged). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051935#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...