"camunda" wrote : 1.) contribute some jbpm commands (because we had written some additional logic like updating a process version in special cricumstances) to get rid of our own service-classes. | great. put them in org.jbpm.command package. the good thing is that commands are isolated. so you can't break any existing stuff. "camunda" wrote : 3.) Extract the generic code we used for a Swing-Tasklist and opening tasks in Swing panels to form a generic framework for Swing applications working with jBPM | a minimal working swing client would be nice. even better would be a client based on eclipse rcp. ever thought of doing that ? "camunda" wrote : One problem is maybe, that we have some very pragmatic commands in our toolkit (e.g. updating the process version of a running instance in the case, that there is a note with the same name in the new version), which we also want to contribute. Would that be OK for you? | process migration is a good command. providing that functionality is on my todo list as well. i want to do this as follows: input is a processInstance, a new processDefinition and a map of old node names to new node names. any help in that is appreciated. even if your code doesn't yet have the node map integrated. "camunda" wrote : Maybe I can make a package org.jbpm.command.experimental for that? | no need for that. put it in the org.jbpm.package. if you can, such info should be in the documentation. i guess the most practical place to start documenting commands is in the javadocs. "camunda" wrote : A second thing is, that I need for Swing-applications some GetProcess/Task/.../Command's, because I need to preload some parts of the objects graph before give the result to the client. But the advantage is, we can get rid of any DataTransferObject's we currently use in the AdminClient. I will just add them to the core, ok? | yes, please add them. "camunda" wrote : Also I will not have a JUnit test for every command, even if they are working in some real life applications... But I will work on that issue as soon there is time! | as long as the average test coverage is ok, this is good. but beware that writing a test also guards your code of being evicted if you can't maintain it any more. if untested code starts producing problems and you're not around to fix it in a reasonable time, we might decide to evict that code... With unit test we can fix it ourselves, even if you're not around. great plan. thanks. sorry for late reply View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002180#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...