It would certainly be irresponsible to put out this release with a
lurking problem unless we also create a workaround and release it
before the problem starts to impact our users.

Raymond's point is well taken and I hope that the Axis2/Axiom
community will create a release very soon to fix this problem even
though they are not severely impacted by it.

I don't think we should refactor the M2 branch before the M2 release.
This is too large a change to be making at this late stage.  If we can
be confident that the fixed Axis2/Axiom release is really only a few
days away (i.e., this week or by the weekend), then we could wait.
Otherwise I think we should release M2, document the issue, and
release an updated Axis2 binding as soon as the new releases of Axis2
and Axiom are in place.

  Simon

Raymond Feng wrote:

FYI: I have got Sanka and Dims's attensions and the patch is now in the JIRA.

We have a different usage here than the axis2 1.1 with axiom 1.2. Axis2 1.1 ships axiom jars in the distro but we load them from maven repo at build/runtime. So the issue has much more serious impact against us than the axis2 or axiom release.

Thanks,
Raymond

----- Original Message ----- From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, November 28, 2006 8:43 AM
Subject: Re: WSCOMMONS-131 and options for Tuscany SCA Java M2 release


I think that it is irresponsible to put out a release that we know has a lurking problem in it with no workaround.

I was chatting with Raymond yesterday and he was planning on working with Axis2/Axiom to get -131 fixed fairly quickly so waiting a few days should be no big deal.

In the mean time we can start the refactoring of trunk to support more modular releases (given we need to do that anyway). If this is ready before the fix for -131 then we can consider making the same changes in the M2 tree.

--
Jeremy

On Nov 28, 2006, at 5:51 AM, Simon Nash wrote:

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]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to