Hey Sanjiva:
Sanjiva Weerawarana wrote:
- 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.
+1
And while we're at it (separate conversation though), perhaps transports
should be deployable as easily as services/modules...
conf/
modules/
services/
transports/
nhttp.tsp
jms.tsp
...with transport.xml inside *.tsp/META-INF
- 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 ;-).
Sounds like a plan. :)
See http://markmail.org/message/huukx25f3vgpethi - you might not have
seen that due to the lack of [axis2] prefix.
- 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.
New mailing lists, then? (oh joy more folders :)) I could be ok with
this, but I think using commons is simpler.
- we kill the old NHTTP and JMS tranports in axis2
Dims is already on this.
- move JMS and SMTP out of synapse into the new project
+1. We should look at which if any of the Synapse transports are not
generally applicable outside the Synapse context, and move all the others.
- 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
I'd tweak that - as a general rule, if the transport is generally useful
to both projects, it should live here to make sure it gets tested in
both contexts.
- for other transports we strongly encourage people to put them here
to enable easier wider use (e.g., WSO2 Mashup Server would inherit all
the transports in Axis2 but not those from Synapse .. I think Asankha
would want the new and improved SMTP transport to be in the WSO2 Mashup
Server too ;-)). Of course we can't enforce that but I would hope that
we should be able to come to a sufficient community understanding
between the Synapse and WS TLPs to make that work.
+1
- 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
Need to think about that a bit.
- 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.
+1, yup.
The result is that the transports become an enabler for Axis2 (and
Synapse and more) just as much as Axiom or XMLSchema is. The benefit is
that they're no longer "Axis2's transports" or "Synapse's transports"
but rather "those common transports". (I have to admit I didn't look at
the code to evaluate the realisticness of this bit of the proposal - but
the rest of it stands on its own anyway.)
Well, they ARE still Axis2 transports in that they exist to extend Axis2
- they're just in a common place so other users of Axis2 (Synapse in
particular) can share them easier. Aside from the issues around
perception, I think it would make just as much sense to have them under
axis2/ (assuming we could release them separately, etc). No, I'm not
proposing that. :)
Thanks,
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
