JPDL Changes:<br>+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.<br>
<br>API changes:<br>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.<br>
<br>Application/process retesting<br>Not a real problem for two reasons.<br>- I would introduce jBPM 4 in combination of a major release of the application so it needs full testing anyway.<br>- 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.<br>
<br>DB change: <br>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 .... <br>
<br>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. <br>
<br>Regarding Thomas additional statement: <br><br>>> Also mixing the libraries will be a very hard or impossible.<br>
>Also not true. Project libraries should have distinct maven artefact
ids. <br>> The container integration layer takes care of transitive
dependencies that are available to all BPM engines.<br><br>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) <br>
<br>What you (and Thomas) are in fact stating is that if Toms statement <br><br>> 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. <br><br>Can be addressed/solved/documented in some way, co-existence of 3 and 4 prevails.<br><br>Just my quick remarks<br>Ronald<br><br><br><div class="gmail_quote">On Wed, Dec 10, 2008 at 3:31 PM, Burr Sutter <span dir="ltr"><<a href="mailto:bsutter@redhat.com">bsutter@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.<div>
<div></div><div class="Wj3C7c"><br></div></div></blockquote></div><br>