That seems like an odd policy to me. Once a project is separated out (was Axiom part of Axis2 like XmlSchema?) from Axis2 or any other project Axis2 then becomes a consumer of the project. To tell someone that they can't make a change to Axiom because Axis is shutting down seems like a dangerous precedent to set. It doesn't seem practical for developers working on one project to have to follow the development schedule of another project they may not be interested in. Exploding this out, how would this work if 5 projects relied on Axiom? Would changes ever be able to be made to the Axiom code and would the project simply be killed by the overhead of consulting all the consuming projects before making changes?
As I'm told, the policy in WS is release early and release often. I think this policy can work but does need some coordination of the projects beforehand. For example, how about mapping out, if only a month or two in advance, a release of Axiom that will be used for Axis2. That way Axiom developers should know not to make breaking changes as the release cycle approaches the end. As well, Axis2 doesn't have to use the latest snapshot at all times as it's trying to stabilize. Updating the snapshot on a less frequent basis may allow you to make more progress in light of breaking changes. Alternatively, Axiom can branch to allow development to continue while Axis2 shuts down.
Just my 2 cents coming from my experience working at Eclipse. (If you're interested in taking a look at what Eclipse is doing about the dependencies between projects take a look at [1].) Feel free to tell me I'm way off base or shout out alternate/better solutions.
Lawrence Mandel
[1] http://www.eclipse.org/projects/callisto.php
| Eran Chinthaka <[EMAIL PROTECTED]>
04/24/2006 01:59 AM
|
|
Hi,
I hope we made a clear statement saying, if some one is changing
something in axis2 related ws-commons project, he/she needs to check at
least Axis2 whether its fine or not. But this particular commit breaks
Axis2 build.
As you all might know we are in the process of releasing Axis2 1.0 and
we are really busy with the important issues related to 1.0. We can not
continue with work related to Axis2 1.0 when the build is failing.
So the only option for me here is to revert this particular commit to
proceed with Axis2.
Glen, please review this and commit this when you are sure that Axis2
build is successful. And please do not commit anything without checking
Axis2 as well, a humble request.
-- Chinthaka
[EMAIL PROTECTED] wrote:
> Author: gdaniels
> Date: Mon Apr 24 09:15:24 2006
> New Revision: 396597
>
> URL: http://svn.apache.org/viewcvs?rev=396597&view=rev
> Log:
> Ensure default SOAPEnvelope has a valid parent (Synapse's XPath mediator needs this)
>
> Modified:
> webservices/commons/trunk/modules/axiom/src/org/apache/axiom/soap/impl/llom/soap11/SOAP11Factory.java
>
> Modified: webservices/commons/trunk/modules/axiom/src/org/apache/axiom/soap/impl/llom/soap11/SOAP11Factory.java
> URL: http://svn.apache.org/viewcvs/webservices/commons/trunk/modules/axiom/src/org/apache/axiom/soap/impl/llom/soap11/SOAP11Factory.java?rev=396597&r1=396596&r2=396597&view=diff
> ==============================================================================
> --- webservices/commons/trunk/modules/axiom/src/org/apache/axiom/soap/impl/llom/soap11/SOAP11Factory.java (original)
> +++ webservices/commons/trunk/modules/axiom/src/org/apache/axiom/soap/impl/llom/soap11/SOAP11Factory.java Mon Apr 24 09:15:24 2006
> @@ -272,6 +272,8 @@
> SOAPEnvelopeImpl env = new SOAPEnvelopeImpl(ns, this);
> createSOAPHeader(env);
> createSOAPBody(env);
> + SOAPMessageImpl msg = new SOAPMessageImpl();
> + msg.setSOAPEnvelope(env);
> return env;
> }
>
>
>
>
