On yesterday's IRC chat we discussed WSCOMMONS-131, which causes the current Tuscany M2 RC to have a SNAPSHOT dependency on axiom-api. This creates a "time bomb" which would cause the Axis2 binding in Tuscany SCA Java M2 to stop working at some future time when incompatible changes are made to the axiom-api trunk.
On the chat we identified 3 options that we could consider for how to deal with this problem. 1. release what we have 2. release without axis 3. wait until axis is fixed Other options were discussed but did not get much support. For the three that I have listed above (as summarized by Meeraj on the chat), there are some variations and refinements. I have tried to summarize the main points that were made in the chat in the paragraphs below. For option 1, we could mitigate the problem by explaining it in our M2 release documentation, and we could release an update to the Axis2 binding (a mandatory patch) that fixes the problem as soon as new axis2 and axiom releases are available. As long as there is no breaking change to axiom-api before the new release is available, this means at all times we would have a combination that works. The downside is that it looks bad to release something that we know is broken (or will become broken in the future), even though there is a patch available to fix the brokenness. For option 2, we could remove the Axis2 binding and testcases that depend on it. Or we could just remove the Axis2 binding and document that the Axis2 testcases don't work at the present time. Then we could release the missing pieces as soon as there is a new Axis2 release that fixes the problem. The disadvantage of this is that this removes a large part of the funtionality and value of the M2 release. Alternatively, we could create a more modular release structure (which will be needed in the future) and repackage M2 in a more modular form with separate releases of the core and extensions. This has the same disadvantage that the initial release doesn't have all the functionality that we had intended for M2. However, it does not require extra effort (over the long term), since it brings forward some work that we will have to do anyway. The problem with bringing it forward is that we would would be doing it under time pressure to get something out, thus creating tension between allowing full consideration of how the modular structure would work (including some tricky issues about compatibility of the modular parts), and doing the restructure quickly so that we can release M2. Option 3 has less in the way of variations and sub-options. The big unknonwn with this is how long we would need to wait, and how damaging to Tuscany it is to wait compared with the downsides of option 1 or 2. Given the experience of how long we had to wait for Axis2 1.1, there is concern about another another long wait. However, this new release would be a simple patch to 1.1, so it should be possible to get it out very quickly. There is currently no information about how soon a new release may be available. Is this a fair summary of the options? Would anyone like to add additional rationale either pro or con any of these, or express their preference(s) for or against any of them, or add any new options that we might seriously consider? Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
