ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Gainty <>
Subject RE: [WODEN] Future of Woden Axiom implementation ?
Date Wed, 27 Jun 2012 10:43:41 GMT

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 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

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:
> To:
> 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
> <> 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      -
> > Web      -
> > LinkedIn -
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> -- 
> 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:
> For additional commands, e-mail:
View raw message