On 2 oct. 08, at 23:45, Deepal jayasinghe wrote:
I'm happy with Paul's proposal. However there is also another
alternative:
1) Keep the org.apache.axis2.transport package name for all
transports
(as it is now in trunk).
2) Before creating the first release of the new transports (and
therefore also before the next Synapse release; see point 3), we
create a new Axis2 release 1.4.2, which will basically be 1.4.1 minus
the old transports. Of course the persons volunteering to create that
release may decide to include other critical fixes.
3) The next Synapse release will depend on Axis2 1.4.2 and the first
release of the new transports.
4) In Synapse we implement the compatibility classes I suggested so
that we maintain compatibility at the axis2.xml level (at least for
one release cycle).
+1
Advantages:
* We have a common package name (not a mix of org.apache.axis2 and
org.apache.synapse) that is the same as the original one (before the
Synapse transports were created).
Well you are right , those are Axis2 transports I mean implement Axis2
transports interfaces so having o.a.axis2 is more meaning full. I mean
those transport can not be used without Axis2.(Even in synapse it uses
Axis2)
* Users of the transports (other than HTTP) have a better migration
path from Axis2 1.4.1 to Axis2 1.5. Indeed, the fact that the JMS and
mail transports are quite different from the old Axis2 versions will
make it necessary for them to retest (and maybe rework) their
application. If they can do that independently from the other changes
in Axis2 1.5, it will probably make things easier for them.
+1
* The compatibility problem caused by the package renames is only a
concern for Synapse, not for the whole Axis2 community.
My concern was Axis2 in general.
I didn't express my idea clearly. What I meant was that in my
proposal, only the transports coming from Synapse will have new
package names, so there is no impact on the Axis2 community in general
and the package renames will only be a concern for Synapse.
* Assuming that people from Synapse participate in the creation of
the
1.4.2 release and do the work, we could include some fixes that are
critical to Synapse.
Disadvantage:
* We can't change the dependency of Synapse trunk to 1.4.2 now,
because this release doesn't exist yet.
Yes I agree , for that let's try to do 1.4.2 release as soon as we
can.
There is an additional benefit when releasing 1.4.2 soon: it would
allow us to create the first release of the transports sooner, which
in turn allows us to get more feedback from the community. The
drawback is that we loose the last advantage I mentioned (i.e. that of
using 1.4.2 to get critical fixes for Synapse into Axis2).
Thank you!
Deepal
---------------------------------------------------------------------
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]
