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).
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).
* 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.
* The compatibility problem caused by the package renames is only a
concern for Synapse, not for the whole Axis2 community.
* 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.
* Creating release 1.4.2 will probably trigger lots of requests to
include various fixes that people consider important. We can't satisfy
all these requests, in particular because the baseline for that
release will be 1.4.1, not the trunk.
Andreas
On 2 oct. 08, at 19:29, Deepal jayasinghe wrote:
So how about this for a compromise:
1) We ship all the new transports in separate JARs
+1 and we can have a single jar containing all the transports as well
(thats working now)
2) We rename all the transports to a new package name
I am sorry I am not still convinced to do this change. :-\
3) We do Andreas' suggestion - just for HTTP - so that the old
axis2.xml will work
4) Synapse can ship all new transports - everything except the HTTP
transport which will be inherited from the current axis2 kernel.
Yes only for the synapse version that depends on Axis2 1.4.
-Deepal
Paul
On Thu, Oct 2, 2008 at 6:17 PM, Deepal jayasinghe
<[EMAIL PROTECTED]> wrote:
I don't see any issue with backward compatibility. This chage is
something in the axis2.xml, this will not break any code that users
have with them.
Thats exactly my point I should be able to upgrade Axis2 without
changing axis2.xml. If you work with default axis2.xml then you do
not
have any problem , however if you have change your axis2.xml then
you
have to change that. That is the backward compatibility issue I am
talking here :).
If it was a API call then I can understand. Also this change would
not effect generated code (AFAIK).
---------------------------------------------------------------------
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]
