Hi, Very good map. The only observation i've on this roadmap, is that unfortunately i've not seen any plan towards OSGi integration. This would be a very important feature for me.... Andrea Il 25/05/2010 17:06, Kris Verlaenen ha scritto:

Hi Kris, I'am a jBPM 3 and ( maybe i'm wrong ) i've always considered jBPM as a "the process engine" and drools as "the rule engine" and in myprojects i've try to keep it separated, in my typical use case i've used mainly jBPM and i've implemented some custom handler powered by drools to inject in my processes the ability to take different flow according to business rule for which rules are the right solution. So talking about an OSGi integration, i really means a deep integration within JBPM. In particular: 1) Be able to expose jBPM API throuhg OSGi services 2) Be able to use OSGi services within jBPM 3) Be more indepent by persistence layer ( hibernate could be problematic within OSGi.... ) In my current project ( www.spagic3.org ) i've just solved 1) and 2) ant it was not so easy... For the 3) point the only solution i've found quite know it to keep jbp, hibernate and all the dependencies incapsulate in my own bunlde.... and expose through OSGi a my custom API interface.. Andrea Il 26/05/2010 14:17, Kris Verlaenen ha scritto:

Hi Andrea, Export service is much easier than handle the persistence layer. Hibernate is truely hard to integrate into OSGi environment. Since it just store the classname as String and initialize instance everytime. I don't know other JPA framework could handle this. And in the jBPM 4, there is still some classloader issue for running on OSGi environment. Or Maybe we should provide an OSGi platform with jbpm as a system package. So we needn't worry about the classloader issues. regards 2010-05-27 Xu Hui Sheng WebSite: http://www.family168.com/ 发件人： Andrea Zoppello 发送时间： 2010-05-27 16:13:24 收件人： jbpm-dev 抄送： 主题： Re: [jbpm-dev] Proposal for jBPM5 first release Hi Kris, I'am a jBPM 3 and ( maybe i'm wrong ) i've always considered jBPM as a "the process engine" and drools as "the rule engine" and in myprojects i've try to keep it separated, in my typical use case i've used mainly jBPM and i've implemented some custom handler powered by drools to inject in my processes the ability to take different flow according to business rule for which rules are the right solution. So talking about an OSGi integration, i really means a deep integration within JBPM. In particular: 1) Be able to expose jBPM API throuhg OSGi services 2) Be able to use OSGi services within jBPM 3) Be more indepent by persistence layer ( hibernate could be problematic within OSGi.... ) In my current project ( www.spagic3.org ) i've just solved 1) and 2) ant it was not so easy... For the 3) point the only solution i've found quite know it to keep jbp, hibernate and all the dependencies incapsulate in my own bunlde.... and expose through OSGi a my custom API interface.. Andrea Il 26/05/2010 14:17, Kris Verlaenen ha scritto: _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev

Hi Kris, I am glad to see the roadmap up on-line but without a planning / milestones it is not yet clear what is going into the various components. I posted some specific comments in reply to Brad's post, here are some general comments on this roadmap (it is really missing the details and feels like a quick copy of the RFC to me): Core process engine using BPMN 2.0 =========================== Glad to see the common executable worked out in the roadmap, this is what we can expect. Should be in the first milestone. Would be nice to see the existing components listed that can be leveraged or merged for this functionality. Human tasks ========== Going to provide complete spec support in first milestone release along with human task web console supporting the task life cycle (claim, start, complete, etc.) and custom task forms? If not would be nice to see the work listed that needs to be done, leveraged from other implementation, etc. Eclipse-based tooling for creating BPMN2 processes ===================================== Seems this can be leveraged from the existing components? list them out maybe with the milestones that they will appear in. What about "basic validation, testing and debugging," this means? does this map to existing components? Web-based tooling for creating BPMN2 processes =================================== Here you map it to the existing implementation, great! Process repository ============== Can you expand on the components that already exist? What is here and not so that you can provide milestone dates for what will appear when? Pretty sure you are going to leverage the JCR stuff from Drools or extend this for process definition artefacts for example? Process management console ===================== A core component if we want to sell this thing! Details again, what it will do, what can be leveraged, what is to be done and milestones they will appear in. Reporting ======= Nice to have... Installation script (and demo setup) ========================= Leveraging the existing jBPM4 stuff? what are you going to target? community scripts are way too monolithic for customer usage if you ask me. Anyway, again a breakdown and planning would be nice. Documentation =========== Blank == nice to have? ;-) Migration ======= I think you need to take a look at API mapping too. Why not provide some api call mapping in the tooling where it is possible? I expect I would be able to provide customer input (code bases) for looking at real world implementations to start generating a matrix of used calls for example? Just migration of the jPDL 3/4 -> BPMN2.0 would be rather weak attempt. If it turns out that a customer uses API calls, no custom SQL or hibernate tweaking, plays nice in the infrastructure code they create, then it is conceivable that we could provide simple instance migration. (Cross your fingers!). I have a personal interest in this area and if we can go a bit farther in detailing the components and development that needs to be done in the roadmap, I will complete my blog articles on jBPM Migration Strategies (http://www.schabell.org/2010/03/jbpm-migration-strategies-introduction.html). Conclusions: ========= Basically I would like to discuss the details within each area to be developed for the roadmap; what is the break down of components to be developed, what is existing and/or ready to be leveraged, map this to the components, planning in milestones for what is to appear and when. With that kind of roadmap you can then leverage JIRA for the roadmap creating milestones for all to watch progress and/or help with by picking up work to be done. Looking forward to this, erics On Tue, May 25, 2010 at 5:06 PM, Kris Verlaenen <kverlaen(a)redhat.com&gt; wrote:

This is the part of the discussion I hope to be included in. Excellent, this is pretty important part of migration to even get a customer to take it seriously. Just jPDL to BPMN2 at process definition level would be too simplistic. I have setup this several times in my previous work, using just JIRA and my dev team used the Mylyn plugin to keep a focus on their assigned tasks. This is not required as the web interface with JIRA works just fine too. It is just a matter of having a project lead that takes the time to orchestrate the process and sort out the milestones. I would be more than happy to help, just need to be in on the planning phases. The mailinglists and dev lists are fine as is, for discussion the problems/progress, etc. Irc is great for meetings, ad-hoc discussions and poking the developer in question! Btw, what or which irc are the jBPM developers hanging out on? Let me know if you need help with this, I can make some room for this in my schedule.