This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: Kawa configuration
- From: Jim White <jim at pagesmiths dot com>
- To: Per Bothner <per at bothner dot com>
- Cc: kawa at sources dot redhat dot com, qexo-general at gnu dot org
- Date: Thu, 14 Apr 2005 12:32:54 -0700
- Subject: Re: Kawa configuration
- References: <425EB6F7.3020507@bothner.com>
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