This is the mail archive of the kawa@sources.redhat.com mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Kawa configuration


Per Bothner wrote:

... Perhaps a cleaner solution to the JAXP 1.2 vs 1.3 incompatibility is
to use factory methods:

I think the Kawa classes just need to implement DOM3 methods and optionally implement the org.w3c interfaces.


abstract class KNode
/* BEGIN JAXP */
implements org.wc3.Node
/* END JAXP */

That could also be done this way:
/* BEGIN JAXP 1.2 */
// implements org.wc3.Node
/* END JAXP 1.2 */
/* BEGIN JAXP 1.3 */
implements org.wc3.Node
/* END JAXP 1.3 */

There is no need to omit DOM3 methods for DOM2 except where they depend on classes that are only in DOM3, as is already done:

  /* BEGIN JAXP 1.3+ */
  public TypeInfo getSchemaTypeInfo ()
  {
    return null;
  }
  /* END JAXP 1.3+ */

For a more general configuration mechanism, if the preprocessor could use class and method tests then fewer build switches could be used. So it could look like this:

abstract class KNode
/* #ifKawa classDefined("org.w3c.Node") */
implements org.wc3.Node
/* #endifKawa */

The test being relative to the build's target environment of course. This goes along with the "autoconfigure" approach.

The definition of the target environment is a little tricky. One scheme for that would be a classpath perhaps along with exclusion patterns ('omit "org.w3c.**"') to retain control over the autoconfiguration.

While the nice thing about this approach is that it eliminates the need to keep adding stuff to the common configuration, the down side is that there isn't an easy way to see what the target dependencies are. OTOH, a 'grep "#ifKawa" `find . -name "*java"` | sort -u' would provide a pretty good picture.

Jim


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]