[jbpm-dev] Re: Migration

[Ronald van Kuijk]

JPDL Changes:
+90% of the conversion of JPDL would be acceptable for me. In fact I think
it will be higher. The number of users that use really complex stuff is
limited. The number of users that accidentally abuse some functionality
because it was never intended that way but works might be higher.

API changes:
They are no problem for me since we've isolated those in PAO (Process Access
Objects) where the real jbpm api is used in a limited number of places (like
it is hidden when you use seam). Not sure about other users though, I just
hope they follow best practices as well.

Application/process retesting
Not a real problem for two reasons.
- I would introduce jBPM 4 in combination of a major release of the
application so it needs full testing anyway.
- I encourage TDD for the processes as well, so the behaviour of jBPM 4
could be tested before the full application is tested and errors caused by
upgrading jBPM could be tackled first.

DB change:
That is the area where I have the least knowledge about and like to keep it
that way. Way to many other technologies that I have to keep track of. But I
do have some additional remarks. My argument about the direct access to the
database via jBPM was not because of schema changes, but because of the
initial proposal (because of disgust ;-)) to remove this. That I think is
unacceptable. People who have written queries directly to the database are
mostly aware of the risk and are knowledgable about creating the queries.
They should have encapsulated those as well and so I think we have the
'liberty' to change the schema since they will be able to adapt fairly
easily. They will start asking questions like: what will happen with the DB
for 4.1 (easy answer: nothing that requires you to change again) or 5 (no
idea, Tom?) or ....

I think Thomas is right stating that deployment to 3 or 4 could be decided
in the new api and be based on the schema. Cannot remember this argument
came up in Antwerp btw. It would require code changes for the client since
they have to start using 'the' api.

Regarding Thomas additional statement:

>> Also mixing the libraries will be a very hard or impossible.
>Also not true. Project libraries should have distinct maven artefact ids.
> The container integration layer takes care of transitive dependencies that
are available to all BPM engines.

For normal webapps this might be true by using classloader scoping. I've
never used JBoss ESB extensively, so not sure if something similar is
possible (also not remeber this remark from Antwerp, but better late than
never)

What you (and Thomas) are in fact stating is that if Toms statement

> In most deployment environments, I don't think our users will have an
option to run jBPM 4 in a different DB schema then their own app and jbpm
3.

Can be addressed/solved/documented in some way, co-existence of 3 and 4
prevails.

Just my quick remarks
Ronald


On Wed, Dec 10, 2008 at 3:31 PM, Burr Sutter <bsutter at redhat.com> wrote:

> I'm curious to see if Joram, Bernd & Ronald agree (even a little) with my
> suggestion that a 90% conversion of DB, JPDL & API and the need to re-test
> the end-user application are substantial barriers to the any migration.  The
> question is how big are those barriers and we have to measure the cost
> associated with development of the conversion tools vs the likelihood that a
> user will be willing to take on the rest of the effort (the final 10% and
> re-test).  My guess is that many users will simply not migrate unless they
> are using jBPM in a "small way" or have issues causing them great pain in
> jBPM 3.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbpm-dev/attachments/20081210/5ab82435/attachment.html