[jbpm-dev] Proposal for jBPM5 first release

[Kris Verlaenen]

Eric,

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.

Eric D. Schabell wrote:
> 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.
>   
Yes, don't think we can have a first milestone without an engine, right? ;)
Regarding existing components, if you're talking about the core engine, that
actually is just one component, right?  And thus we be based on the existing
core engines from jBPM and Drools Flow.

> 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.
>   
Drools Flow already contains an independent human task service that 
follows the WS-HT spec,
so we're planning to reuse that.  Web tooling is based on the existing 
gwt-console.  The first
release will mostly focus on consolidating and integrating that in the 
large picture I think.

> 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?
>   
All this is a continuation of the existing jBPM and Drools Flow tooling, 
but now
focusing on BPMN2.  Both were already based on the same core.

> 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?
>   
The idea is to leverage Drools Guvnor for this.  This already allow 
Drools Flow
processes (and related artefacts) to be stored there, but obviously this 
needs to be
extended for BPMN2.

> 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.
>   
Based on the process management capabilities in the current gwt-console.

> 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.
>   
Yes, I know it's not easy to provide installation scripts for 
everything, but I don't
think that should be the goal.  But for people who would like to start 
playing with
our project but don't have deep technical knowledge about everything, 
just a simple
demo setup to get started is already a huge benefit imho.

> Documentation
> ===========
> Blank == nice to have? ;-)
>   
Any volunteers? ;)

> 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.

> 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?

Thanks for the help Eric !

Kris