Hi Edwin,
Thanks for the correction and for pointing out the wrong location of the
resource files. I'll rework the build file to make sure those files are in
the implementation jar instead of the API jar.
As to the Netscape 4.7 issue, we can add a note to the docs--which I also
need to update to reflect the change in packaging--to inform people of the
workaround of using the "oldjars" build target to get the old-style unified
jar file.
Is there a complete list of environments in which this might be an issue?
If there isn't we can make one as bugs get reported.
As to mixed-case filenames, the reason we picked this one is that it's
shorter than using dashes to separate name components, follows the Java
naming convention, and is consistent with the xercesSamples jar that we've
produced forever and that no one has complained about to my knowledge.
Cheers,
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
Edwin Goei <[EMAIL PROTECTED]> on 11/26/2001 09:31:48 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: Re: [xerces2] info about some packaging changes
[EMAIL PROTECTED] wrote:
>
> [snip]
>
> However, from the standpoint of a user wishing to use DOM level 3
> interfaces or methods this does have two downsides.
> First, it means that a lot of casting will need to be done:
> DOM's methods return DOM level 2 objects; e.g.,
> Node.getOwnerDocument() returns an org.w3c.dom.Document, so if
> you want the DOM level three version, you'll have to explicitly
> cast this to org.apache.xerces.dom3.Document3. Secondly,
> once DOM level 3 becomes a standard and is incorporated into
> Sun's certification suites etc., applications using our
> repackaged DOM level 3 support will need to be modified so that
> they use the org.apache.dom packages. This wouldn't appear to be
^^^^^^^
Probably mean "org.w3c.dom" package here.
> a very big problem--it will require the modification of some
> import statements and variable declarations, but that should be
> it.
>
> [snip]
>
> For those concerned about names: we thought we'd call the new
> implementation-specific jarfile xercesImpl.jar, so as to
> distinguish it from the xerces.jar that contains everything. The
> API file we thought could be called xmlParserAPIs.jar, since it
> contains only API's related to XML parsing.
>
> We'd definitely love feedback on these proposals. I've got the
> necessary buildfile changes on my local machine, and I'd like to
> commit them quickly; so if anyone has any really serious
> reservations about the API reorganization, please speak up now!
Sorry, I was out b/c of Thanksgiving so only am now reading your email.
I've got a couple comments:
1) It looks like the META-INF/ directory got placed under the API jar
file and not the implementation jar file. The JAXP javax.xml.parsers.*
resource files are supposed to go in the implementation jar file. This
allows one to take the implementation jar file and put it on the
classpath of JDK 1.4, for example to use Xerces2 as the implementation.
BTW, there is still an unresolved issue using split jar files when
running as an applet on native VMs such as Netscape 4.7. For some
reason, code in one jarfile cannot read a resource in another jar file.
2) Are the mixed case jar file names going to cause problems on some
platforms like DOS?
-Edwin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
