I'm certainly OK with this as it seems to make a lot of sense to me. That said, not being a Woden user or anything, I'm not sure how many people use Woden. You may want to post a note to the users@ list as a quick poll to say "we're thinking of doing XYZ, how badly would you be affected" or something to see if any users would be overly concerned. I'm not saying we shouldn't do it if there ARE users, but it would at least be a data point to consider. If the only real "user" of Woden is Axis2, that's another good thing to know.
Dan On Saturday, June 23, 2012 09:25:15 PM Sagara Gunathunga 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 ! -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org