We're using jBPM 4 at the PVM level to support a Groovy-based domain-specific process language. In any new version, I'd like to see the PVM API more formally defined and documented - at the moment it feels like we are taking a risk messing about in the internals of jBPM. Perhaps the PVM could be a separate sub-project in its own right? This hard separation might also help improve its design - it seems to be getting more muddled with each release of jBPM 4, for example exposing implementation classes in APIs rather than the interfaces they implement. I'd also like to see the back of the strange dependency-injection/configuration framework in jBPM, and be able to use any DI framework (e.g. Spring) to fully configure jBPM. Thanks, Alex. -----Original Message----- From: jbpm-dev-bounces(a)lists.jboss.org [mailto:jbpm-dev-bounces@lists.jboss.org] On Behalf Of Kris Verlaenen Sent: 16 April 2010 17:29 To: jbpm-dev(a)lists.jboss.org Subject: [jbpm-dev] jBPM5 Request for Comments Over the last few years, we have accumulated a lot of knowledge and experience in various BPM-related projects here at JBoss, and in an effort to consolidate that, we would like to combine our efforts in what will be the next generation BPM platform, called jBPM5. jBPM5 will be based on the combined experience of jBPM and Drools Flow (and related projects like RiftSaw and Overlord), and will bring together the benefits of both solutions (and much more). As part of this process, we would like to ask you, our community, for feedback and assistance on this. The architecture of jBPM5 builds on the experience that was built up over the past few years based on our customer feedback as well as strong community involvement. It will continue the vision of all of the constituent projects, so large parts of the architecture that is presented here will probably not come as a surprise to you, either because it already exists in a current project or because it has been on the roadmap for quite some time (e.g. BPMN2). Nevertheless, wide feedback is very important to us, and we have therefore constructed a "Request for Comments" document which describes (what we believe could be) the new architecture of jBPM5. Now is the time for the community that has helped shape these projects so well in the past to do so again. http://community.jboss.org/wiki/jBPM5RequestforComments This not only includes an overview of the most important components, but also some of the key characteristics. Based on this architecture (and the feedback we receive), we will roll out a roadmap for jBPM5. We would like to welcome any feedback feedback on this proposal, using the jbpm-dev(a)lists.jboss.org mailing list, or in private by sending your comments to your JBoss contact. If you want to subscribe to the jbpm-dev mailing list or browse the archive, use: http://lists.jboss.org/mailman/listinfo/jbpm-dev Kris _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev

Alex, When you are talking about a Groovy-based domain-specific language, could you provide some detail on what you are actually trying to achieve by using the PVM directly (for example, are you extending jPDL or providing your own language altogether)? It is probably true that more emphasis has been put on providing a clean client API, and there's still some risk associated with using the PVM directly. We hope to tackle this as well as part of the modularization of the project. Kris