Hi Mukul, Does the Eclipse team have a plan for when they might reach API stability? Incompatible changes to an API are a pain for consumers and would prefer if we didn't start introducing code to cope with incompatible changes to the PsychoPath API.
I do think the instability is okay at the moment because we have not had a release yet and once we do it would be a "developer preview" where we warn our users that things can and will change in the future. We could just change our code to align with the updates to the API. However, once XML Schema 1.1 is included in a Xerces release from the main trunk I would hope that the PsychoPath API is stable and that the Eclipse team isn't changing it in the future in ways which could potentially break users. We're very careful about compatibility with our own APIs (e.g. XNI and XML Schema API) though I understand PsychoPath hasn't reached that level of maturity yet. Would also be nice if the API signatures stay compatible with Java 1.3 (i.e. don't have visible dependencies on classes / interfaces in JDK 1.4+) so that it's possible for us to make a final JDK 1.3 PsychoPath jar around the time of the first "production" release, but also allow users to obtain newer versions from eclipse.org which may have internal dependencies on Java 5+. Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [email protected] E-mail: [email protected] Mukul Gandhi <[email protected]> wrote on 09/21/2009 01:39:38 AM: > Hi all, > I have done some study yesterday and today, about what's currently > happening with PsychoPath APIs, and here are the issues I think, exist > with PsychoPath in relation to Xerces-J. > > The PsychoPath XPath 2.0 engine available with, Eclipse WTP 3.2M1 > milestone release, works fine with current Xerces-J SVN code. > (ref: http://download.eclipse.org/webtools/downloads/ > http://download.eclipse.org/webtools/downloads/drops/R3. > 2/S-3.2M1b-20090814143519/) > > PsychoPath with Eclipse WTP 3.2M1, has 96% spec compliance (ref: > http://intellectualcramps.blogspot.com/2009/08/psychopath-11m1-available.html > ). > > <problem> > The problem actually comes up with current PsychoPath development code > base, which will likely become part of Eclipse WTP 3.2M2 and > eventually, Eclipse WTP 3.2. > > The current PsychoPath development code base has made some API > changes, which are not compatible with the current Xerces-J SVN code. > Xerces-J assertions calls to PsychoPath APIs (on current PsychoPath > development code base, which I tested locally) give error, currently. > > At present, the impact of PsychoPath API changes are minor, to Xerces-J. > > for e.g, the following method call, in Xerces-J class > AbstractPsychoPathImpl.java: > nodeEvalRS.add(new ElementType(contextNode, > fDynamicContext.node_position(contextNode))); > > now needs to be written like: > nodeEvalRS.add(new ElementType(contextNode)); > > and this is the only problem, which Xerces-J currently has, to > integrate with the current PsychoPath development code. But in future, > PsychoPath might do widespread API changes, which we don't know at > present. > </problem> > > my simple question is, how should we handle these PsychoPath API > changes at Xerces-J end? Should we request PsychoPath project to do > something about this? Or can we (and how) handle this independently at > Xerces-J end? > > I suggest the option to use a system property with Xerces-J, to handle > this. But I am not sure, if that's good enough for this situation. > > Any opinions, please? > > > -- > Regards, > Mukul Gandhi > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected]
