[PROPOSAL] Moving Axis2 Transports to core

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

For various reasons, there have been no releases of the Axis2
Transports subproject since the migration of Axis/Axis2 to a TLP. To
change that situation I would like to propose to move that code to
Axis2 core, with the exception of the SMS transport (more on this
restriction later).

Doing this has a couple of advantages:

* All transports will be released together with every Axis2 release.
* Changes in ASF policies (related to the release process, branding
guidelines, etc.) no longer need to be implemented separately for
Axis2 Transports.
* For Axis2 core we manage at least one maintenance branch, and over
the last couple of years we have successfully produces several
maintenance releases from these branches. If we move the transports to
core, then they will also benefit from that.
* It eliminates the strange situation where the HTTP transport is
included in Axis2 core, but part of the unit tests are in Axis2
Transports.

The Axis2 Transports project is fairly easy to integrate into Axis2
core (in contrast to Rampart and Sandesha2, which is the reason these
projects are not included):

* The documentation has one page per transport. This makes it easy to
integrate it into the main site (and to set up the necessary redirects
from the old locations).
* With the exception of the SMS transport, only Apache controlled
Maven repositories are used. This is important because in the past,
there have been several occasions where the Axis2 core build broke
because of non Apache repositories. We must not allow that to happen
again in the future.
* With the exception of the SMS transport, the Axis2 Transport build
is very stable. It is as least as stable as the Axis2 core build. Only
the build of the SMS transport is not stable because it randomly fails
as described in TRANSPORTS-20 (which has been open for more than 2
years now).
* It takes less than 3 minutes to build Axis2 Transport. Therefore
moving that code to Axis2 core would only marginally increase the
build time.

The SMS transport would be moved later once the issues mentioned above
have been fixed. Note that after moving the other transports to Axis2
core we also have the option to merge these changes to the 1.6 branch
so that the Axis2 1.6.3 release would already contain them.

Andreas

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org

Re: [PROPOSAL] Moving Axis2 Transports to core

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

On Tue, Sep 11, 2012 at 7:06 PM, Hiranya Jayathilaka
<hi...@gmail.com> wrote:
> What about JIRA and other project resources? Are we going to get rid of the
> TRANSPORTS JIRA project and make it a component of the Axis2 JIRA project?

Versions in JIRA are defined at the project level. If we move the
transports to Axis2 core, they will have the same release cycle as the
rest of Axis2 and therefore use the same versions. Therefore it would
probably make the most sense to leave issues solved in Axis2
Transports 1.0.0 in the TRANSPORTS project and move unresolved issues
and issues solved only in trunk to the AXIS2 project.

> Thanks,
> Hiranya
>
> On Mon, Sep 10, 2012 at 5:21 AM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> For various reasons, there have been no releases of the Axis2
>> Transports subproject since the migration of Axis/Axis2 to a TLP. To
>> change that situation I would like to propose to move that code to
>> Axis2 core, with the exception of the SMS transport (more on this
>> restriction later).
>>
>> Doing this has a couple of advantages:
>>
>> * All transports will be released together with every Axis2 release.
>> * Changes in ASF policies (related to the release process, branding
>> guidelines, etc.) no longer need to be implemented separately for
>> Axis2 Transports.
>> * For Axis2 core we manage at least one maintenance branch, and over
>> the last couple of years we have successfully produces several
>> maintenance releases from these branches. If we move the transports to
>> core, then they will also benefit from that.
>> * It eliminates the strange situation where the HTTP transport is
>> included in Axis2 core, but part of the unit tests are in Axis2
>> Transports.
>>
>> The Axis2 Transports project is fairly easy to integrate into Axis2
>> core (in contrast to Rampart and Sandesha2, which is the reason these
>> projects are not included):
>>
>> * The documentation has one page per transport. This makes it easy to
>> integrate it into the main site (and to set up the necessary redirects
>> from the old locations).
>> * With the exception of the SMS transport, only Apache controlled
>> Maven repositories are used. This is important because in the past,
>> there have been several occasions where the Axis2 core build broke
>> because of non Apache repositories. We must not allow that to happen
>> again in the future.
>> * With the exception of the SMS transport, the Axis2 Transport build
>> is very stable. It is as least as stable as the Axis2 core build. Only
>> the build of the SMS transport is not stable because it randomly fails
>> as described in TRANSPORTS-20 (which has been open for more than 2
>> years now).
>> * It takes less than 3 minutes to build Axis2 Transport. Therefore
>> moving that code to Axis2 core would only marginally increase the
>> build time.
>>
>> The SMS transport would be moved later once the issues mentioned above
>> have been fixed. Note that after moving the other transports to Axis2
>> core we also have the option to merge these changes to the 1.6 branch
>> so that the Axis2 1.6.3 release would already contain them.
>>
>> Andreas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Hiranya Jayathilaka
> Mayhem Lab/RACE Lab;
> Dept. of Computer Science, UCSB;  http://cs.ucsb.edu
> E-mail: hiranya@cs.ucsb.edu;  Mobile: +1 (805) 895-7443
> Blog: http://techfeast-hiranya.blogspot.com

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org

Re: [PROPOSAL] Moving Axis2 Transports to core

[Hiranya Jayathilaka <hi...@gmail.com>]

What about JIRA and other project resources? Are we going to get rid of the
TRANSPORTS JIRA project and make it a component of the Axis2 JIRA project?

Thanks,
Hiranya

On Mon, Sep 10, 2012 at 5:21 AM, Andreas Veithen
<an...@gmail.com>wrote:

> For various reasons, there have been no releases of the Axis2
> Transports subproject since the migration of Axis/Axis2 to a TLP. To
> change that situation I would like to propose to move that code to
> Axis2 core, with the exception of the SMS transport (more on this
> restriction later).
>
> Doing this has a couple of advantages:
>
> * All transports will be released together with every Axis2 release.
> * Changes in ASF policies (related to the release process, branding
> guidelines, etc.) no longer need to be implemented separately for
> Axis2 Transports.
> * For Axis2 core we manage at least one maintenance branch, and over
> the last couple of years we have successfully produces several
> maintenance releases from these branches. If we move the transports to
> core, then they will also benefit from that.
> * It eliminates the strange situation where the HTTP transport is
> included in Axis2 core, but part of the unit tests are in Axis2
> Transports.
>
> The Axis2 Transports project is fairly easy to integrate into Axis2
> core (in contrast to Rampart and Sandesha2, which is the reason these
> projects are not included):
>
> * The documentation has one page per transport. This makes it easy to
> integrate it into the main site (and to set up the necessary redirects
> from the old locations).
> * With the exception of the SMS transport, only Apache controlled
> Maven repositories are used. This is important because in the past,
> there have been several occasions where the Axis2 core build broke
> because of non Apache repositories. We must not allow that to happen
> again in the future.
> * With the exception of the SMS transport, the Axis2 Transport build
> is very stable. It is as least as stable as the Axis2 core build. Only
> the build of the SMS transport is not stable because it randomly fails
> as described in TRANSPORTS-20 (which has been open for more than 2
> years now).
> * It takes less than 3 minutes to build Axis2 Transport. Therefore
> moving that code to Axis2 core would only marginally increase the
> build time.
>
> The SMS transport would be moved later once the issues mentioned above
> have been fixed. Note that after moving the other transports to Axis2
> core we also have the option to merge these changes to the 1.6 branch
> so that the Axis2 1.6.3 release would already contain them.
>
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>


-- 
Hiranya Jayathilaka
Mayhem Lab/RACE Lab;
Dept. of Computer Science, UCSB;  http://cs.ucsb.edu
E-mail: hiranya@cs.ucsb.edu <hi...@wso2.com>;  Mobile: +1 (805) 895-7443
Blog: http://techfeast-hiranya.blogspot.com

Re: [PROPOSAL] Moving Axis2 Transports to core

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

On Mon, Sep 10, 2012 at 3:45 PM, Sagara Gunathunga
<sa...@gmail.com> wrote:
>
>
> On Mon, Sep 10, 2012 at 5:51 PM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> For various reasons, there have been no releases of the Axis2
>> Transports subproject since the migration of Axis/Axis2 to a TLP. To
>> change that situation I would like to propose to move that code to
>> Axis2 core, with the exception of the SMS transport (more on this
>> restriction later).
>>
>> Doing this has a couple of advantages:
>>
>> * All transports will be released together with every Axis2 release.
>> * Changes in ASF policies (related to the release process, branding
>> guidelines, etc.) no longer need to be implemented separately for
>> Axis2 Transports.
>> * For Axis2 core we manage at least one maintenance branch, and over
>> the last couple of years we have successfully produces several
>> maintenance releases from these branches. If we move the transports to
>> core, then they will also benefit from that.
>> * It eliminates the strange situation where the HTTP transport is
>> included in Axis2 core, but part of the unit tests are in Axis2
>> Transports.
>>
>> The Axis2 Transports project is fairly easy to integrate into Axis2
>> core (in contrast to Rampart and Sandesha2, which is the reason these
>> projects are not included):
>>
>> * The documentation has one page per transport. This makes it easy to
>> integrate it into the main site (and to set up the necessary redirects
>> from the old locations).
>> * With the exception of the SMS transport, only Apache controlled
>> Maven repositories are used. This is important because in the past,
>> there have been several occasions where the Axis2 core build broke
>> because of non Apache repositories. We must not allow that to happen
>> again in the future.
>> * With the exception of the SMS transport, the Axis2 Transport build
>> is very stable. It is as least as stable as the Axis2 core build. Only
>> the build of the SMS transport is not stable because it randomly fails
>> as described in TRANSPORTS-20 (which has been open for more than 2
>> years now).
>> * It takes less than 3 minutes to build Axis2 Transport. Therefore
>> moving that code to Axis2 core would only marginally increase the
>> build time.
>
>
>  +1
>  In fact sometimes back I discussed same suggestion with few people.
>
>>
>>
>> The SMS transport would be moved later once the issues mentioned above
>> have been fixed. Note that after moving the other transports to Axis2
>> core we also have the option to merge these changes to the 1.6 branch
>> so that the Axis2 1.6.3 release would already contain them.
>
>
> My only concern is can't we have any good solution for SMS transports ?
>
> Last two years no one works on SMS transport hence I don't think
> TRANSPORTS-20 will resolve in near future. May be if we left it till
> TRANSPORTS-20 get resolved there is a chance that SMS transport will never
> integrate to core.  But in fact other than random build fails occurred in
> time to time there is no functional or usability issue with it.
>

There is indeed a risk that this will happen, but this would probably
mean that we neither have users nor active developers for the SMS
transport. If we do have users for the SMS transport and we release
Axis2 without the SMS transport they will likely complain, and that
may give the motivation to some people to do the necessary steps to
stabilize the build of that code.

>
> Thanks !
>
>
>
>>
>>
>> Andreas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Sagara Gunathunga
>
> Blog      - http://ssagara.blogspot.com
> Web      - http://people.apache.org/~sagara/
> LinkedIn - http://www.linkedin.com/in/ssagara

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org

Re: [PROPOSAL] Moving Axis2 Transports to core

[Sagara Gunathunga <sa...@gmail.com>]

On Mon, Sep 10, 2012 at 5:51 PM, Andreas Veithen
<an...@gmail.com>wrote:

> For various reasons, there have been no releases of the Axis2
> Transports subproject since the migration of Axis/Axis2 to a TLP. To
> change that situation I would like to propose to move that code to
> Axis2 core, with the exception of the SMS transport (more on this
> restriction later).
>
> Doing this has a couple of advantages:
>
> * All transports will be released together with every Axis2 release.
> * Changes in ASF policies (related to the release process, branding
> guidelines, etc.) no longer need to be implemented separately for
> Axis2 Transports.
> * For Axis2 core we manage at least one maintenance branch, and over
> the last couple of years we have successfully produces several
> maintenance releases from these branches. If we move the transports to
> core, then they will also benefit from that.
> * It eliminates the strange situation where the HTTP transport is
> included in Axis2 core, but part of the unit tests are in Axis2
> Transports.
>
> The Axis2 Transports project is fairly easy to integrate into Axis2
> core (in contrast to Rampart and Sandesha2, which is the reason these
> projects are not included):
>
> * The documentation has one page per transport. This makes it easy to
> integrate it into the main site (and to set up the necessary redirects
> from the old locations).
> * With the exception of the SMS transport, only Apache controlled
> Maven repositories are used. This is important because in the past,
> there have been several occasions where the Axis2 core build broke
> because of non Apache repositories. We must not allow that to happen
> again in the future.
> * With the exception of the SMS transport, the Axis2 Transport build
> is very stable. It is as least as stable as the Axis2 core build. Only
> the build of the SMS transport is not stable because it randomly fails
> as described in TRANSPORTS-20 (which has been open for more than 2
> years now).
> * It takes less than 3 minutes to build Axis2 Transport. Therefore
> moving that code to Axis2 core would only marginally increase the
> build time.
>

 +1
 In fact sometimes back I discussed same suggestion with few people.


>
> The SMS transport would be moved later once the issues mentioned above
> have been fixed. Note that after moving the other transports to Axis2
> core we also have the option to merge these changes to the 1.6 branch
> so that the Axis2 1.6.3 release would already contain them.
>

My only concern is can't we have any good solution for SMS transports ?

Last two years no one works on SMS transport hence I don't think
TRANSPORTS-20 will resolve in near future. May be if we left it till
TRANSPORTS-20 get resolved there is a chance that SMS transport will never
integrate to core.  But in fact other than random build fails occurred in
time to time there is no functional or usability issue with it.


Thanks !




>
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>


-- 
Sagara Gunathunga

Blog      - http://ssagara.blogspot.com
Web      - http://people.apache.org/~sagara/
LinkedIn - http://www.linkedin.com/in/ssagara