Sanjiva
Sanjiva Weerawarana wrote:
- First of all, Asankha, why "synapse-transports.jar"?? That makes no
sense to me- so if you have a bug in the VFS code you'll rev all the
stuff? Why? There should be one jar per transport. Yes, lots of jar
files but so what?
- Asankha, you seem to think that the only place transports that
Synapse finds interesting are being done is in Synapse. What about
CORBA? The code is in Axis2 (and Eranga is still waiting for his
commit rights to come thru to finish that off) and of course
supporting CORBA is very interesting for Synapse. So you're not
solving whatever problem you perceive by saying "keep everything I
care about in Synapse."
- I agree with that Axis2 transports should NOT be in the kernel jar.
Can we finally agree (forget the history please) to that now and
create new maven modules for each transport and put each one into its
own jar? This is for the transports that are (or will remain) in
ws/axis2.
- Given that these transports are usable by anyone building on Axis2
(and not just Synapse) and that they depend on Axis2 APIs, I believe
they should be in a project which releases those transports against
given versions of Axis2 APIs. My preference is that it should be in
ws/commons/transports or a new sub-project called ws/transports.
Asankha, what problem do you see in that approach? I think everyone
would +1 you being the RM for this project ;-).
+1 to all above
- How about the following compromise position:
- we create a new ws/transports project and move http and any other
transports out of axis2 into that.
- we kill the old NHTTP and JMS tranports in axis2
+1, lets get someone from Axis2 to do this as the first step. I will not
be able to work on this at least into the next few weeks..
- move JMS and SMTP out of synapse into the new project
- as a general rule, if Axis2 and Synapse are both going to ship the
transport in their default distros, then we move the code here
- for other transports we strongly encourage people to put them here
to enable easier wider use
- this project publishes each transport as a separate jar with a
naming convention that identifies the axis2 (API) version it
corresponds to. of course trunk will correspond to trunk as always
+1, Will move out the non Synapse specific transports into the new
module once the above project is created, and Axis2 moves out its http/s..
- I'm ok with going one step further and even moving the Axis2
transport APIs into the project and for Axis2 to just use them. This
is like what Axis2 does with Axiom for example.
I maybe wrong.. but I don't see this as required or gives us additional
benefits..
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
