[jbpm-dev] Proposal for jBPM5 first release

Eric D. Schabell eric at schabell.org
Mon May 31 07:47:50 EDT 2010


> See comments inlined ...
>
> As a general remark, we know we need to start adding much more detail to the
> roadmap to define what needs to be done exactly for each component and each
> release etc. and we're working on that.  So I will keep the comments on a
> little higher level for now.
>
This is the part of the discussion I hope to be included in.

>> 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).
>>
>
> We are planning to do what we believe is the best way to do this and still
> feasible.
> But the compatibility between jPDL and BPMN2 has been defined in detail yet,
> so hard to predict exactly.  But documentation on how to migrate APIs etc. is
> definitely part of a migration strategy.
>
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.

>> 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.
>>
>
> Any suggestions on how we set up something like that? Different thread on
> the mailing list / forum for each of the components?  Open discussions on irc?
>
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.



More information about the jbpm-dev mailing list