"bill.burke(a)jboss.com" wrote : I've been thinking about this a bit the last day. Here's the advantages, IMO, of the new deployer I'm proposing: | | * Easier for newbie to get start. One last thing they have to worry about. | * Easier for development | * Less configuration | * Doesn't impair other jBPM deployment options | * gets in line with how other JEMS projects deploy into JBsos | | Disadvantages: | * Not portable to other application servers. (Until we get JBoss Embedded going). | * I don't think this will work well with class versioning unless we add metadata to the .par (like a version number) | could you summarize your new proposal on a wiki page cause a lot of arguments and aspects have been put forward in this discussion and i lost track of which combination your evaluating e.g. on http://www.jboss.org/wiki/Wiki.jsp?page=JbpmJBossDeployment also, it's not a question of pro's and con's for me. i'm all in for a jboss deployment model in addition to the models that we have. the deployment models might be sanetized later, but to date, we don't have a clear enough view on what people actually need. so we offer everything. the motivation is that people must be free to work the way *they* want. we shouldn't force them to work in one way or another. "bill.burke(a)jboss.com" wrote : | My questsions are: | * How often is versioning used? | It's used quite a bit. Although we recommend for performance reasons to skip versioning of classes and just put them in the classpath. "bill.burke(a)jboss.com" wrote : | * How many versions are live at one time? How many versions do applications usually have in play? | no clue on the average. but process instance migration is not a straightforward task. when you deploy a new process definition (either as a new separate definition or as an update of the existing) you'll need to convert the old executions to the new definitions. if all the nodes are the same, it's easy to convert the tokens to the new process. if you can map old node names to new node names that could be an enhancement too. but in the general case, you can't translate old process instances to new definitions. even your concurrency model might have changed. in that case it becomes impossible to map the old tokens to new tokens. on top of that, you need to take the logs into account. in case of a process update, the previous logs might not match the process definition any more. that is why i only see one way of handling versioning: when deploying a process that already exists (process equality is based on the name), then a completely new process definition is created. old executions keep running in the old definition, new process instances are started in the new definition. "bill.burke(a)jboss.com" wrote : | One last thing: | * Maybe with this new deployer, versioning should be turned off by default? | * Should a piece of metadata be added to the deployment to say whether or not it should be versioned or just overwrite the old deployment? see previous remark about process instance migration. please explain how you want to handle that if you talk about not doing versioning. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052783#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...