Sound good, I will proceed with required changes. Thanks !
On Tue, Jun 26, 2012 at 3:06 AM, Andreas Veithen <[email protected]> wrote: > I think it makes sense to remove the Axiom support. There are two > reasons for that: > > 1. Axiom enables a couple of optimizations (deferred parsing, > pull-through and sourced elements) that don't exist in DOM. However, I > don't see how Woden (or code that uses Woden) would benefit from these > optimizations. > > 2. We have a DOM compatible Axiom implementation (although the level > of DOM compliance is currently not very high). Also, I think that at > some point in the future, the default Axiom implementation will > support DOM (with a decent level of compliance). > > Andreas > > On Sat, Jun 23, 2012 at 5:55 PM, Sagara Gunathunga > <[email protected]> wrote: >> Hi Devs, >> >> I'm thinking about future of Axiom (OM) based implementation of Woden >> API for sometime, whether we should continue or drop support from next >> release ? >> >> AFAIK original objective of OM implementation is to support Axis2 but >> in fact Axis2 never used OM implementation instead Axis2 still use DOM >> based implementation. Also in my POV there is no such drawbacks with >> DOM implementation to move Axis2 to use OM implementation. At the >> moment there is no clear indication about users of OM implementation >> too. In this situation it is kind of a overhead to maintain OM >> implementation further specially with small number of developers. At >> the beginning Woden had plans for number of cool features such as >> supporting to both WSDL versions etc, but all original developers have >> been disappeared from the community few years ago hence it's seem OK >> to re-prioritize objectives based on current requirements and >> resources. >> >> This also important decision to reduce complexities among Woden >> artifacts, at the moment it's required to have at least 3 JAR files >> to use Woden framework as woden-api, woden-impl-common and >> woden-impl-dom/woden-impl-om. Dropping OM implementation allows to >> merge these artifacts and deliver above 3 module as a single JAR file >> called woden.jar. IMO this kind of single artifact deliverables are >> more natural for utility projects and easy to deploy on OGSI >> containers too. >> >> Personally I don't have energy to maintain both implementations, also >> without actual users no point to maintain OM implementation further. >> Based on above facts I would like to suggest terminate OM support from >> next release and move forward the project with what ever the useful >> features. >> >> Any thoughts ? >> >> >> Thanks ! >> -- >> Sagara Gunathunga >> >> Blog - http://ssagara.blogspot.com >> Web - http://people.apache.org/~sagara/ >> LinkedIn - http://www.linkedin.com/in/ssagara >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Sagara Gunathunga Blog - http://ssagara.blogspot.com Web - http://people.apache.org/~sagara/ LinkedIn - http://www.linkedin.com/in/ssagara --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
