Releasing transports 1.0 - dependency resolutions

[Glen Daniels <gl...@thoughtcraft.com>]

Hi folks:

So I'm trying to get the transports 1.0 releases moving along, and have run
into a bit of a snag.  The transports depend on axis2-kernel SNAPSHOT, for
interfaces like MessageContext, Flow, etc. - the problem is how do we do the
release when we want to release the transports before the actual Axis2
release?  We need to resolve all the SNAPSHOT dependencies for the Maven
release plugin to be happy, and for this case, we seem to have a circular
dependency chain. :(

A couple of options off the top of my head:

* Release transports against Axis2 1.4.1's kernel - this may not even be
possible as there may have been incompatible changes.

* Do a Maven-only release of Axis2-kernel 1.5 - i.e. NOT a distribution but
just a release into Maven.  Then use that for the Transports 1.0 releases,
and then release the Axis2 1.5 distribution after that.

Moving forward, anyone have thoughts on how to best deal with this?  One of
these options, or something else?

Thanks,
--Glen

Re: Releasing transports 1.0 - dependency resolutions

[Dennis Sosnoski <dm...@sosnoski.com>]

Amila Suriarachchi wrote:
>
> Here the main idea was to share the same transports between Axis2 and 
> synapse. The idea of an axis2 transport is to use as an adapter 
> between axis2 and the actual transport (i.e http, smtp, JMS etc).  In 
> fact Axis2 transport uses respective libraries for these standard 
> transports and hence it is only scoped to use with Axis2.

Then what's the point of having transports as a separate project? The 
code should just be brought into Axis2. Synapse can use transports as 
part of Axis2 just as easily as if it were a separate project.

  - Dennis

Re: Releasing transports 1.0 - dependency resolutions

[Amila Suriarachchi <am...@gmail.com>]

On Tue, Mar 31, 2009 at 2:59 AM, Dennis Sosnoski <dm...@sosnoski.com> wrote:

> If transports is using these Axis2 interfaces I don't see the point of
> having it as a separate project. I thought the reason for moving transports
> outside of Axis2 was to allow it to be used for other purposes. How is that
> going to work if the code is assuming the Axis2 environment?


Here the main idea was to share the same transports between Axis2 and
synapse. The idea of an axis2 transport is to use as an adapter between
axis2 and the actual transport (i.e http, smtp, JMS etc).  In fact Axis2
transport uses respective libraries for these standard transports and hence
it is only scoped to use with Axis2.

thanks,
Amila.

>
>
> The only clean solution is to have transports define whatever interfaces it
> needs. The Axis2 versions can then extend the transports versions.
>
>  - Dennis
>
>
>
> Glen Daniels wrote:
>
>> Hi folks:
>>
>> So I'm trying to get the transports 1.0 releases moving along, and have
>> run
>> into a bit of a snag.  The transports depend on axis2-kernel SNAPSHOT, for
>> interfaces like MessageContext, Flow, etc. - the problem is how do we do
>> the
>> release when we want to release the transports before the actual Axis2
>> release?  We need to resolve all the SNAPSHOT dependencies for the Maven
>> release plugin to be happy, and for this case, we seem to have a circular
>> dependency chain. :(
>>
>> A couple of options off the top of my head:
>>
>> * Release transports against Axis2 1.4.1's kernel - this may not even be
>> possible as there may have been incompatible changes.
>>
>> * Do a Maven-only release of Axis2-kernel 1.5 - i.e. NOT a distribution
>> but
>> just a release into Maven.  Then use that for the Transports 1.0 releases,
>> and then release the Axis2 1.5 distribution after that.
>>
>> Moving forward, anyone have thoughts on how to best deal with this?  One
>> of
>> these options, or something else?
>>
>> Thanks,
>> --Glen
>>
>>
>>
>


-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Re: Releasing transports 1.0 - dependency resolutions

[Amila Suriarachchi <am...@gmail.com>]

On Tue, Mar 31, 2009 at 2:59 AM, Dennis Sosnoski <dm...@sosnoski.com> wrote:

> If transports is using these Axis2 interfaces I don't see the point of
> having it as a separate project. I thought the reason for moving transports
> outside of Axis2 was to allow it to be used for other purposes. How is that
> going to work if the code is assuming the Axis2 environment?


Here the main idea was to share the same transports between Axis2 and
synapse. The idea of an axis2 transport is to use as an adapter between
axis2 and the actual transport (i.e http, smtp, JMS etc).  In fact Axis2
transport uses respective libraries for these standard transports and hence
it is only scoped to use with Axis2.

thanks,
Amila.

>
>
> The only clean solution is to have transports define whatever interfaces it
> needs. The Axis2 versions can then extend the transports versions.
>
>  - Dennis
>
>
>
> Glen Daniels wrote:
>
>> Hi folks:
>>
>> So I'm trying to get the transports 1.0 releases moving along, and have
>> run
>> into a bit of a snag.  The transports depend on axis2-kernel SNAPSHOT, for
>> interfaces like MessageContext, Flow, etc. - the problem is how do we do
>> the
>> release when we want to release the transports before the actual Axis2
>> release?  We need to resolve all the SNAPSHOT dependencies for the Maven
>> release plugin to be happy, and for this case, we seem to have a circular
>> dependency chain. :(
>>
>> A couple of options off the top of my head:
>>
>> * Release transports against Axis2 1.4.1's kernel - this may not even be
>> possible as there may have been incompatible changes.
>>
>> * Do a Maven-only release of Axis2-kernel 1.5 - i.e. NOT a distribution
>> but
>> just a release into Maven.  Then use that for the Transports 1.0 releases,
>> and then release the Axis2 1.5 distribution after that.
>>
>> Moving forward, anyone have thoughts on how to best deal with this?  One
>> of
>> these options, or something else?
>>
>> Thanks,
>> --Glen
>>
>>
>>
>


-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Re: Releasing transports 1.0 - dependency resolutions

[Dennis Sosnoski <dm...@sosnoski.com>]

If transports is using these Axis2 interfaces I don't see the point of 
having it as a separate project. I thought the reason for moving 
transports outside of Axis2 was to allow it to be used for other 
purposes. How is that going to work if the code is assuming the Axis2 
environment?

The only clean solution is to have transports define whatever interfaces 
it needs. The Axis2 versions can then extend the transports versions.

  - Dennis


Glen Daniels wrote:
> Hi folks:
>
> So I'm trying to get the transports 1.0 releases moving along, and have run
> into a bit of a snag.  The transports depend on axis2-kernel SNAPSHOT, for
> interfaces like MessageContext, Flow, etc. - the problem is how do we do the
> release when we want to release the transports before the actual Axis2
> release?  We need to resolve all the SNAPSHOT dependencies for the Maven
> release plugin to be happy, and for this case, we seem to have a circular
> dependency chain. :(
>
> A couple of options off the top of my head:
>
> * Release transports against Axis2 1.4.1's kernel - this may not even be
> possible as there may have been incompatible changes.
>
> * Do a Maven-only release of Axis2-kernel 1.5 - i.e. NOT a distribution but
> just a release into Maven.  Then use that for the Transports 1.0 releases,
> and then release the Axis2 1.5 distribution after that.
>
> Moving forward, anyone have thoughts on how to best deal with this?  One of
> these options, or something else?
>
> Thanks,
> --Glen
>
>   

Re: Releasing transports 1.0 - dependency resolutions

[Andreas Veithen <an...@gmail.com>]

+1 for moving HTTP and local back to Axis2 and keeping all the others
in WS-Commons.

Note that one of the dependencies between HTTP and base is caused by
QueryStringParser and the intention was to move that class to Axis2
kernel anyway. The other is a utility method in BaseUtils that could
also be moved to kernel.

Andreas

On Tue, Mar 31, 2009 at 17:17, Asankha C. Perera <as...@apache.org> wrote:
> Jarek Gawor wrote:
>>
>> ...
>> What about tcp and local? Should we move it or leave it where it is?
>
> I do not see a reason to move it.. but moving local would be trivial too,
> like http
>>
>> Do Axis2 users expect local and/or tcp transports to be installed by
>> default?
>>
>
> I have not seen any Axis2 user using these transports.. Most users would use
> http only by default. Keeping them where they are allows anyone to easily
> use them by uncommenting the sections from the default axis2.xml
>
> cheers
> asankha
>
> --
> Asankha C. Perera
> AdroitLogic, http://adroitlogic.org
>
> http://esbmagic.blogspot.com
>
>
>
>
>

Re: Releasing transports 1.0 - dependency resolutions

["Asankha C. Perera" <as...@apache.org>]

Jarek Gawor wrote:
> ...
> What about tcp and local? Should we move it or leave it where it is? 
I do not see a reason to move it.. but moving local would be trivial 
too, like http
> Do Axis2 users expect local and/or tcp transports to be installed by default?
>   
I have not seen any Axis2 user using these transports.. Most users would 
use http only by default. Keeping them where they are allows anyone to 
easily use them by uncommenting the sections from the default axis2.xml

cheers
asankha

-- 
Asankha C. Perera
AdroitLogic, http://adroitlogic.org

http://esbmagic.blogspot.com

Re: Releasing transports 1.0 - dependency resolutions

[Jarek Gawor <jg...@gmail.com>]

Heh, ok.

Jarek

On Thu, Apr 2, 2009 at 12:07 PM, Andreas Veithen
<an...@gmail.com> wrote:
> Note that the tests applied to the (default Axis2) HTTP transport
> initially were not meant to test the transport but to validate the
> generic HTTP tests in the testkit. The purpose was to apply these
> generic tests to the NIO HTTP transport. This allows to compare the
> behavior of both transports. From that perspective we may leave the
> tests in the transports project ... as tests for the testkit :-)
>
> Andreas
>
> On Thu, Apr 2, 2009 at 17:08, Jarek Gawor <jg...@gmail.com> wrote:
>> On Wed, Apr 1, 2009 at 5:50 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
>>> Jarek Gawor wrote:
>>>>> Also, I'd really like to get 1.5 out the door ASAP, it's lingered way too
>>>>> long already.  So whatever solution gets us there soonest with consensus is
>>>>> the one I'll be happy with.
>>>>
>>>> Yes, I agree. Sounds like we already agree on a solution (moving http
>>>> and local back to Axis2).
>>>
>>> OK, I'm on this tomorrow.  If anyone has issues with it, please pipe up!
>>
>> I already moved some of the utility classes and methods back to Axis2
>> and eliminated a direct dependency on transport base from http and
>> local. But once I was actually looking into moving the http module to
>> Axis2 I realized the the http transport tests have dependency on the
>> testki module which has dependencies on the transport base module....
>> So we can easily move the transport http code itself but not the
>> tests... anybody have ideas how to deal with this now?
>>
>> Jarek
>>
>

Re: Releasing transports 1.0 - dependency resolutions

[Jarek Gawor <jg...@gmail.com>]

Heh, ok.

Jarek

On Thu, Apr 2, 2009 at 12:07 PM, Andreas Veithen
<an...@gmail.com> wrote:
> Note that the tests applied to the (default Axis2) HTTP transport
> initially were not meant to test the transport but to validate the
> generic HTTP tests in the testkit. The purpose was to apply these
> generic tests to the NIO HTTP transport. This allows to compare the
> behavior of both transports. From that perspective we may leave the
> tests in the transports project ... as tests for the testkit :-)
>
> Andreas
>
> On Thu, Apr 2, 2009 at 17:08, Jarek Gawor <jg...@gmail.com> wrote:
>> On Wed, Apr 1, 2009 at 5:50 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
>>> Jarek Gawor wrote:
>>>>> Also, I'd really like to get 1.5 out the door ASAP, it's lingered way too
>>>>> long already.  So whatever solution gets us there soonest with consensus is
>>>>> the one I'll be happy with.
>>>>
>>>> Yes, I agree. Sounds like we already agree on a solution (moving http
>>>> and local back to Axis2).
>>>
>>> OK, I'm on this tomorrow.  If anyone has issues with it, please pipe up!
>>
>> I already moved some of the utility classes and methods back to Axis2
>> and eliminated a direct dependency on transport base from http and
>> local. But once I was actually looking into moving the http module to
>> Axis2 I realized the the http transport tests have dependency on the
>> testki module which has dependencies on the transport base module....
>> So we can easily move the transport http code itself but not the
>> tests... anybody have ideas how to deal with this now?
>>
>> Jarek
>>
>

Re: Releasing transports 1.0 - dependency resolutions

[Amila Suriarachchi <am...@gmail.com>]

hi,

I tested the distribution (after adding http transport) with some samples
and it passes all the test cases. Earlier I had some test with the Sandesha2
security and rampart and worked fine.
So I think we can put an RC and release it there are no any critical issues.

thanks,
Amila.


On Mon, Apr 6, 2009 at 2:08 PM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:

>
>
> On Fri, Apr 3, 2009 at 10:45 PM, Jarek Gawor <jg...@gmail.com> wrote:
>
>> The local module and http module (source only) is now moved to Axis2.
>> Please give it a try and see if things look ok. If so, we'll merge it
>> to 1.5 branch.
>
>
> I ran some sample tests with a sanpshot release and it worked fine.
> (tested with both simple http server and war under tomcat)
> So we can move it to branch and remove the transport dependency.
>
>
>>
>> I kept the http module in the Transport project but I had to change
>> the artifact name to prevent a conflict with the Axis2 http transport
>> module. Btw, I think that the Transport project should have its own
>> group id (e.g org.apache.axis2.transport instead of org.apache.axis2).
>
>
> but anyway we are going to remove the http and local transports from the
> commons transport module isn't it?
>
> IMHO also transport module should have a different group id and a package
> structure.
>
> thanks,
> Amila.
>
>>
>> The Transport http module only has the tests now. If we could refactor
>> the tests somehow that would be great but I guess it's not critical
>> for 1.5.
>>
>> Thanks,
>> Jarek
>>
>> On Thu, Apr 2, 2009 at 5:15 PM, Glen Daniels <gl...@thoughtcraft.com>
>> wrote:
>> > Hi folks:
>> >
>> > First, many thanks to Jarek for getting the transport move going - I got
>> > sucked into other stuff today and probably won't be able to dive back in
>> for
>> > real until Sunday.  Just talked to Jarek on IRC and he's hoping to
>> finish the
>> > move tonight or tomorrow.
>> >
>> > That said.... I'm not very happy about the idea of leaving important
>> tests in
>> > the WS-Commons area if the code they're testing is actually in Axis2.
>>  This
>> > smells of bad refactoring and future confusion.
>> >
>> > I want to get Axis2 1.5 out ASAP, and am willing to do whatever gets us
>> there
>> > quickest, but after that I'd like to have another discussion about how
>> to
>> > correctly host and factor the transports code.  This should dovetail
>> nicely
>> > with another round of the "Splitting WS" conversation, which I'd like to
>> have
>> > at the same time.
>> >
>> > Thanks,
>> > --Glen
>> >
>> > Andreas Veithen wrote:
>> >> Note that the tests applied to the (default Axis2) HTTP transport
>> >> initially were not meant to test the transport but to validate the
>> >> generic HTTP tests in the testkit. The purpose was to apply these
>> >> generic tests to the NIO HTTP transport. This allows to compare the
>> >> behavior of both transports. From that perspective we may leave the
>> >> tests in the transports project ... as tests for the testkit :-)
>> >>
>> >> Andreas
>> >>
>> >> On Thu, Apr 2, 2009 at 17:08, Jarek Gawor <jg...@gmail.com> wrote:
>> >>> On Wed, Apr 1, 2009 at 5:50 PM, Glen Daniels <gl...@thoughtcraft.com>
>> wrote:
>> >>>> Jarek Gawor wrote:
>> >>>>>> Also, I'd really like to get 1.5 out the door ASAP, it's lingered
>> way too
>> >>>>>> long already.  So whatever solution gets us there soonest with
>> consensus is
>> >>>>>> the one I'll be happy with.
>> >>>>> Yes, I agree. Sounds like we already agree on a solution (moving
>> http
>> >>>>> and local back to Axis2).
>> >>>> OK, I'm on this tomorrow.  If anyone has issues with it, please pipe
>> up!
>> >>> I already moved some of the utility classes and methods back to Axis2
>> >>> and eliminated a direct dependency on transport base from http and
>> >>> local. But once I was actually looking into moving the http module to
>> >>> Axis2 I realized the the http transport tests have dependency on the
>> >>> testki module which has dependencies on the transport base module....
>> >>> So we can easily move the transport http code itself but not the
>> >>> tests... anybody have ideas how to deal with this now?
>> >>>
>> >>> Jarek
>> >>>
>> >
>>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Re: Releasing transports 1.0 - dependency resolutions

[Amila Suriarachchi <am...@gmail.com>]

hi,

I tested the distribution (after adding http transport) with some samples
and it passes all the test cases. Earlier I had some test with the Sandesha2
security and rampart and worked fine.
So I think we can put an RC and release it there are no any critical issues.

thanks,
Amila.


On Mon, Apr 6, 2009 at 2:08 PM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:

>
>
> On Fri, Apr 3, 2009 at 10:45 PM, Jarek Gawor <jg...@gmail.com> wrote:
>
>> The local module and http module (source only) is now moved to Axis2.
>> Please give it a try and see if things look ok. If so, we'll merge it
>> to 1.5 branch.
>
>
> I ran some sample tests with a sanpshot release and it worked fine.
> (tested with both simple http server and war under tomcat)
> So we can move it to branch and remove the transport dependency.
>
>
>>
>> I kept the http module in the Transport project but I had to change
>> the artifact name to prevent a conflict with the Axis2 http transport
>> module. Btw, I think that the Transport project should have its own
>> group id (e.g org.apache.axis2.transport instead of org.apache.axis2).
>
>
> but anyway we are going to remove the http and local transports from the
> commons transport module isn't it?
>
> IMHO also transport module should have a different group id and a package
> structure.
>
> thanks,
> Amila.
>
>>
>> The Transport http module only has the tests now. If we could refactor
>> the tests somehow that would be great but I guess it's not critical
>> for 1.5.
>>
>> Thanks,
>> Jarek
>>
>> On Thu, Apr 2, 2009 at 5:15 PM, Glen Daniels <gl...@thoughtcraft.com>
>> wrote:
>> > Hi folks:
>> >
>> > First, many thanks to Jarek for getting the transport move going - I got
>> > sucked into other stuff today and probably won't be able to dive back in
>> for
>> > real until Sunday.  Just talked to Jarek on IRC and he's hoping to
>> finish the
>> > move tonight or tomorrow.
>> >
>> > That said.... I'm not very happy about the idea of leaving important
>> tests in
>> > the WS-Commons area if the code they're testing is actually in Axis2.
>>  This
>> > smells of bad refactoring and future confusion.
>> >
>> > I want to get Axis2 1.5 out ASAP, and am willing to do whatever gets us
>> there
>> > quickest, but after that I'd like to have another discussion about how
>> to
>> > correctly host and factor the transports code.  This should dovetail
>> nicely
>> > with another round of the "Splitting WS" conversation, which I'd like to
>> have
>> > at the same time.
>> >
>> > Thanks,
>> > --Glen
>> >
>> > Andreas Veithen wrote:
>> >> Note that the tests applied to the (default Axis2) HTTP transport
>> >> initially were not meant to test the transport but to validate the
>> >> generic HTTP tests in the testkit. The purpose was to apply these
>> >> generic tests to the NIO HTTP transport. This allows to compare the
>> >> behavior of both transports. From that perspective we may leave the
>> >> tests in the transports project ... as tests for the testkit :-)
>> >>
>> >> Andreas
>> >>
>> >> On Thu, Apr 2, 2009 at 17:08, Jarek Gawor <jg...@gmail.com> wrote:
>> >>> On Wed, Apr 1, 2009 at 5:50 PM, Glen Daniels <gl...@thoughtcraft.com>
>> wrote:
>> >>>> Jarek Gawor wrote:
>> >>>>>> Also, I'd really like to get 1.5 out the door ASAP, it's lingered
>> way too
>> >>>>>> long already.  So whatever solution gets us there soonest with
>> consensus is
>> >>>>>> the one I'll be happy with.
>> >>>>> Yes, I agree. Sounds like we already agree on a solution (moving
>> http
>> >>>>> and local back to Axis2).
>> >>>> OK, I'm on this tomorrow.  If anyone has issues with it, please pipe
>> up!
>> >>> I already moved some of the utility classes and methods back to Axis2
>> >>> and eliminated a direct dependency on transport base from http and
>> >>> local. But once I was actually looking into moving the http module to
>> >>> Axis2 I realized the the http transport tests have dependency on the
>> >>> testki module which has dependencies on the transport base module....
>> >>> So we can easily move the transport http code itself but not the
>> >>> tests... anybody have ideas how to deal with this now?
>> >>>
>> >>> Jarek
>> >>>
>> >
>>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Re: Releasing transports 1.0 - dependency resolutions

[Amila Suriarachchi <am...@gmail.com>]

On Fri, Apr 3, 2009 at 10:45 PM, Jarek Gawor <jg...@gmail.com> wrote:

> The local module and http module (source only) is now moved to Axis2.
> Please give it a try and see if things look ok. If so, we'll merge it
> to 1.5 branch.


I ran some sample tests with a sanpshot release and it worked fine.
(tested with both simple http server and war under tomcat)
So we can move it to branch and remove the transport dependency.


>
> I kept the http module in the Transport project but I had to change
> the artifact name to prevent a conflict with the Axis2 http transport
> module. Btw, I think that the Transport project should have its own
> group id (e.g org.apache.axis2.transport instead of org.apache.axis2).


but anyway we are going to remove the http and local transports from the
commons transport module isn't it?

IMHO also transport module should have a different group id and a package
structure.

thanks,
Amila.

>
> The Transport http module only has the tests now. If we could refactor
> the tests somehow that would be great but I guess it's not critical
> for 1.5.
>
> Thanks,
> Jarek
>
> On Thu, Apr 2, 2009 at 5:15 PM, Glen Daniels <gl...@thoughtcraft.com>
> wrote:
> > Hi folks:
> >
> > First, many thanks to Jarek for getting the transport move going - I got
> > sucked into other stuff today and probably won't be able to dive back in
> for
> > real until Sunday.  Just talked to Jarek on IRC and he's hoping to finish
> the
> > move tonight or tomorrow.
> >
> > That said.... I'm not very happy about the idea of leaving important
> tests in
> > the WS-Commons area if the code they're testing is actually in Axis2.
>  This
> > smells of bad refactoring and future confusion.
> >
> > I want to get Axis2 1.5 out ASAP, and am willing to do whatever gets us
> there
> > quickest, but after that I'd like to have another discussion about how to
> > correctly host and factor the transports code.  This should dovetail
> nicely
> > with another round of the "Splitting WS" conversation, which I'd like to
> have
> > at the same time.
> >
> > Thanks,
> > --Glen
> >
> > Andreas Veithen wrote:
> >> Note that the tests applied to the (default Axis2) HTTP transport
> >> initially were not meant to test the transport but to validate the
> >> generic HTTP tests in the testkit. The purpose was to apply these
> >> generic tests to the NIO HTTP transport. This allows to compare the
> >> behavior of both transports. From that perspective we may leave the
> >> tests in the transports project ... as tests for the testkit :-)
> >>
> >> Andreas
> >>
> >> On Thu, Apr 2, 2009 at 17:08, Jarek Gawor <jg...@gmail.com> wrote:
> >>> On Wed, Apr 1, 2009 at 5:50 PM, Glen Daniels <gl...@thoughtcraft.com>
> wrote:
> >>>> Jarek Gawor wrote:
> >>>>>> Also, I'd really like to get 1.5 out the door ASAP, it's lingered
> way too
> >>>>>> long already.  So whatever solution gets us there soonest with
> consensus is
> >>>>>> the one I'll be happy with.
> >>>>> Yes, I agree. Sounds like we already agree on a solution (moving http
> >>>>> and local back to Axis2).
> >>>> OK, I'm on this tomorrow.  If anyone has issues with it, please pipe
> up!
> >>> I already moved some of the utility classes and methods back to Axis2
> >>> and eliminated a direct dependency on transport base from http and
> >>> local. But once I was actually looking into moving the http module to
> >>> Axis2 I realized the the http transport tests have dependency on the
> >>> testki module which has dependencies on the transport base module....
> >>> So we can easily move the transport http code itself but not the
> >>> tests... anybody have ideas how to deal with this now?
> >>>
> >>> Jarek
> >>>
> >
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Re: Releasing transports 1.0 - dependency resolutions

[Amila Suriarachchi <am...@gmail.com>]

On Fri, Apr 3, 2009 at 10:45 PM, Jarek Gawor <jg...@gmail.com> wrote:

> The local module and http module (source only) is now moved to Axis2.
> Please give it a try and see if things look ok. If so, we'll merge it
> to 1.5 branch.


I ran some sample tests with a sanpshot release and it worked fine.
(tested with both simple http server and war under tomcat)
So we can move it to branch and remove the transport dependency.


>
> I kept the http module in the Transport project but I had to change
> the artifact name to prevent a conflict with the Axis2 http transport
> module. Btw, I think that the Transport project should have its own
> group id (e.g org.apache.axis2.transport instead of org.apache.axis2).


but anyway we are going to remove the http and local transports from the
commons transport module isn't it?

IMHO also transport module should have a different group id and a package
structure.

thanks,
Amila.

>
> The Transport http module only has the tests now. If we could refactor
> the tests somehow that would be great but I guess it's not critical
> for 1.5.
>
> Thanks,
> Jarek
>
> On Thu, Apr 2, 2009 at 5:15 PM, Glen Daniels <gl...@thoughtcraft.com>
> wrote:
> > Hi folks:
> >
> > First, many thanks to Jarek for getting the transport move going - I got
> > sucked into other stuff today and probably won't be able to dive back in
> for
> > real until Sunday.  Just talked to Jarek on IRC and he's hoping to finish
> the
> > move tonight or tomorrow.
> >
> > That said.... I'm not very happy about the idea of leaving important
> tests in
> > the WS-Commons area if the code they're testing is actually in Axis2.
>  This
> > smells of bad refactoring and future confusion.
> >
> > I want to get Axis2 1.5 out ASAP, and am willing to do whatever gets us
> there
> > quickest, but after that I'd like to have another discussion about how to
> > correctly host and factor the transports code.  This should dovetail
> nicely
> > with another round of the "Splitting WS" conversation, which I'd like to
> have
> > at the same time.
> >
> > Thanks,
> > --Glen
> >
> > Andreas Veithen wrote:
> >> Note that the tests applied to the (default Axis2) HTTP transport
> >> initially were not meant to test the transport but to validate the
> >> generic HTTP tests in the testkit. The purpose was to apply these
> >> generic tests to the NIO HTTP transport. This allows to compare the
> >> behavior of both transports. From that perspective we may leave the
> >> tests in the transports project ... as tests for the testkit :-)
> >>
> >> Andreas
> >>
> >> On Thu, Apr 2, 2009 at 17:08, Jarek Gawor <jg...@gmail.com> wrote:
> >>> On Wed, Apr 1, 2009 at 5:50 PM, Glen Daniels <gl...@thoughtcraft.com>
> wrote:
> >>>> Jarek Gawor wrote:
> >>>>>> Also, I'd really like to get 1.5 out the door ASAP, it's lingered
> way too
> >>>>>> long already.  So whatever solution gets us there soonest with
> consensus is
> >>>>>> the one I'll be happy with.
> >>>>> Yes, I agree. Sounds like we already agree on a solution (moving http
> >>>>> and local back to Axis2).
> >>>> OK, I'm on this tomorrow.  If anyone has issues with it, please pipe
> up!
> >>> I already moved some of the utility classes and methods back to Axis2
> >>> and eliminated a direct dependency on transport base from http and
> >>> local. But once I was actually looking into moving the http module to
> >>> Axis2 I realized the the http transport tests have dependency on the
> >>> testki module which has dependencies on the transport base module....
> >>> So we can easily move the transport http code itself but not the
> >>> tests... anybody have ideas how to deal with this now?
> >>>
> >>> Jarek
> >>>
> >
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Re: Releasing transports 1.0 - dependency resolutions

[Jarek Gawor <jg...@gmail.com>]

The local module and http module (source only) is now moved to Axis2.
Please give it a try and see if things look ok. If so, we'll merge it
to 1.5 branch.

I kept the http module in the Transport project but I had to change
the artifact name to prevent a conflict with the Axis2 http transport
module. Btw, I think that the Transport project should have its own
group id (e.g org.apache.axis2.transport instead of org.apache.axis2).
The Transport http module only has the tests now. If we could refactor
the tests somehow that would be great but I guess it's not critical
for 1.5.

Thanks,
Jarek

On Thu, Apr 2, 2009 at 5:15 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi folks:
>
> First, many thanks to Jarek for getting the transport move going - I got
> sucked into other stuff today and probably won't be able to dive back in for
> real until Sunday.  Just talked to Jarek on IRC and he's hoping to finish the
> move tonight or tomorrow.
>
> That said.... I'm not very happy about the idea of leaving important tests in
> the WS-Commons area if the code they're testing is actually in Axis2.  This
> smells of bad refactoring and future confusion.
>
> I want to get Axis2 1.5 out ASAP, and am willing to do whatever gets us there
> quickest, but after that I'd like to have another discussion about how to
> correctly host and factor the transports code.  This should dovetail nicely
> with another round of the "Splitting WS" conversation, which I'd like to have
> at the same time.
>
> Thanks,
> --Glen
>
> Andreas Veithen wrote:
>> Note that the tests applied to the (default Axis2) HTTP transport
>> initially were not meant to test the transport but to validate the
>> generic HTTP tests in the testkit. The purpose was to apply these
>> generic tests to the NIO HTTP transport. This allows to compare the
>> behavior of both transports. From that perspective we may leave the
>> tests in the transports project ... as tests for the testkit :-)
>>
>> Andreas
>>
>> On Thu, Apr 2, 2009 at 17:08, Jarek Gawor <jg...@gmail.com> wrote:
>>> On Wed, Apr 1, 2009 at 5:50 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
>>>> Jarek Gawor wrote:
>>>>>> Also, I'd really like to get 1.5 out the door ASAP, it's lingered way too
>>>>>> long already.  So whatever solution gets us there soonest with consensus is
>>>>>> the one I'll be happy with.
>>>>> Yes, I agree. Sounds like we already agree on a solution (moving http
>>>>> and local back to Axis2).
>>>> OK, I'm on this tomorrow.  If anyone has issues with it, please pipe up!
>>> I already moved some of the utility classes and methods back to Axis2
>>> and eliminated a direct dependency on transport base from http and
>>> local. But once I was actually looking into moving the http module to
>>> Axis2 I realized the the http transport tests have dependency on the
>>> testki module which has dependencies on the transport base module....
>>> So we can easily move the transport http code itself but not the
>>> tests... anybody have ideas how to deal with this now?
>>>
>>> Jarek
>>>
>

Re: Releasing transports 1.0 - dependency resolutions

[Jarek Gawor <jg...@gmail.com>]

The local module and http module (source only) is now moved to Axis2.
Please give it a try and see if things look ok. If so, we'll merge it
to 1.5 branch.

I kept the http module in the Transport project but I had to change
the artifact name to prevent a conflict with the Axis2 http transport
module. Btw, I think that the Transport project should have its own
group id (e.g org.apache.axis2.transport instead of org.apache.axis2).
The Transport http module only has the tests now. If we could refactor
the tests somehow that would be great but I guess it's not critical
for 1.5.

Thanks,
Jarek

On Thu, Apr 2, 2009 at 5:15 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi folks:
>
> First, many thanks to Jarek for getting the transport move going - I got
> sucked into other stuff today and probably won't be able to dive back in for
> real until Sunday.  Just talked to Jarek on IRC and he's hoping to finish the
> move tonight or tomorrow.
>
> That said.... I'm not very happy about the idea of leaving important tests in
> the WS-Commons area if the code they're testing is actually in Axis2.  This
> smells of bad refactoring and future confusion.
>
> I want to get Axis2 1.5 out ASAP, and am willing to do whatever gets us there
> quickest, but after that I'd like to have another discussion about how to
> correctly host and factor the transports code.  This should dovetail nicely
> with another round of the "Splitting WS" conversation, which I'd like to have
> at the same time.
>
> Thanks,
> --Glen
>
> Andreas Veithen wrote:
>> Note that the tests applied to the (default Axis2) HTTP transport
>> initially were not meant to test the transport but to validate the
>> generic HTTP tests in the testkit. The purpose was to apply these
>> generic tests to the NIO HTTP transport. This allows to compare the
>> behavior of both transports. From that perspective we may leave the
>> tests in the transports project ... as tests for the testkit :-)
>>
>> Andreas
>>
>> On Thu, Apr 2, 2009 at 17:08, Jarek Gawor <jg...@gmail.com> wrote:
>>> On Wed, Apr 1, 2009 at 5:50 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
>>>> Jarek Gawor wrote:
>>>>>> Also, I'd really like to get 1.5 out the door ASAP, it's lingered way too
>>>>>> long already.  So whatever solution gets us there soonest with consensus is
>>>>>> the one I'll be happy with.
>>>>> Yes, I agree. Sounds like we already agree on a solution (moving http
>>>>> and local back to Axis2).
>>>> OK, I'm on this tomorrow.  If anyone has issues with it, please pipe up!
>>> I already moved some of the utility classes and methods back to Axis2
>>> and eliminated a direct dependency on transport base from http and
>>> local. But once I was actually looking into moving the http module to
>>> Axis2 I realized the the http transport tests have dependency on the
>>> testki module which has dependencies on the transport base module....
>>> So we can easily move the transport http code itself but not the
>>> tests... anybody have ideas how to deal with this now?
>>>
>>> Jarek
>>>
>

Re: Releasing transports 1.0 - dependency resolutions

[Andreas Veithen <an...@gmail.com>]

I see two things that need to be done to solve the testkit->base
dependency issue:

* Move the message builders and formatters that are located in base to
axis2-kernel. That was already discussed back in December, but at that
time we decided to do a complete review of the whole builder/formatter
stuff after the 1.5 release (which we thought was imminent at that
time...)

* Promote some of the extension interfaces (for transports; e.g.
management) defined by base to axis2-kernel. This should be considered
in a larger context of reviewing the whole transport API (i.e. improve
the documentation so that it becomes a specification).

I think technically it's not difficult to achieve, but we have to
postpone this if we want to get 1.5 out.

Andreas

On Thu, Apr 2, 2009 at 23:15, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi folks:
>
> First, many thanks to Jarek for getting the transport move going - I got
> sucked into other stuff today and probably won't be able to dive back in for
> real until Sunday.  Just talked to Jarek on IRC and he's hoping to finish the
> move tonight or tomorrow.
>
> That said.... I'm not very happy about the idea of leaving important tests in
> the WS-Commons area if the code they're testing is actually in Axis2.  This
> smells of bad refactoring and future confusion.
>
> I want to get Axis2 1.5 out ASAP, and am willing to do whatever gets us there
> quickest, but after that I'd like to have another discussion about how to
> correctly host and factor the transports code.  This should dovetail nicely
> with another round of the "Splitting WS" conversation, which I'd like to have
> at the same time.
>
> Thanks,
> --Glen
>
> Andreas Veithen wrote:
>> Note that the tests applied to the (default Axis2) HTTP transport
>> initially were not meant to test the transport but to validate the
>> generic HTTP tests in the testkit. The purpose was to apply these
>> generic tests to the NIO HTTP transport. This allows to compare the
>> behavior of both transports. From that perspective we may leave the
>> tests in the transports project ... as tests for the testkit :-)
>>
>> Andreas
>>
>> On Thu, Apr 2, 2009 at 17:08, Jarek Gawor <jg...@gmail.com> wrote:
>>> On Wed, Apr 1, 2009 at 5:50 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
>>>> Jarek Gawor wrote:
>>>>>> Also, I'd really like to get 1.5 out the door ASAP, it's lingered way too
>>>>>> long already.  So whatever solution gets us there soonest with consensus is
>>>>>> the one I'll be happy with.
>>>>> Yes, I agree. Sounds like we already agree on a solution (moving http
>>>>> and local back to Axis2).
>>>> OK, I'm on this tomorrow.  If anyone has issues with it, please pipe up!
>>> I already moved some of the utility classes and methods back to Axis2
>>> and eliminated a direct dependency on transport base from http and
>>> local. But once I was actually looking into moving the http module to
>>> Axis2 I realized the the http transport tests have dependency on the
>>> testki module which has dependencies on the transport base module....
>>> So we can easily move the transport http code itself but not the
>>> tests... anybody have ideas how to deal with this now?
>>>
>>> Jarek
>>>
>

Re: Releasing transports 1.0 - dependency resolutions

[Andreas Veithen <an...@gmail.com>]

I see two things that need to be done to solve the testkit->base
dependency issue:

* Move the message builders and formatters that are located in base to
axis2-kernel. That was already discussed back in December, but at that
time we decided to do a complete review of the whole builder/formatter
stuff after the 1.5 release (which we thought was imminent at that
time...)

* Promote some of the extension interfaces (for transports; e.g.
management) defined by base to axis2-kernel. This should be considered
in a larger context of reviewing the whole transport API (i.e. improve
the documentation so that it becomes a specification).

I think technically it's not difficult to achieve, but we have to
postpone this if we want to get 1.5 out.

Andreas

On Thu, Apr 2, 2009 at 23:15, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi folks:
>
> First, many thanks to Jarek for getting the transport move going - I got
> sucked into other stuff today and probably won't be able to dive back in for
> real until Sunday.  Just talked to Jarek on IRC and he's hoping to finish the
> move tonight or tomorrow.
>
> That said.... I'm not very happy about the idea of leaving important tests in
> the WS-Commons area if the code they're testing is actually in Axis2.  This
> smells of bad refactoring and future confusion.
>
> I want to get Axis2 1.5 out ASAP, and am willing to do whatever gets us there
> quickest, but after that I'd like to have another discussion about how to
> correctly host and factor the transports code.  This should dovetail nicely
> with another round of the "Splitting WS" conversation, which I'd like to have
> at the same time.
>
> Thanks,
> --Glen
>
> Andreas Veithen wrote:
>> Note that the tests applied to the (default Axis2) HTTP transport
>> initially were not meant to test the transport but to validate the
>> generic HTTP tests in the testkit. The purpose was to apply these
>> generic tests to the NIO HTTP transport. This allows to compare the
>> behavior of both transports. From that perspective we may leave the
>> tests in the transports project ... as tests for the testkit :-)
>>
>> Andreas
>>
>> On Thu, Apr 2, 2009 at 17:08, Jarek Gawor <jg...@gmail.com> wrote:
>>> On Wed, Apr 1, 2009 at 5:50 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
>>>> Jarek Gawor wrote:
>>>>>> Also, I'd really like to get 1.5 out the door ASAP, it's lingered way too
>>>>>> long already.  So whatever solution gets us there soonest with consensus is
>>>>>> the one I'll be happy with.
>>>>> Yes, I agree. Sounds like we already agree on a solution (moving http
>>>>> and local back to Axis2).
>>>> OK, I'm on this tomorrow.  If anyone has issues with it, please pipe up!
>>> I already moved some of the utility classes and methods back to Axis2
>>> and eliminated a direct dependency on transport base from http and
>>> local. But once I was actually looking into moving the http module to
>>> Axis2 I realized the the http transport tests have dependency on the
>>> testki module which has dependencies on the transport base module....
>>> So we can easily move the transport http code itself but not the
>>> tests... anybody have ideas how to deal with this now?
>>>
>>> Jarek
>>>
>

Re: Releasing transports 1.0 - dependency resolutions

[Glen Daniels <gl...@thoughtcraft.com>]

Hi folks:

First, many thanks to Jarek for getting the transport move going - I got
sucked into other stuff today and probably won't be able to dive back in for
real until Sunday.  Just talked to Jarek on IRC and he's hoping to finish the
move tonight or tomorrow.

That said.... I'm not very happy about the idea of leaving important tests in
the WS-Commons area if the code they're testing is actually in Axis2.  This
smells of bad refactoring and future confusion.

I want to get Axis2 1.5 out ASAP, and am willing to do whatever gets us there
quickest, but after that I'd like to have another discussion about how to
correctly host and factor the transports code.  This should dovetail nicely
with another round of the "Splitting WS" conversation, which I'd like to have
at the same time.

Thanks,
--Glen

Andreas Veithen wrote:
> Note that the tests applied to the (default Axis2) HTTP transport
> initially were not meant to test the transport but to validate the
> generic HTTP tests in the testkit. The purpose was to apply these
> generic tests to the NIO HTTP transport. This allows to compare the
> behavior of both transports. From that perspective we may leave the
> tests in the transports project ... as tests for the testkit :-)
> 
> Andreas
> 
> On Thu, Apr 2, 2009 at 17:08, Jarek Gawor <jg...@gmail.com> wrote:
>> On Wed, Apr 1, 2009 at 5:50 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
>>> Jarek Gawor wrote:
>>>>> Also, I'd really like to get 1.5 out the door ASAP, it's lingered way too
>>>>> long already.  So whatever solution gets us there soonest with consensus is
>>>>> the one I'll be happy with.
>>>> Yes, I agree. Sounds like we already agree on a solution (moving http
>>>> and local back to Axis2).
>>> OK, I'm on this tomorrow.  If anyone has issues with it, please pipe up!
>> I already moved some of the utility classes and methods back to Axis2
>> and eliminated a direct dependency on transport base from http and
>> local. But once I was actually looking into moving the http module to
>> Axis2 I realized the the http transport tests have dependency on the
>> testki module which has dependencies on the transport base module....
>> So we can easily move the transport http code itself but not the
>> tests... anybody have ideas how to deal with this now?
>>
>> Jarek
>>

Re: Releasing transports 1.0 - dependency resolutions

[Glen Daniels <gl...@thoughtcraft.com>]

Hi folks:

First, many thanks to Jarek for getting the transport move going - I got
sucked into other stuff today and probably won't be able to dive back in for
real until Sunday.  Just talked to Jarek on IRC and he's hoping to finish the
move tonight or tomorrow.

That said.... I'm not very happy about the idea of leaving important tests in
the WS-Commons area if the code they're testing is actually in Axis2.  This
smells of bad refactoring and future confusion.

I want to get Axis2 1.5 out ASAP, and am willing to do whatever gets us there
quickest, but after that I'd like to have another discussion about how to
correctly host and factor the transports code.  This should dovetail nicely
with another round of the "Splitting WS" conversation, which I'd like to have
at the same time.

Thanks,
--Glen

Andreas Veithen wrote:
> Note that the tests applied to the (default Axis2) HTTP transport
> initially were not meant to test the transport but to validate the
> generic HTTP tests in the testkit. The purpose was to apply these
> generic tests to the NIO HTTP transport. This allows to compare the
> behavior of both transports. From that perspective we may leave the
> tests in the transports project ... as tests for the testkit :-)
> 
> Andreas
> 
> On Thu, Apr 2, 2009 at 17:08, Jarek Gawor <jg...@gmail.com> wrote:
>> On Wed, Apr 1, 2009 at 5:50 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
>>> Jarek Gawor wrote:
>>>>> Also, I'd really like to get 1.5 out the door ASAP, it's lingered way too
>>>>> long already.  So whatever solution gets us there soonest with consensus is
>>>>> the one I'll be happy with.
>>>> Yes, I agree. Sounds like we already agree on a solution (moving http
>>>> and local back to Axis2).
>>> OK, I'm on this tomorrow.  If anyone has issues with it, please pipe up!
>> I already moved some of the utility classes and methods back to Axis2
>> and eliminated a direct dependency on transport base from http and
>> local. But once I was actually looking into moving the http module to
>> Axis2 I realized the the http transport tests have dependency on the
>> testki module which has dependencies on the transport base module....
>> So we can easily move the transport http code itself but not the
>> tests... anybody have ideas how to deal with this now?
>>
>> Jarek
>>

Re: Releasing transports 1.0 - dependency resolutions

[Andreas Veithen <an...@gmail.com>]

Note that the tests applied to the (default Axis2) HTTP transport
initially were not meant to test the transport but to validate the
generic HTTP tests in the testkit. The purpose was to apply these
generic tests to the NIO HTTP transport. This allows to compare the
behavior of both transports. From that perspective we may leave the
tests in the transports project ... as tests for the testkit :-)

Andreas

On Thu, Apr 2, 2009 at 17:08, Jarek Gawor <jg...@gmail.com> wrote:
> On Wed, Apr 1, 2009 at 5:50 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
>> Jarek Gawor wrote:
>>>> Also, I'd really like to get 1.5 out the door ASAP, it's lingered way too
>>>> long already.  So whatever solution gets us there soonest with consensus is
>>>> the one I'll be happy with.
>>>
>>> Yes, I agree. Sounds like we already agree on a solution (moving http
>>> and local back to Axis2).
>>
>> OK, I'm on this tomorrow.  If anyone has issues with it, please pipe up!
>
> I already moved some of the utility classes and methods back to Axis2
> and eliminated a direct dependency on transport base from http and
> local. But once I was actually looking into moving the http module to
> Axis2 I realized the the http transport tests have dependency on the
> testki module which has dependencies on the transport base module....
> So we can easily move the transport http code itself but not the
> tests... anybody have ideas how to deal with this now?
>
> Jarek
>

Re: Releasing transports 1.0 - dependency resolutions

[Andreas Veithen <an...@gmail.com>]

Note that the tests applied to the (default Axis2) HTTP transport
initially were not meant to test the transport but to validate the
generic HTTP tests in the testkit. The purpose was to apply these
generic tests to the NIO HTTP transport. This allows to compare the
behavior of both transports. From that perspective we may leave the
tests in the transports project ... as tests for the testkit :-)

Andreas

On Thu, Apr 2, 2009 at 17:08, Jarek Gawor <jg...@gmail.com> wrote:
> On Wed, Apr 1, 2009 at 5:50 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
>> Jarek Gawor wrote:
>>>> Also, I'd really like to get 1.5 out the door ASAP, it's lingered way too
>>>> long already.  So whatever solution gets us there soonest with consensus is
>>>> the one I'll be happy with.
>>>
>>> Yes, I agree. Sounds like we already agree on a solution (moving http
>>> and local back to Axis2).
>>
>> OK, I'm on this tomorrow.  If anyone has issues with it, please pipe up!
>
> I already moved some of the utility classes and methods back to Axis2
> and eliminated a direct dependency on transport base from http and
> local. But once I was actually looking into moving the http module to
> Axis2 I realized the the http transport tests have dependency on the
> testki module which has dependencies on the transport base module....
> So we can easily move the transport http code itself but not the
> tests... anybody have ideas how to deal with this now?
>
> Jarek
>

Re: Releasing transports 1.0 - dependency resolutions

[Jarek Gawor <jg...@gmail.com>]

On Wed, Apr 1, 2009 at 5:50 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Jarek Gawor wrote:
>>> Also, I'd really like to get 1.5 out the door ASAP, it's lingered way too
>>> long already.  So whatever solution gets us there soonest with consensus is
>>> the one I'll be happy with.
>>
>> Yes, I agree. Sounds like we already agree on a solution (moving http
>> and local back to Axis2).
>
> OK, I'm on this tomorrow.  If anyone has issues with it, please pipe up!

I already moved some of the utility classes and methods back to Axis2
and eliminated a direct dependency on transport base from http and
local. But once I was actually looking into moving the http module to
Axis2 I realized the the http transport tests have dependency on the
testki module which has dependencies on the transport base module....
So we can easily move the transport http code itself but not the
tests... anybody have ideas how to deal with this now?

Jarek

Re: Releasing transports 1.0 - dependency resolutions

[Jarek Gawor <jg...@gmail.com>]

On Wed, Apr 1, 2009 at 5:50 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Jarek Gawor wrote:
>>> Also, I'd really like to get 1.5 out the door ASAP, it's lingered way too
>>> long already.  So whatever solution gets us there soonest with consensus is
>>> the one I'll be happy with.
>>
>> Yes, I agree. Sounds like we already agree on a solution (moving http
>> and local back to Axis2).
>
> OK, I'm on this tomorrow.  If anyone has issues with it, please pipe up!

I already moved some of the utility classes and methods back to Axis2
and eliminated a direct dependency on transport base from http and
local. But once I was actually looking into moving the http module to
Axis2 I realized the the http transport tests have dependency on the
testki module which has dependencies on the transport base module....
So we can easily move the transport http code itself but not the
tests... anybody have ideas how to deal with this now?

Jarek

Re: Releasing transports 1.0 - dependency resolutions

[Glen Daniels <gl...@thoughtcraft.com>]

Jarek Gawor wrote:
>> Also, I'd really like to get 1.5 out the door ASAP, it's lingered way too
>> long already.  So whatever solution gets us there soonest with consensus is
>> the one I'll be happy with.
> 
> Yes, I agree. Sounds like we already agree on a solution (moving http
> and local back to Axis2).

OK, I'm on this tomorrow.  If anyone has issues with it, please pipe up!

Thanks,
--Glen

Re: Releasing transports 1.0 - dependency resolutions

[Glen Daniels <gl...@thoughtcraft.com>]

Jarek Gawor wrote:
>> Also, I'd really like to get 1.5 out the door ASAP, it's lingered way too
>> long already.  So whatever solution gets us there soonest with consensus is
>> the one I'll be happy with.
> 
> Yes, I agree. Sounds like we already agree on a solution (moving http
> and local back to Axis2).

OK, I'm on this tomorrow.  If anyone has issues with it, please pipe up!

Thanks,
--Glen

Re: Releasing transports 1.0 - dependency resolutions

[Jarek Gawor <jg...@gmail.com>]

On Tue, Mar 31, 2009 at 4:02 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi Jarek, all:
>
> Jarek Gawor wrote:
>> So sounds like we agree on moving the http module back to Axis2 and
>> leaving transport base where it is (after fixing the utility classes
>> dependency). What about tcp and local? Should we move it or leave it
>> where it is? Do Axis2 users expect local and/or tcp transports to be
>> installed by default?
>
> If we're really thinking about doing this, local should be there IMO, both
> for quick accesses (HTTP-based service gets called, say, and it calls another
> service via local transport) and for testing.  TCP not so much.

Ok, great.

> So, to be clear, the point of this is to... remove the dependency from Axis2
> to the other transports?  I do still want to be able to release the
> transports (including HTTP) separately from the full Axis2 distributions, so
> I'm not entirely sure that moving http/local back necessarily solves things.

It solves the circular dependency problem for now. For the long term
if we want to release the http transport independently from Axis2 we
might have to re-factor Axis2 and the http transport code to rely on
some new module that contains classes/interfaces through which Axis2
and transport code interacts - sort of what Jason was saying.

>  I'm not against it (I actually think all the transports should be under the
> Axis2 TLP as a subproject, but that's another conversation :)),

+1000 to that.

> I'm just not
> sure it entirely helps with this problem long term.
>
> Once we have a stable Axis2 1.5 base for the transports to depend on, this
> problem should go away until the next time we have a core change.  So if it's
> possible, I'm still thinking about the "release 1.5 jars then depend on those
> for the transport releases" option....
>
> Also, I'd really like to get 1.5 out the door ASAP, it's lingered way too
> long already.  So whatever solution gets us there soonest with consensus is
> the one I'll be happy with.

Yes, I agree. Sounds like we already agree on a solution (moving http
and local back to Axis2).

Jarek

Re: Releasing transports 1.0 - dependency resolutions

["Asankha C. Perera" <as...@apache.org>]

Glen Daniels wrote:
> Jarek Gawor wrote:
>   
>> So sounds like we agree on moving the http module back to Axis2 and
>> leaving transport base where it is (after fixing the utility classes
>> dependency). What about tcp and local? Should we move it or leave it
>> where it is? Do Axis2 users expect local and/or tcp transports to be
>> installed by default?
>>     
> ....
>
> Also, I'd really like to get 1.5 out the door ASAP, it's lingered way too
> long already.  So whatever solution gets us there soonest with consensus is
> the one I'll be happy with.
>   
I think we have consensus now.. move http and local back to Axis2 
transports. That allows you to release minor bug fix versions of these 
separately if required as well

cheers
asankha

-- 
Asankha C. Perera
AdroitLogic, http://adroitlogic.org

http://esbmagic.blogspot.com

Re: Releasing transports 1.0 - dependency resolutions

["Asankha C. Perera" <as...@apache.org>]

Glen Daniels wrote:
> Jarek Gawor wrote:
>   
>> So sounds like we agree on moving the http module back to Axis2 and
>> leaving transport base where it is (after fixing the utility classes
>> dependency). What about tcp and local? Should we move it or leave it
>> where it is? Do Axis2 users expect local and/or tcp transports to be
>> installed by default?
>>     
> ....
>
> Also, I'd really like to get 1.5 out the door ASAP, it's lingered way too
> long already.  So whatever solution gets us there soonest with consensus is
> the one I'll be happy with.
>   
I think we have consensus now.. move http and local back to Axis2 
transports. That allows you to release minor bug fix versions of these 
separately if required as well

cheers
asankha

-- 
Asankha C. Perera
AdroitLogic, http://adroitlogic.org

http://esbmagic.blogspot.com

Re: Releasing transports 1.0 - dependency resolutions

[Jarek Gawor <jg...@gmail.com>]

On Tue, Mar 31, 2009 at 4:02 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi Jarek, all:
>
> Jarek Gawor wrote:
>> So sounds like we agree on moving the http module back to Axis2 and
>> leaving transport base where it is (after fixing the utility classes
>> dependency). What about tcp and local? Should we move it or leave it
>> where it is? Do Axis2 users expect local and/or tcp transports to be
>> installed by default?
>
> If we're really thinking about doing this, local should be there IMO, both
> for quick accesses (HTTP-based service gets called, say, and it calls another
> service via local transport) and for testing.  TCP not so much.

Ok, great.

> So, to be clear, the point of this is to... remove the dependency from Axis2
> to the other transports?  I do still want to be able to release the
> transports (including HTTP) separately from the full Axis2 distributions, so
> I'm not entirely sure that moving http/local back necessarily solves things.

It solves the circular dependency problem for now. For the long term
if we want to release the http transport independently from Axis2 we
might have to re-factor Axis2 and the http transport code to rely on
some new module that contains classes/interfaces through which Axis2
and transport code interacts - sort of what Jason was saying.

>  I'm not against it (I actually think all the transports should be under the
> Axis2 TLP as a subproject, but that's another conversation :)),

+1000 to that.

> I'm just not
> sure it entirely helps with this problem long term.
>
> Once we have a stable Axis2 1.5 base for the transports to depend on, this
> problem should go away until the next time we have a core change.  So if it's
> possible, I'm still thinking about the "release 1.5 jars then depend on those
> for the transport releases" option....
>
> Also, I'd really like to get 1.5 out the door ASAP, it's lingered way too
> long already.  So whatever solution gets us there soonest with consensus is
> the one I'll be happy with.

Yes, I agree. Sounds like we already agree on a solution (moving http
and local back to Axis2).

Jarek

Re: Releasing transports 1.0 - dependency resolutions

[Glen Daniels <gl...@thoughtcraft.com>]

Hi Jarek, all:

Jarek Gawor wrote:
> So sounds like we agree on moving the http module back to Axis2 and
> leaving transport base where it is (after fixing the utility classes
> dependency). What about tcp and local? Should we move it or leave it
> where it is? Do Axis2 users expect local and/or tcp transports to be
> installed by default?

If we're really thinking about doing this, local should be there IMO, both
for quick accesses (HTTP-based service gets called, say, and it calls another
service via local transport) and for testing.  TCP not so much.

So, to be clear, the point of this is to... remove the dependency from Axis2
to the other transports?  I do still want to be able to release the
transports (including HTTP) separately from the full Axis2 distributions, so
I'm not entirely sure that moving http/local back necessarily solves things.
 I'm not against it (I actually think all the transports should be under the
Axis2 TLP as a subproject, but that's another conversation :)), I'm just not
sure it entirely helps with this problem long term.

Once we have a stable Axis2 1.5 base for the transports to depend on, this
problem should go away until the next time we have a core change.  So if it's
possible, I'm still thinking about the "release 1.5 jars then depend on those
for the transport releases" option....

Also, I'd really like to get 1.5 out the door ASAP, it's lingered way too
long already.  So whatever solution gets us there soonest with consensus is
the one I'll be happy with.

--Glen

Re: Releasing transports 1.0 - dependency resolutions

[Glen Daniels <gl...@thoughtcraft.com>]

Hi Jarek, all:

Jarek Gawor wrote:
> So sounds like we agree on moving the http module back to Axis2 and
> leaving transport base where it is (after fixing the utility classes
> dependency). What about tcp and local? Should we move it or leave it
> where it is? Do Axis2 users expect local and/or tcp transports to be
> installed by default?

If we're really thinking about doing this, local should be there IMO, both
for quick accesses (HTTP-based service gets called, say, and it calls another
service via local transport) and for testing.  TCP not so much.

So, to be clear, the point of this is to... remove the dependency from Axis2
to the other transports?  I do still want to be able to release the
transports (including HTTP) separately from the full Axis2 distributions, so
I'm not entirely sure that moving http/local back necessarily solves things.
 I'm not against it (I actually think all the transports should be under the
Axis2 TLP as a subproject, but that's another conversation :)), I'm just not
sure it entirely helps with this problem long term.

Once we have a stable Axis2 1.5 base for the transports to depend on, this
problem should go away until the next time we have a core change.  So if it's
possible, I'm still thinking about the "release 1.5 jars then depend on those
for the transport releases" option....

Also, I'd really like to get 1.5 out the door ASAP, it's lingered way too
long already.  So whatever solution gets us there soonest with consensus is
the one I'll be happy with.

--Glen

Re: Releasing transports 1.0 - dependency resolutions

[Jarek Gawor <jg...@gmail.com>]

On Tue, Mar 31, 2009 at 1:53 AM, Asankha C. Perera <as...@apache.org> wrote:
>
> No, only the following two classes are using a two utility classes, which
> can be fixed easily. Like I said, the base will remain in the transports
> module - whether it be under commons or back again in Synapse.
>
> ./src/org/apache/axis2/transport/http/CommonsHTTPTransportSender.java
> ./src/org/apache/axis2/transport/http/AxisServlet.java
>

Ok. If we can eliminate these dependencies that's great. One less
thing to worry about.

So sounds like we agree on moving the http module back to Axis2 and
leaving transport base where it is (after fixing the utility classes
dependency). What about tcp and local? Should we move it or leave it
where it is? Do Axis2 users expect local and/or tcp transports to be
installed by default?

Jarek

Re: Releasing transports 1.0 - dependency resolutions

[Jarek Gawor <jg...@gmail.com>]

On Tue, Mar 31, 2009 at 1:53 AM, Asankha C. Perera <as...@apache.org> wrote:
>
> No, only the following two classes are using a two utility classes, which
> can be fixed easily. Like I said, the base will remain in the transports
> module - whether it be under commons or back again in Synapse.
>
> ./src/org/apache/axis2/transport/http/CommonsHTTPTransportSender.java
> ./src/org/apache/axis2/transport/http/AxisServlet.java
>

Ok. If we can eliminate these dependencies that's great. One less
thing to worry about.

So sounds like we agree on moving the http module back to Axis2 and
leaving transport base where it is (after fixing the utility classes
dependency). What about tcp and local? Should we move it or leave it
where it is? Do Axis2 users expect local and/or tcp transports to be
installed by default?

Jarek

Re: Releasing transports 1.0 - dependency resolutions

["Asankha C. Perera" <as...@apache.org>]

Jarek Gawor wrote:
> On Tue, Mar 31, 2009 at 12:22 AM, Asankha C. Perera <as...@apache.org> wrote:
>   
>>>> 2) Move the base, local, tcp, and http transport modules back to Axis2
>>>> and release them with Axis2. That way the transports project would
>>>> only have the 'optional' transport modules and we wouldn't have to
>>>> release the transports for/with Axis2.
>>>>         
>> You can take back just http and local into Axis2 if that makes the release
>> possible, but not base. AFAIK the base had no relationship with the Axis2
>> http transport. I do not think the tcp transport has much value to vanilla
>> Axis2 either..
>>     
>
> Transport base has lots of dependencies on Axis2 and transport http
> has dependencies on transport base (and Axis2). So transport base has
> to move if we decide to move it. 
No, only the following two classes are using a two utility classes, 
which can be fixed easily. Like I said, the base will remain in the 
transports module - whether it be under commons or back again in Synapse.

./src/org/apache/axis2/transport/http/CommonsHTTPTransportSender.java
./src/org/apache/axis2/transport/http/AxisServlet.java

> I mentioned tcp and local transport modules because they are currently enabled in Axis2 conf.xml file so
> we would need to update the configuration at least.
>   
thats fine

cheers
asankha

-- 
Asankha C. Perera
AdroitLogic, http://adroitlogic.org

http://esbmagic.blogspot.com

Re: Releasing transports 1.0 - dependency resolutions

["Asankha C. Perera" <as...@apache.org>]

Jarek Gawor wrote:
> On Tue, Mar 31, 2009 at 12:22 AM, Asankha C. Perera <as...@apache.org> wrote:
>   
>>>> 2) Move the base, local, tcp, and http transport modules back to Axis2
>>>> and release them with Axis2. That way the transports project would
>>>> only have the 'optional' transport modules and we wouldn't have to
>>>> release the transports for/with Axis2.
>>>>         
>> You can take back just http and local into Axis2 if that makes the release
>> possible, but not base. AFAIK the base had no relationship with the Axis2
>> http transport. I do not think the tcp transport has much value to vanilla
>> Axis2 either..
>>     
>
> Transport base has lots of dependencies on Axis2 and transport http
> has dependencies on transport base (and Axis2). So transport base has
> to move if we decide to move it. 
No, only the following two classes are using a two utility classes, 
which can be fixed easily. Like I said, the base will remain in the 
transports module - whether it be under commons or back again in Synapse.

./src/org/apache/axis2/transport/http/CommonsHTTPTransportSender.java
./src/org/apache/axis2/transport/http/AxisServlet.java

> I mentioned tcp and local transport modules because they are currently enabled in Axis2 conf.xml file so
> we would need to update the configuration at least.
>   
thats fine

cheers
asankha

-- 
Asankha C. Perera
AdroitLogic, http://adroitlogic.org

http://esbmagic.blogspot.com

Re: Releasing transports 1.0 - dependency resolutions

[Jarek Gawor <jg...@gmail.com>]

On Tue, Mar 31, 2009 at 12:22 AM, Asankha C. Perera <as...@apache.org> wrote:
>
>>> 2) Move the base, local, tcp, and http transport modules back to Axis2
>>> and release them with Axis2. That way the transports project would
>>> only have the 'optional' transport modules and we wouldn't have to
>>> release the transports for/with Axis2.
>
> You can take back just http and local into Axis2 if that makes the release
> possible, but not base. AFAIK the base had no relationship with the Axis2
> http transport. I do not think the tcp transport has much value to vanilla
> Axis2 either..

Transport base has lots of dependencies on Axis2 and transport http
has dependencies on transport base (and Axis2). So transport base has
to move if we decide to move it. I mentioned tcp and local transport
modules because they are currently enabled in Axis2 conf.xml file so
we would need to update the configuration at least.

Jarek

Re: Releasing transports 1.0 - dependency resolutions

[Jarek Gawor <jg...@gmail.com>]

On Tue, Mar 31, 2009 at 12:22 AM, Asankha C. Perera <as...@apache.org> wrote:
>
>>> 2) Move the base, local, tcp, and http transport modules back to Axis2
>>> and release them with Axis2. That way the transports project would
>>> only have the 'optional' transport modules and we wouldn't have to
>>> release the transports for/with Axis2.
>
> You can take back just http and local into Axis2 if that makes the release
> possible, but not base. AFAIK the base had no relationship with the Axis2
> http transport. I do not think the tcp transport has much value to vanilla
> Axis2 either..

Transport base has lots of dependencies on Axis2 and transport http
has dependencies on transport base (and Axis2). So transport base has
to move if we decide to move it. I mentioned tcp and local transport
modules because they are currently enabled in Axis2 conf.xml file so
we would need to update the configuration at least.

Jarek

Re: Releasing transports 1.0 - dependency resolutions

["Asankha C. Perera" <as...@apache.org>]

>> 2) Move the base, local, tcp, and http transport modules back to Axis2
>> and release them with Axis2. That way the transports project would
>> only have the 'optional' transport modules and we wouldn't have to
>> release the transports for/with Axis2.
You can take back just http and local into Axis2 if that makes the 
release possible, but not base. AFAIK the base had no relationship with 
the Axis2 http transport. I do not think the tcp transport has much 
value to vanilla Axis2 either..

After almost one year since 
[http://markmail.org/message/hshqoxr33uqqwvhz], are we talking about 
moving code back :-[ ?

cheers
asankha

-- 
Asankha C. Perera
AdroitLogic, http://adroitlogic.org

http://esbmagic.blogspot.com

Re: Releasing transports 1.0 - dependency resolutions

["Asankha C. Perera" <as...@apache.org>]

>> 2) Move the base, local, tcp, and http transport modules back to Axis2
>> and release them with Axis2. That way the transports project would
>> only have the 'optional' transport modules and we wouldn't have to
>> release the transports for/with Axis2.
You can take back just http and local into Axis2 if that makes the 
release possible, but not base. AFAIK the base had no relationship with 
the Axis2 http transport. I do not think the tcp transport has much 
value to vanilla Axis2 either..

After almost one year since 
[http://markmail.org/message/hshqoxr33uqqwvhz], are we talking about 
moving code back :-[ ?

cheers
asankha

-- 
Asankha C. Perera
AdroitLogic, http://adroitlogic.org

http://esbmagic.blogspot.com

Re: Releasing transports 1.0 - dependency resolutions

[Jason Fager <ja...@riskmetrics.com>]

> Jarek Gawor wrote:
>> ...
>> 
>> 2) Move the base, local, tcp, and http transport modules back to Axis2
>> and release them with Axis2. That way the transports project would
>> only have the 'optional' transport modules and we wouldn't have to
>> release the transports for/with Axis2.
>>  
> 
> +1 for this approach. Having two projects which are mutually dependent
> on each other is just plain stupid.

Agreed, but that doesn't necessarily mean that moving the relevant parts of
one directly into the other is smart.  The normal way to break a cyclical
dependency is to introduce a third element with no dependency on either,
that both elements can in turn depend on; or a third element with a
dependency on both, that neither themselves depend on. I.e: factor out the
bits that both share into a common api, or to create a separate artifact
that glues the parts together as needed. (I'm still new around here, I'm not
familiar enough with the codebase to know which makes more sense in this
case).

- Jason

Re: Releasing transports 1.0 - dependency resolutions

[Dennis Sosnoski <dm...@sosnoski.com>]

Jarek Gawor wrote:
> ...
>
> 2) Move the base, local, tcp, and http transport modules back to Axis2
> and release them with Axis2. That way the transports project would
> only have the 'optional' transport modules and we wouldn't have to
> release the transports for/with Axis2.
>   

+1 for this approach. Having two projects which are mutually dependent 
on each other is just plain stupid.

  - Dennis

Re: Releasing transports 1.0 - dependency resolutions

[Dennis Sosnoski <dm...@sosnoski.com>]

Jarek Gawor wrote:
> ...
>
> 2) Move the base, local, tcp, and http transport modules back to Axis2
> and release them with Axis2. That way the transports project would
> only have the 'optional' transport modules and we wouldn't have to
> release the transports for/with Axis2.
>   

+1 for this approach. Having two projects which are mutually dependent 
on each other is just plain stupid.

  - Dennis

Re: Releasing transports 1.0 - dependency resolutions

[Amila Suriarachchi <am...@gmail.com>]

On Tue, Mar 31, 2009 at 8:20 AM, Jarek Gawor <jg...@gmail.com> wrote:

> I mentioned two additional ideas to deal with this problem a while ago
> when this issue also came up:
>
> 1) Release transports and axis2 at the same time. Have one vote for
> both libraries.


+1.  I think this the best way.

thanks,
Amila.

>
>
> 2) Move the base, local, tcp, and http transport modules back to Axis2
> and release them with Axis2. That way the transports project would
> only have the 'optional' transport modules and we wouldn't have to
> release the transports for/with Axis2.
>
> Jarek
>
> On Mon, Mar 30, 2009 at 3:20 PM, Glen Daniels <gl...@thoughtcraft.com>
> wrote:
> > Hi folks:
> >
> > So I'm trying to get the transports 1.0 releases moving along, and have
> run
> > into a bit of a snag.  The transports depend on axis2-kernel SNAPSHOT,
> for
> > interfaces like MessageContext, Flow, etc. - the problem is how do we do
> the
> > release when we want to release the transports before the actual Axis2
> > release?  We need to resolve all the SNAPSHOT dependencies for the Maven
> > release plugin to be happy, and for this case, we seem to have a circular
> > dependency chain. :(
> >
> > A couple of options off the top of my head:
> >
> > * Release transports against Axis2 1.4.1's kernel - this may not even be
> > possible as there may have been incompatible changes.
> >
> > * Do a Maven-only release of Axis2-kernel 1.5 - i.e. NOT a distribution
> but
> > just a release into Maven.  Then use that for the Transports 1.0
> releases,
> > and then release the Axis2 1.5 distribution after that.
> >
> > Moving forward, anyone have thoughts on how to best deal with this?  One
> of
> > these options, or something else?
> >
> > Thanks,
> > --Glen
> >
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Re: Releasing transports 1.0 - dependency resolutions

[Amila Suriarachchi <am...@gmail.com>]

On Tue, Mar 31, 2009 at 8:20 AM, Jarek Gawor <jg...@gmail.com> wrote:

> I mentioned two additional ideas to deal with this problem a while ago
> when this issue also came up:
>
> 1) Release transports and axis2 at the same time. Have one vote for
> both libraries.


+1.  I think this the best way.

thanks,
Amila.

>
>
> 2) Move the base, local, tcp, and http transport modules back to Axis2
> and release them with Axis2. That way the transports project would
> only have the 'optional' transport modules and we wouldn't have to
> release the transports for/with Axis2.
>
> Jarek
>
> On Mon, Mar 30, 2009 at 3:20 PM, Glen Daniels <gl...@thoughtcraft.com>
> wrote:
> > Hi folks:
> >
> > So I'm trying to get the transports 1.0 releases moving along, and have
> run
> > into a bit of a snag.  The transports depend on axis2-kernel SNAPSHOT,
> for
> > interfaces like MessageContext, Flow, etc. - the problem is how do we do
> the
> > release when we want to release the transports before the actual Axis2
> > release?  We need to resolve all the SNAPSHOT dependencies for the Maven
> > release plugin to be happy, and for this case, we seem to have a circular
> > dependency chain. :(
> >
> > A couple of options off the top of my head:
> >
> > * Release transports against Axis2 1.4.1's kernel - this may not even be
> > possible as there may have been incompatible changes.
> >
> > * Do a Maven-only release of Axis2-kernel 1.5 - i.e. NOT a distribution
> but
> > just a release into Maven.  Then use that for the Transports 1.0
> releases,
> > and then release the Axis2 1.5 distribution after that.
> >
> > Moving forward, anyone have thoughts on how to best deal with this?  One
> of
> > these options, or something else?
> >
> > Thanks,
> > --Glen
> >
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Re: Releasing transports 1.0 - dependency resolutions

[Jarek Gawor <jg...@gmail.com>]

I mentioned two additional ideas to deal with this problem a while ago
when this issue also came up:

1) Release transports and axis2 at the same time. Have one vote for
both libraries.

2) Move the base, local, tcp, and http transport modules back to Axis2
and release them with Axis2. That way the transports project would
only have the 'optional' transport modules and we wouldn't have to
release the transports for/with Axis2.

Jarek

On Mon, Mar 30, 2009 at 3:20 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi folks:
>
> So I'm trying to get the transports 1.0 releases moving along, and have run
> into a bit of a snag.  The transports depend on axis2-kernel SNAPSHOT, for
> interfaces like MessageContext, Flow, etc. - the problem is how do we do the
> release when we want to release the transports before the actual Axis2
> release?  We need to resolve all the SNAPSHOT dependencies for the Maven
> release plugin to be happy, and for this case, we seem to have a circular
> dependency chain. :(
>
> A couple of options off the top of my head:
>
> * Release transports against Axis2 1.4.1's kernel - this may not even be
> possible as there may have been incompatible changes.
>
> * Do a Maven-only release of Axis2-kernel 1.5 - i.e. NOT a distribution but
> just a release into Maven.  Then use that for the Transports 1.0 releases,
> and then release the Axis2 1.5 distribution after that.
>
> Moving forward, anyone have thoughts on how to best deal with this?  One of
> these options, or something else?
>
> Thanks,
> --Glen
>

Re: Releasing transports 1.0 - dependency resolutions

[Jarek Gawor <jg...@gmail.com>]

I mentioned two additional ideas to deal with this problem a while ago
when this issue also came up:

1) Release transports and axis2 at the same time. Have one vote for
both libraries.

2) Move the base, local, tcp, and http transport modules back to Axis2
and release them with Axis2. That way the transports project would
only have the 'optional' transport modules and we wouldn't have to
release the transports for/with Axis2.

Jarek

On Mon, Mar 30, 2009 at 3:20 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi folks:
>
> So I'm trying to get the transports 1.0 releases moving along, and have run
> into a bit of a snag.  The transports depend on axis2-kernel SNAPSHOT, for
> interfaces like MessageContext, Flow, etc. - the problem is how do we do the
> release when we want to release the transports before the actual Axis2
> release?  We need to resolve all the SNAPSHOT dependencies for the Maven
> release plugin to be happy, and for this case, we seem to have a circular
> dependency chain. :(
>
> A couple of options off the top of my head:
>
> * Release transports against Axis2 1.4.1's kernel - this may not even be
> possible as there may have been incompatible changes.
>
> * Do a Maven-only release of Axis2-kernel 1.5 - i.e. NOT a distribution but
> just a release into Maven.  Then use that for the Transports 1.0 releases,
> and then release the Axis2 1.5 distribution after that.
>
> Moving forward, anyone have thoughts on how to best deal with this?  One of
> these options, or something else?
>
> Thanks,
> --Glen
>

Re: Releasing transports 1.0 - dependency resolutions

[Dennis Sosnoski <dm...@sosnoski.com>]

If transports is using these Axis2 interfaces I don't see the point of 
having it as a separate project. I thought the reason for moving 
transports outside of Axis2 was to allow it to be used for other 
purposes. How is that going to work if the code is assuming the Axis2 
environment?

The only clean solution is to have transports define whatever interfaces 
it needs. The Axis2 versions can then extend the transports versions.

  - Dennis


Glen Daniels wrote:
> Hi folks:
>
> So I'm trying to get the transports 1.0 releases moving along, and have run
> into a bit of a snag.  The transports depend on axis2-kernel SNAPSHOT, for
> interfaces like MessageContext, Flow, etc. - the problem is how do we do the
> release when we want to release the transports before the actual Axis2
> release?  We need to resolve all the SNAPSHOT dependencies for the Maven
> release plugin to be happy, and for this case, we seem to have a circular
> dependency chain. :(
>
> A couple of options off the top of my head:
>
> * Release transports against Axis2 1.4.1's kernel - this may not even be
> possible as there may have been incompatible changes.
>
> * Do a Maven-only release of Axis2-kernel 1.5 - i.e. NOT a distribution but
> just a release into Maven.  Then use that for the Transports 1.0 releases,
> and then release the Axis2 1.5 distribution after that.
>
> Moving forward, anyone have thoughts on how to best deal with this?  One of
> these options, or something else?
>
> Thanks,
> --Glen
>
>   

Re: Releasing transports 1.0 - dependency resolutions

[Glen Daniels <gl...@thoughtcraft.com>]

Oops - sent that before I finished editing.

Glen Daniels wrote:
> The was never to release the transports without dependency on Axis2 - they
> are *Axis2* transports, and while they're pluggable components, they're not
> designed for usage outside of Axis2 (Synapse notwithstanding - Synapse is
> built around Axis2, not without it).  They live in WS-Commons

That was meant to say "They live in WS-Commons because it was felt to be
easier for more people to work on them and release them there, not because
they're completely separable from Axis2."

Thanks,
--Glen

Re: Releasing transports 1.0 - dependency resolutions

[Glen Daniels <gl...@thoughtcraft.com>]

Oops - sent that before I finished editing.

Glen Daniels wrote:
> The was never to release the transports without dependency on Axis2 - they
> are *Axis2* transports, and while they're pluggable components, they're not
> designed for usage outside of Axis2 (Synapse notwithstanding - Synapse is
> built around Axis2, not without it).  They live in WS-Commons

That was meant to say "They live in WS-Commons because it was felt to be
easier for more people to work on them and release them there, not because
they're completely separable from Axis2."

Thanks,
--Glen

Re: Releasing transports 1.0 - dependency resolutions

[Jason Fager <ja...@riskmetrics.com>]

> Well, it's not quite that easy.  The problem is that we want to release Axis2
> (the distribution assemblies) /with/ at least the HTTP and local transports
> included.  This puts us in a situation where we can't release either unless
> the other has been released first... but only if we tightly couple the Maven
> releases of the Axis2 jars to the release of the Axis2 distribution files.
> 
> I'd like to understand the confusion that releasing Maven artifacts first
> (before the distribution packages) would cause, because as I think about it
> more, I think it might be a pretty reasonable solution.  Release the Axis2
> 1.5 jars to the Maven repositories (those jars depend upon the transports
> 1.0-SNAPSHOT version, but only for tests), then release the transport 1.0
> jars bound to those, then build and release the Axis2 1.5 distribution
> assemblies (containing the 1.0 transports).

I'm sorry, I may be misunderstanding what you mean by "Maven-only" release.
When you say "distribution assemblies", what are you referring to?  The big
omnibus distribution package that people download from the front page when
they don't want to know the details?  That should be considered a completely
separate artifact from the components that go into it - i.e. there should
*never* be a case where *anything* depends on the final distributable.  It's
just an assembly of other artifacts, and those artifacts should be available
independent of the larger distribution.



> I do not, clearly, agree with the point of view that the transports should
> become truly decoupled from Axis2.  I'm not sure what that would even mean,
> when you think about what the transports actually do - which is take
> wire-level stuff and turn it into MessageContexts to push into AxisEngine,
> and vice versa.

I didn't mean to imply that there should be a complete decoupling.  I just
think its important that any cyclical dependencies are removed, rather than
papered over.

Thanks,
Jason


> 
> Thanks,
> --Glen
> 
>> - Jason
>> 
>> 
>> 
>>> Hi folks:
>>> 
>>> So I'm trying to get the transports 1.0 releases moving along, and have run
>>> into a bit of a snag.  The transports depend on axis2-kernel SNAPSHOT, for
>>> interfaces like MessageContext, Flow, etc. - the problem is how do we do the
>>> release when we want to release the transports before the actual Axis2
>>> release?  We need to resolve all the SNAPSHOT dependencies for the Maven
>>> release plugin to be happy, and for this case, we seem to have a circular
>>> dependency chain. :(
>>> 
>>> A couple of options off the top of my head:
>>> 
>>> * Release transports against Axis2 1.4.1's kernel - this may not even be
>>> possible as there may have been incompatible changes.
>>> 
>>> * Do a Maven-only release of Axis2-kernel 1.5 - i.e. NOT a distribution but
>>> just a release into Maven.  Then use that for the Transports 1.0 releases,
>>> and then release the Axis2 1.5 distribution after that.
>>> 
>>> Moving forward, anyone have thoughts on how to best deal with this?  One of
>>> these options, or something else?
>>> 
>>> Thanks,
>>> --Glen
>> 

Re: Releasing transports 1.0 - dependency resolutions

[Jason Fager <ja...@riskmetrics.com>]

> Well, it's not quite that easy.  The problem is that we want to release Axis2
> (the distribution assemblies) /with/ at least the HTTP and local transports
> included.  This puts us in a situation where we can't release either unless
> the other has been released first... but only if we tightly couple the Maven
> releases of the Axis2 jars to the release of the Axis2 distribution files.
> 
> I'd like to understand the confusion that releasing Maven artifacts first
> (before the distribution packages) would cause, because as I think about it
> more, I think it might be a pretty reasonable solution.  Release the Axis2
> 1.5 jars to the Maven repositories (those jars depend upon the transports
> 1.0-SNAPSHOT version, but only for tests), then release the transport 1.0
> jars bound to those, then build and release the Axis2 1.5 distribution
> assemblies (containing the 1.0 transports).

I'm sorry, I may be misunderstanding what you mean by "Maven-only" release.
When you say "distribution assemblies", what are you referring to?  The big
omnibus distribution package that people download from the front page when
they don't want to know the details?  That should be considered a completely
separate artifact from the components that go into it - i.e. there should
*never* be a case where *anything* depends on the final distributable.  It's
just an assembly of other artifacts, and those artifacts should be available
independent of the larger distribution.



> I do not, clearly, agree with the point of view that the transports should
> become truly decoupled from Axis2.  I'm not sure what that would even mean,
> when you think about what the transports actually do - which is take
> wire-level stuff and turn it into MessageContexts to push into AxisEngine,
> and vice versa.

I didn't mean to imply that there should be a complete decoupling.  I just
think its important that any cyclical dependencies are removed, rather than
papered over.

Thanks,
Jason


> 
> Thanks,
> --Glen
> 
>> - Jason
>> 
>> 
>> 
>>> Hi folks:
>>> 
>>> So I'm trying to get the transports 1.0 releases moving along, and have run
>>> into a bit of a snag.  The transports depend on axis2-kernel SNAPSHOT, for
>>> interfaces like MessageContext, Flow, etc. - the problem is how do we do the
>>> release when we want to release the transports before the actual Axis2
>>> release?  We need to resolve all the SNAPSHOT dependencies for the Maven
>>> release plugin to be happy, and for this case, we seem to have a circular
>>> dependency chain. :(
>>> 
>>> A couple of options off the top of my head:
>>> 
>>> * Release transports against Axis2 1.4.1's kernel - this may not even be
>>> possible as there may have been incompatible changes.
>>> 
>>> * Do a Maven-only release of Axis2-kernel 1.5 - i.e. NOT a distribution but
>>> just a release into Maven.  Then use that for the Transports 1.0 releases,
>>> and then release the Axis2 1.5 distribution after that.
>>> 
>>> Moving forward, anyone have thoughts on how to best deal with this?  One of
>>> these options, or something else?
>>> 
>>> Thanks,
>>> --Glen
>> 

Re: Releasing transports 1.0 - dependency resolutions

[Glen Daniels <gl...@thoughtcraft.com>]

Hi Jason:

Jason Fager wrote:
> I'm sorry, I'm kind of new around here, but the basic strategy that I know

Welcome! :)

> to follow is to cut a branch, change the dependency in the pom of the branch
> to the released version of the upstream dependency that you're milestoning
> against, and then release from the branch.

Exactly right.

> If you can't do this because the transports actually do depend on
> kernel-SNAPSHOT, and won't work with a previous version, then what are you
> releasing them *for* - i.e., where do you expect to use them, if the
> underlying code they depend on doesn't exist as a release anywhere?

Good question, and I think the crux of the issue.

> I kind of agree with Dennis - if the intent is for these things to exist
> independent from the larger axis2 codebase, then one of two things needs to
> happen.  Either the interfaces in question need to be rolled into the
> transports package, or (and probably even better) they need to be split off
> into their own artifact (axis2-api?) that both transports and the mainline
> axis2 code can depend on.

The was never to release the transports without dependency on Axis2 - they
are *Axis2* transports, and while they're pluggable components, they're not
designed for usage outside of Axis2 (Synapse notwithstanding - Synapse is
built around Axis2, not without it).  They live in WS-Commons

> I would be emphatically against the idea of a "Maven-only" release.  That's
> a stopgap measure, and it creates confusion for people coming into the
> project (and being in the middle of this process myself, it's pretty
> confusing as is).  If this is a problem, the time should be taken to solve
> it correctly, else it's just going to get worse in the future.

Well, it's not quite that easy.  The problem is that we want to release Axis2
(the distribution assemblies) /with/ at least the HTTP and local transports
included.  This puts us in a situation where we can't release either unless
the other has been released first... but only if we tightly couple the Maven
releases of the Axis2 jars to the release of the Axis2 distribution files.

I'd like to understand the confusion that releasing Maven artifacts first
(before the distribution packages) would cause, because as I think about it
more, I think it might be a pretty reasonable solution.  Release the Axis2
1.5 jars to the Maven repositories (those jars depend upon the transports
1.0-SNAPSHOT version, but only for tests), then release the transport 1.0
jars bound to those, then build and release the Axis2 1.5 distribution
assemblies (containing the 1.0 transports).

I do not, clearly, agree with the point of view that the transports should
become truly decoupled from Axis2.  I'm not sure what that would even mean,
when you think about what the transports actually do - which is take
wire-level stuff and turn it into MessageContexts to push into AxisEngine,
and vice versa.

Thanks,
--Glen

> - Jason 
> 
> 
> 
>> Hi folks:
>>
>> So I'm trying to get the transports 1.0 releases moving along, and have run
>> into a bit of a snag.  The transports depend on axis2-kernel SNAPSHOT, for
>> interfaces like MessageContext, Flow, etc. - the problem is how do we do the
>> release when we want to release the transports before the actual Axis2
>> release?  We need to resolve all the SNAPSHOT dependencies for the Maven
>> release plugin to be happy, and for this case, we seem to have a circular
>> dependency chain. :(
>>
>> A couple of options off the top of my head:
>>
>> * Release transports against Axis2 1.4.1's kernel - this may not even be
>> possible as there may have been incompatible changes.
>>
>> * Do a Maven-only release of Axis2-kernel 1.5 - i.e. NOT a distribution but
>> just a release into Maven.  Then use that for the Transports 1.0 releases,
>> and then release the Axis2 1.5 distribution after that.
>>
>> Moving forward, anyone have thoughts on how to best deal with this?  One of
>> these options, or something else?
>>
>> Thanks,
>> --Glen
> 

Re: Releasing transports 1.0 - dependency resolutions

[Glen Daniels <gl...@thoughtcraft.com>]

Hi Jason:

Jason Fager wrote:
> I'm sorry, I'm kind of new around here, but the basic strategy that I know

Welcome! :)

> to follow is to cut a branch, change the dependency in the pom of the branch
> to the released version of the upstream dependency that you're milestoning
> against, and then release from the branch.

Exactly right.

> If you can't do this because the transports actually do depend on
> kernel-SNAPSHOT, and won't work with a previous version, then what are you
> releasing them *for* - i.e., where do you expect to use them, if the
> underlying code they depend on doesn't exist as a release anywhere?

Good question, and I think the crux of the issue.

> I kind of agree with Dennis - if the intent is for these things to exist
> independent from the larger axis2 codebase, then one of two things needs to
> happen.  Either the interfaces in question need to be rolled into the
> transports package, or (and probably even better) they need to be split off
> into their own artifact (axis2-api?) that both transports and the mainline
> axis2 code can depend on.

The was never to release the transports without dependency on Axis2 - they
are *Axis2* transports, and while they're pluggable components, they're not
designed for usage outside of Axis2 (Synapse notwithstanding - Synapse is
built around Axis2, not without it).  They live in WS-Commons

> I would be emphatically against the idea of a "Maven-only" release.  That's
> a stopgap measure, and it creates confusion for people coming into the
> project (and being in the middle of this process myself, it's pretty
> confusing as is).  If this is a problem, the time should be taken to solve
> it correctly, else it's just going to get worse in the future.

Well, it's not quite that easy.  The problem is that we want to release Axis2
(the distribution assemblies) /with/ at least the HTTP and local transports
included.  This puts us in a situation where we can't release either unless
the other has been released first... but only if we tightly couple the Maven
releases of the Axis2 jars to the release of the Axis2 distribution files.

I'd like to understand the confusion that releasing Maven artifacts first
(before the distribution packages) would cause, because as I think about it
more, I think it might be a pretty reasonable solution.  Release the Axis2
1.5 jars to the Maven repositories (those jars depend upon the transports
1.0-SNAPSHOT version, but only for tests), then release the transport 1.0
jars bound to those, then build and release the Axis2 1.5 distribution
assemblies (containing the 1.0 transports).

I do not, clearly, agree with the point of view that the transports should
become truly decoupled from Axis2.  I'm not sure what that would even mean,
when you think about what the transports actually do - which is take
wire-level stuff and turn it into MessageContexts to push into AxisEngine,
and vice versa.

Thanks,
--Glen

> - Jason 
> 
> 
> 
>> Hi folks:
>>
>> So I'm trying to get the transports 1.0 releases moving along, and have run
>> into a bit of a snag.  The transports depend on axis2-kernel SNAPSHOT, for
>> interfaces like MessageContext, Flow, etc. - the problem is how do we do the
>> release when we want to release the transports before the actual Axis2
>> release?  We need to resolve all the SNAPSHOT dependencies for the Maven
>> release plugin to be happy, and for this case, we seem to have a circular
>> dependency chain. :(
>>
>> A couple of options off the top of my head:
>>
>> * Release transports against Axis2 1.4.1's kernel - this may not even be
>> possible as there may have been incompatible changes.
>>
>> * Do a Maven-only release of Axis2-kernel 1.5 - i.e. NOT a distribution but
>> just a release into Maven.  Then use that for the Transports 1.0 releases,
>> and then release the Axis2 1.5 distribution after that.
>>
>> Moving forward, anyone have thoughts on how to best deal with this?  One of
>> these options, or something else?
>>
>> Thanks,
>> --Glen
> 

Re: Releasing transports 1.0 - dependency resolutions

[Jason Fager <ja...@riskmetrics.com>]

I'm sorry, I'm kind of new around here, but the basic strategy that I know
to follow is to cut a branch, change the dependency in the pom of the branch
to the released version of the upstream dependency that you're milestoning
against, and then release from the branch.

If you can't do this because the transports actually do depend on
kernel-SNAPSHOT, and won't work with a previous version, then what are you
releasing them *for* - i.e., where do you expect to use them, if the
underlying code they depend on doesn't exist as a release anywhere?

I kind of agree with Dennis - if the intent is for these things to exist
independent from the larger axis2 codebase, then one of two things needs to
happen.  Either the interfaces in question need to be rolled into the
transports package, or (and probably even better) they need to be split off
into their own artifact (axis2-api?) that both transports and the mainline
axis2 code can depend on.

I would be emphatically against the idea of a "Maven-only" release.  That's
a stopgap measure, and it creates confusion for people coming into the
project (and being in the middle of this process myself, it's pretty
confusing as is).  If this is a problem, the time should be taken to solve
it correctly, else it's just going to get worse in the future.

- Jason 



> Hi folks:
> 
> So I'm trying to get the transports 1.0 releases moving along, and have run
> into a bit of a snag.  The transports depend on axis2-kernel SNAPSHOT, for
> interfaces like MessageContext, Flow, etc. - the problem is how do we do the
> release when we want to release the transports before the actual Axis2
> release?  We need to resolve all the SNAPSHOT dependencies for the Maven
> release plugin to be happy, and for this case, we seem to have a circular
> dependency chain. :(
> 
> A couple of options off the top of my head:
> 
> * Release transports against Axis2 1.4.1's kernel - this may not even be
> possible as there may have been incompatible changes.
> 
> * Do a Maven-only release of Axis2-kernel 1.5 - i.e. NOT a distribution but
> just a release into Maven.  Then use that for the Transports 1.0 releases,
> and then release the Axis2 1.5 distribution after that.
> 
> Moving forward, anyone have thoughts on how to best deal with this?  One of
> these options, or something else?
> 
> Thanks,
> --Glen