You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Glen Daniels <gl...@thoughtcraft.com> on 2007/04/07 14:38:14 UTC
[axis2] Changes on the 1_2 branch
Hi all:
Just checking in - is everyone who's making changes on the 1_2 branch
merging them over to the trunk? We don't want to fix bugs only on the
branch, lest they come back to bite us later down the line....
If you've made fixes for the release and HAVEN'T yet merged them over,
please consider doing so soon. Otherwise, please ignore this friendly
reminder.
Thanks,
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Changes on the 1_2 branch (VOTE)
Posted by Jeremy Hughes <hu...@apache.org>.
Hi, sorry, I've been away from the list. Thanks for expanding on this
and yes I guess we don't want to *rely* on non-committers in order
that we can close off JIRAs. Getting their feedback is of course
useful.
I'm +1. I have a comment though:
On 14/04/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
[...]
> This way the only times we make fixes directly on the release branch are
> as follows:
>
> * For release-specific fixes (references to version number, taking out
> SNAPSHOTs, release notes, etc)
>
> * For post-release bug fixes - IF the trunk has moved on in an
> incompatible way (if the bug hasn't been fixed on trunk it should as per
> usual be fixed there first and merged)
If a user requires a fix in a branch surely they'll require it there
whether it is compatible with the trunk or not. In fact I thought the
release branches are typically closed once the release is out, then
the trunk is used for the next release.
>
> Otherwise, everything that goes into the release branch should be a
> merge over from the trunk.
>
> Sound reasonable?
Sounds good. I think this will give more flexibility in the timing of
taking a branch from the trunk to do a release. History has shown the
branch stays alive for longer than expected. Tracking which branches a
fix goes to will hopefully prevent the need for a 'big merge' back to
trunk - which is never pleasant.
Thanks,
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Changes on the 1_2 branch (VOTE)
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Axis-dev'ers:
Any commentary on this? Votes?
--Glen
Glen Daniels wrote:
> Hi Folks:
>
> Sanjiva Weerawarana wrote:
>> That's a **itload of work for the RM to have to do this for each and
>> every fix going into the trunk. I don't see this as a scalable
>> proposition.
>
> I agree that the RM shouldn't be the one to do the merge - the person
> who makes the fix should be responsible for merging. That way the
> person most familiar with the code does the work on both branches.
>
> However, the RM might want to be the "gateway" for permission to do the
> merge. We can start out with people just using their discretion as to
> whether or not to merge, and if that becomes problematic we can throttle
> it down via the RM.
>
> So the current proposal as I see it is:
>
> 1. RM goes through JIRA and sets "fix for" to point to both "NIGHTLY"
> and the new branched release number for the fixes that are still
> targeted for the release after branch is cut.
>
> 2. Asignee/coder fixes JIRA issues or makes other changes *on the
> trunk*. If JIRA is set to branched release as target, or upon coder's
> discretion, they then merge the fix over to the release branch.
>
> 3. When Asignee resolves JIRA, they confirm it's been fixed in both
> branches, if appropriate.
>
> This way the only times we make fixes directly on the release branch are
> as follows:
>
> * For release-specific fixes (references to version number, taking out
> SNAPSHOTs, release notes, etc)
>
> * For post-release bug fixes - IF the trunk has moved on in an
> incompatible way (if the bug hasn't been fixed on trunk it should as per
> usual be fixed there first and merged)
>
> Otherwise, everything that goes into the release branch should be a
> merge over from the trunk.
>
> Sound reasonable?
>
> --Glen
>
>> Davanum Srinivas wrote:
>>> Yes, trunk first and then branch later seems the right thing to do.
>>> The RM can choose which fixes go into branch.
>>>
>>> thanks,
>>> -- dims
>>>
>>> On 4/14/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
>>>> Hi Afkham!
>>>>
>>>> Afkham Azeez wrote:
>>>> > Do the fixes in the branch need to be necessarily carried out on the
>>>> > trunk as well. I'm asking this since we'd be merging the code in the
>>>> > branch with the trunk eventually.
>>>>
>>>> The problem is that the longer we go without merging, the more
>>>> likely it
>>>> is we'll have conflicts, or heaven forbid fix the same problem twice
>>>> (if
>>>> someone working on trunk hasn't noticed that the bug has been fixed on
>>>> the branch, say). It also becomes much more of a pain to have one
>>>> person do a giant merge where they don't necessarily have intimate
>>>> knowledge of all the conflicts, as opposed to the people making the
>>>> individual fixes simply merge them over when they're fresh in the mind.
>>>>
>>>> Also, we always want the trunk to carry the latest fixes and
>>>> improvements so people can move forward there without having to wait
>>>> for
>>>> a big post-release merge to pick up fixes. In fact, I think it likely
>>>> makes the most sense to fix bugs on the trunk *first*, and then merge
>>>> those changes over to the release branch, rather than the other way
>>>> around.
>>>>
>>>> --Glen
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Changes on the 1_2 branch (VOTE)
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Folks:
Sanjiva Weerawarana wrote:
> That's a **itload of work for the RM to have to do this for each and
> every fix going into the trunk. I don't see this as a scalable proposition.
I agree that the RM shouldn't be the one to do the merge - the person
who makes the fix should be responsible for merging. That way the
person most familiar with the code does the work on both branches.
However, the RM might want to be the "gateway" for permission to do the
merge. We can start out with people just using their discretion as to
whether or not to merge, and if that becomes problematic we can throttle
it down via the RM.
So the current proposal as I see it is:
1. RM goes through JIRA and sets "fix for" to point to both "NIGHTLY"
and the new branched release number for the fixes that are still
targeted for the release after branch is cut.
2. Asignee/coder fixes JIRA issues or makes other changes *on the
trunk*. If JIRA is set to branched release as target, or upon coder's
discretion, they then merge the fix over to the release branch.
3. When Asignee resolves JIRA, they confirm it's been fixed in both
branches, if appropriate.
This way the only times we make fixes directly on the release branch are
as follows:
* For release-specific fixes (references to version number, taking out
SNAPSHOTs, release notes, etc)
* For post-release bug fixes - IF the trunk has moved on in an
incompatible way (if the bug hasn't been fixed on trunk it should as per
usual be fixed there first and merged)
Otherwise, everything that goes into the release branch should be a
merge over from the trunk.
Sound reasonable?
--Glen
> Davanum Srinivas wrote:
>> Yes, trunk first and then branch later seems the right thing to do.
>> The RM can choose which fixes go into branch.
>>
>> thanks,
>> -- dims
>>
>> On 4/14/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
>>> Hi Afkham!
>>>
>>> Afkham Azeez wrote:
>>> > Do the fixes in the branch need to be necessarily carried out on the
>>> > trunk as well. I'm asking this since we'd be merging the code in the
>>> > branch with the trunk eventually.
>>>
>>> The problem is that the longer we go without merging, the more likely it
>>> is we'll have conflicts, or heaven forbid fix the same problem twice (if
>>> someone working on trunk hasn't noticed that the bug has been fixed on
>>> the branch, say). It also becomes much more of a pain to have one
>>> person do a giant merge where they don't necessarily have intimate
>>> knowledge of all the conflicts, as opposed to the people making the
>>> individual fixes simply merge them over when they're fresh in the mind.
>>>
>>> Also, we always want the trunk to carry the latest fixes and
>>> improvements so people can move forward there without having to wait for
>>> a big post-release merge to pick up fixes. In fact, I think it likely
>>> makes the most sense to fix bugs on the trunk *first*, and then merge
>>> those changes over to the release branch, rather than the other way
>>> around.
>>>
>>> --Glen
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>>
>>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Changes on the 1_2 branch (VOTE)
Posted by Davanum Srinivas <da...@gmail.com>.
I guess, we need to cut the branch only at the last minute?
-- dims
On 4/14/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> That's a **itload of work for the RM to have to do this for each and every
> fix going into the trunk. I don't see this as a scalable proposition.
>
> Sanjiva.
>
> Davanum Srinivas wrote:
> > Yes, trunk first and then branch later seems the right thing to do.
> > The RM can choose which fixes go into branch.
> >
> > thanks,
> > -- dims
> >
> > On 4/14/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
> >> Hi Afkham!
> >>
> >> Afkham Azeez wrote:
> >> > Do the fixes in the branch need to be necessarily carried out on the
> >> > trunk as well. I'm asking this since we'd be merging the code in the
> >> > branch with the trunk eventually.
> >>
> >> The problem is that the longer we go without merging, the more likely it
> >> is we'll have conflicts, or heaven forbid fix the same problem twice (if
> >> someone working on trunk hasn't noticed that the bug has been fixed on
> >> the branch, say). It also becomes much more of a pain to have one
> >> person do a giant merge where they don't necessarily have intimate
> >> knowledge of all the conflicts, as opposed to the people making the
> >> individual fixes simply merge them over when they're fresh in the mind.
> >>
> >> Also, we always want the trunk to carry the latest fixes and
> >> improvements so people can move forward there without having to wait for
> >> a big post-release merge to pick up fixes. In fact, I think it likely
> >> makes the most sense to fix bugs on the trunk *first*, and then merge
> >> those changes over to the release branch, rather than the other way
> >> around.
> >>
> >> --Glen
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-dev-help@ws.apache.org
> >>
> >>
> >
> >
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Director; Open Source Initiative; http://www.opensource.org/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Changes on the 1_2 branch (VOTE)
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
That's a **itload of work for the RM to have to do this for each and every
fix going into the trunk. I don't see this as a scalable proposition.
Sanjiva.
Davanum Srinivas wrote:
> Yes, trunk first and then branch later seems the right thing to do.
> The RM can choose which fixes go into branch.
>
> thanks,
> -- dims
>
> On 4/14/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
>> Hi Afkham!
>>
>> Afkham Azeez wrote:
>> > Do the fixes in the branch need to be necessarily carried out on the
>> > trunk as well. I'm asking this since we'd be merging the code in the
>> > branch with the trunk eventually.
>>
>> The problem is that the longer we go without merging, the more likely it
>> is we'll have conflicts, or heaven forbid fix the same problem twice (if
>> someone working on trunk hasn't noticed that the bug has been fixed on
>> the branch, say). It also becomes much more of a pain to have one
>> person do a giant merge where they don't necessarily have intimate
>> knowledge of all the conflicts, as opposed to the people making the
>> individual fixes simply merge them over when they're fresh in the mind.
>>
>> Also, we always want the trunk to carry the latest fixes and
>> improvements so people can move forward there without having to wait for
>> a big post-release merge to pick up fixes. In fact, I think it likely
>> makes the most sense to fix bugs on the trunk *first*, and then merge
>> those changes over to the release branch, rather than the other way
>> around.
>>
>> --Glen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>
>
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Changes on the 1_2 branch (VOTE)
Posted by Davanum Srinivas <da...@gmail.com>.
Yes, trunk first and then branch later seems the right thing to do.
The RM can choose which fixes go into branch.
thanks,
-- dims
On 4/14/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi Afkham!
>
> Afkham Azeez wrote:
> > Do the fixes in the branch need to be necessarily carried out on the
> > trunk as well. I'm asking this since we'd be merging the code in the
> > branch with the trunk eventually.
>
> The problem is that the longer we go without merging, the more likely it
> is we'll have conflicts, or heaven forbid fix the same problem twice (if
> someone working on trunk hasn't noticed that the bug has been fixed on
> the branch, say). It also becomes much more of a pain to have one
> person do a giant merge where they don't necessarily have intimate
> knowledge of all the conflicts, as opposed to the people making the
> individual fixes simply merge them over when they're fresh in the mind.
>
> Also, we always want the trunk to carry the latest fixes and
> improvements so people can move forward there without having to wait for
> a big post-release merge to pick up fixes. In fact, I think it likely
> makes the most sense to fix bugs on the trunk *first*, and then merge
> those changes over to the release branch, rather than the other way around.
>
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Changes on the 1_2 branch (VOTE)
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Afkham!
Afkham Azeez wrote:
> Do the fixes in the branch need to be necessarily carried out on the
> trunk as well. I'm asking this since we'd be merging the code in the
> branch with the trunk eventually.
The problem is that the longer we go without merging, the more likely it
is we'll have conflicts, or heaven forbid fix the same problem twice (if
someone working on trunk hasn't noticed that the bug has been fixed on
the branch, say). It also becomes much more of a pain to have one
person do a giant merge where they don't necessarily have intimate
knowledge of all the conflicts, as opposed to the people making the
individual fixes simply merge them over when they're fresh in the mind.
Also, we always want the trunk to carry the latest fixes and
improvements so people can move forward there without having to wait for
a big post-release merge to pick up fixes. In fact, I think it likely
makes the most sense to fix bugs on the trunk *first*, and then merge
those changes over to the release branch, rather than the other way around.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Changes on the 1_2 branch (VOTE)
Posted by Afkham Azeez <af...@gmail.com>.
Do the fixes in the branch need to be necessarily carried out on the trunk
as well. I'm asking this since we'd be merging the code in the branch with
the trunk eventually.
-- Azeez
On 4/13/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
>
> Hi Jeremy!
>
> This sounds like a great policy to me. Can we VOTE on this and then
> make sure we get a serious "Developer Guidelines" page on the website
> (right now that link just gets you a mail guidelines page), including
> this, coding conventions, build policies, etc...?
>
> I'd remove the third bullet though. I don't think we want to put that
> much responsibility on the reporter - they're not necessarily Axis2
> developers, they might just be poor users with bugs. The reporter
> should check that the version they're using has been fixed and the
> assignee should have already taken care of any cross-branch merging
> before resolving the issue. I don't ever want to get into a situation
> where we blame someone who's not on the team for not verifying something.
> :)
>
> That said, +1 from me!
>
> --Glen
>
> Jeremy Hughes wrote:
> > Just a thought ... could JIRA be used in a way that means we can see
> > that fixes put into a branch have also gone into the trunk, rather
> > than assuming it. e.g. for a JIRA that needs to be fixed in 1.2 branch
> > and trunk, set the 'fix for' field of the JIRA to be both "1.2" and
> > "nightly" (which I assume represents trunk). Then ...
> >
> > * It's the RM's responsibility to ensure all the JIRA's being fixed in
> > 1.2 have both "1.2" and "nightly" values in the 'fix for' field.
> > * It's the assignee's responsibility to check in the fix to all the
> > branches in the 'fix for' field.
> > * It's the reporter's responsibility when closing the JIRA to check
> > that the fix has been checked in to all the branches in the 'fix for'
> > field.
> >
> > Any thoughts?
> >
> > Cheers,
> > Jeremy
> >
> > On 07/04/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
> >> Hi all:
> >>
> >> Just checking in - is everyone who's making changes on the 1_2 branch
> >> merging them over to the trunk? We don't want to fix bugs only on the
> >> branch, lest they come back to bite us later down the line....
> >>
> >> If you've made fixes for the release and HAVEN'T yet merged them over,
> >> please consider doing so soon. Otherwise, please ignore this friendly
> >> reminder.
> >>
> >> Thanks,
> >> --Glen
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-dev-help@ws.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Thanks
Afkham Azeez
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: [axis2] Changes on the 1_2 branch (VOTE)
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Jeremy!
This sounds like a great policy to me. Can we VOTE on this and then
make sure we get a serious "Developer Guidelines" page on the website
(right now that link just gets you a mail guidelines page), including
this, coding conventions, build policies, etc...?
I'd remove the third bullet though. I don't think we want to put that
much responsibility on the reporter - they're not necessarily Axis2
developers, they might just be poor users with bugs. The reporter
should check that the version they're using has been fixed and the
assignee should have already taken care of any cross-branch merging
before resolving the issue. I don't ever want to get into a situation
where we blame someone who's not on the team for not verifying something. :)
That said, +1 from me!
--Glen
Jeremy Hughes wrote:
> Just a thought ... could JIRA be used in a way that means we can see
> that fixes put into a branch have also gone into the trunk, rather
> than assuming it. e.g. for a JIRA that needs to be fixed in 1.2 branch
> and trunk, set the 'fix for' field of the JIRA to be both "1.2" and
> "nightly" (which I assume represents trunk). Then ...
>
> * It's the RM's responsibility to ensure all the JIRA's being fixed in
> 1.2 have both "1.2" and "nightly" values in the 'fix for' field.
> * It's the assignee's responsibility to check in the fix to all the
> branches in the 'fix for' field.
> * It's the reporter's responsibility when closing the JIRA to check
> that the fix has been checked in to all the branches in the 'fix for'
> field.
>
> Any thoughts?
>
> Cheers,
> Jeremy
>
> On 07/04/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
>> Hi all:
>>
>> Just checking in - is everyone who's making changes on the 1_2 branch
>> merging them over to the trunk? We don't want to fix bugs only on the
>> branch, lest they come back to bite us later down the line....
>>
>> If you've made fixes for the release and HAVEN'T yet merged them over,
>> please consider doing so soon. Otherwise, please ignore this friendly
>> reminder.
>>
>> Thanks,
>> --Glen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Changes on the 1_2 branch
Posted by Jeremy Hughes <hu...@apache.org>.
Just a thought ... could JIRA be used in a way that means we can see
that fixes put into a branch have also gone into the trunk, rather
than assuming it. e.g. for a JIRA that needs to be fixed in 1.2 branch
and trunk, set the 'fix for' field of the JIRA to be both "1.2" and
"nightly" (which I assume represents trunk). Then ...
* It's the RM's responsibility to ensure all the JIRA's being fixed in
1.2 have both "1.2" and "nightly" values in the 'fix for' field.
* It's the assignee's responsibility to check in the fix to all the
branches in the 'fix for' field.
* It's the reporter's responsibility when closing the JIRA to check
that the fix has been checked in to all the branches in the 'fix for'
field.
Any thoughts?
Cheers,
Jeremy
On 07/04/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi all:
>
> Just checking in - is everyone who's making changes on the 1_2 branch
> merging them over to the trunk? We don't want to fix bugs only on the
> branch, lest they come back to bite us later down the line....
>
> If you've made fixes for the release and HAVEN'T yet merged them over,
> please consider doing so soon. Otherwise, please ignore this friendly
> reminder.
>
> Thanks,
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org