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.