Hello Jochen apparently I am the only person that has implemented axiom in a live commercial implementation so clearly i hold a minority opinion
I agree there are alot more constructive use of devs time and effort than say pulling an dependent subsystem but if every enhancement forces you to duplicate every dom integration effort with woden integration then a strong case can be made to the panelists to support the stronger more stable subsystem and drop support for the dupe subsystem (best if we could see see a matrix to verify woden and dom featuresets are indeed identical) On a side note here is what I see are Axis 3 main drawbacks in order of priority 1)antiquated use of build.xml in build scripts instead of refactoring all builds to version aware SCM e.g. maven (3)..server and client scripts are all ant based.. 2)lack of esb 3)process lacks adherence to apache vote by democracy rules..one person says 'do it' and then another makes vast sweeping changes to working code without bothering to put the effort to a vote (majority wins) for a fixed period of time (usually 72 hours)..sagara has graciously revived the apache process with his request for comment on deprecating woden Granted alot of people are going on vaca now (including myself) so resources (peoples time to research,design and code, test and integrate) are limited but we need to address the axis2 community collectively to gain consensus for each effort before committing sweeping changes The end result *should be* increased adoption of Axis2 in the SAAS community WDYT Martin ______________________________________________ Verzicht und Vertraulichkeitanmerkung Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. > Date: Wed, 27 Jun 2012 09:45:38 +0200 > Subject: Re: [WODEN] Future of Woden Axiom implementation ? > From: [email protected] > To: [email protected] > > Question: Are there any ongoing developments: If not, I'd say we leave > the code and avoid annoying potential users. > > Otherwise: If we might save work ourselves, drop it. (Don't forget to > increment the major version number and possibly change Maven GID and > package to indicate incompatible changes.) > > > 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] > > > > > > -- > In other words: what could be seen as a socially debilitating failure > of character can certainly work to your advantage too. (Linus > Torvalds, but the use in the signature tells something about me as > well.) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
