Re: [jbpm-dev] [Design of JBoss jBPM] - API first cut available for jBPM3
Can you say a few words about the benefits are posted? Alternatively you
could also outline the benefits of providing an integration layer for
jBPM4 only despite that those concepts exist in jBPM3 just the same.
From a resource perspective, it is actually better to provide an jBPM3
integration. Doing so folks don't have to duplicate work to integrate
both with jBPM3 and jBPM4 - they can integrate with API instead.
The bulk of the API+CTS work is in well thought through API
interfaces/classes and comprehensive CTS test cases. It is not in the
integration layer, which (as you can see here) is actually very slim
http://anonsvn.jboss.org/repos/jbpm/jbpm3/trunk/modules/integration/src/m...
Anyway, its important not to wait too long before API and CTS maven
artefacts actually become available. I also don't care so much where
these artefacts come from or who makes them available. What interests me
is that they are available and within the scope of what has been agreed
on. Koen for example can only start his work if an API snaphot is available.
cheers
-thomas
Tom Baeyens wrote:
The scope of jBPM 3 work is already way beyond the resources we have
for
it. We should focus on the necessary work to put jBPM 3 in maintenance
rather then introducing a new API on it.
We said in the meeting in the context of the migration debate that no
API will be introduced in jBPM 3. A new API will be introduced in jBPM 4.
regards, tom.
thomas.diesler(a)jboss.com wrote:
> Folks,
>
> following our team meeting in Antwerp I trimmed down the API+CTS that
> I had in the incubator project to the functionality and concepts that
> we agreed on.
>
> http://www.jboss.org/community/docs/DOC-12945
>
> In Antwerp we decided that the threading model that is native to jBPM
> (i.e. borrowing the client Thread) should be supported by the API,
> which actually makes a mapping to the jBPM3 code base possible.
>
> How the API+CTS can be integrated in the Maven build is documented here
>
> http://www.jboss.org/community/docs/DOC-12871
>
> the Java Doc is here
>
> http://jbpm.dyndns.org/jbpm-spec/jbpm-spec-api/apidocs/index.html
>
> Doing this work for jBPM3 has multiple benefits.
> #1 It will be much easier to decide when jBPM3 functional equivalence
> is reached
>
> #2 Projects that require a stable API but also have a dependency on
> jBPM3 can start to decouple from jBPM3 implementation detail and
> interface with the API. This is particularly true for the GWT-Console
> and to some extend to the GPD.
>
> #3 The migration to jBPM4 will be seamless for projects that use the
> API as an integration point
>
> #4 TomB who leads the API and provides an implementation for jBPM4 can
> reuse the jBPM3 integration and make good progress in jBPM4.
>
> #5 Folks that know jBPM3 can start to provide qualified and meaningful
> feedback based on API signatures and CTS test implementations
>
> Over the next couple of weeks I still expect to see some movement in
> the API+CTS snapshot artefacts until it becomes clear what will
> actually go into 3.3.1 and 4.0.0.Alpha1 respectively
>
>
>
> View the original post :
> http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4190004#...
>
> Reply to the post :
>
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...
> _______________________________________________
> jbpm-dev mailing list
> jbpm-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbpm-dev
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
BPM Product Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx