Andy, I have made the changes required to compile the HEAD branch of jakarta-tomcat-4.0 with either xerces-2_0_)_beta4, or with an earlier version. Based on this experience, I believe that you are oversimplifying the nature of the problem some people might have in implementing this switchover.
For any application (including Tomcat) that only uses an XML parser through the JAXP APIs, there are no code changes required. However, Tomcat (like *lots* of other packages that are built with Ant) uses Ant properties to define the pathname of the parser (typically with a property named "xerces.jar"). The assumption that there is only one necessary file is no longer true with beta4. Even though splitting the API classes away from the implementation is absolutely the right thing to do (having them together in xerces.jar is a major cause of class path problems for webapps), it is non-trivial to create a build environment that can adapt to *either* an old version or a new version of the packaging, unless you are pretty good at understanding conditionals in Ant scripts. If you get questions on how this can be done gracefully, feel free to point people at the Tomcat build system (particularly the file "catalina/build.xml" in the "jakarta-tomcat-4.0" repository). Craig McClanahan PS: At the present time, we are approaching a final release of Tomcat 4.0.2. My preference is to continue shipping Tomcat 4.0.x with the stable Xerces 1.4.4 release, rather than risk a disruptive change at this point in time. Therefore, I have *not* ported these changes to the CVS branch being used for that release (tomcat_40_branch). If Gump is trying to build this branch against Xerces 2.0.0beta4, it's going to continue to fail. On Mon, 28 Jan 2002, Andy Clark wrote: > Date: Mon, 28 Jan 2002 13:43:19 -0500 > From: Andy Clark <[EMAIL PROTECTED]> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [EMAIL PROTECTED], > [EMAIL PROTECTED], [EMAIL PROTECTED], > [EMAIL PROTECTED], [EMAIL PROTECTED], > [EMAIL PROTECTED] > Subject: [Xerces2] Stop the Release! -- ALL PROJECTS PLEASE READ > > Okay, perhaps "Stop the Release!" is a little harsh but I wanted to get > your attention. ;) > > After a long journey, Xerces 2.0.0 is scheduled to be released THIS > WEEK! Aren't you excited? I know I am. However... > > I believe that there are still a few things that need to be straightened > out *before* we release. First are the changes I have listed in my > previous message titled "[Xerces2] Missing API Changes". But also very > important is fixing (or getting a commitment to fix) the projects that > are still failing with the Xerces2 build as mentioned by Sam Ruby. Just > as a reminder, you can view the output of Gump using Xerces2 at the > following URL: > > http://nagoya.apache.org/~rubys/gump/xerces2/ > > I looked at a few of the offenders and, for the most part, it is more of > a simple oversight than a problem with Xerces2. (e.g. importing > org.apache.xerces.framework.XMLParser even though it no longer exists > and isn't even used in that source file.) This makes me feel better but > all of these reported failures are a big black eye that I would like to > be healed before we release. > > Therefore, I would like an immediate response from the following > projects regarding status, planned fix, etc. so that we can move forward > with the Xerces 2.0.0 (NON-BETA!!!) release: (These are the project > currently reporting errors from the latest Gump run. If the problem has > already been fixed, please disregard this message.) > > xml-batik > jakarta-turbine-torque > jakarta-turbine-2 > jakarta-avalon-cornerstone > jakarta-cactus-22 > jakarta-tomcat-4.0 > xml-security > > If you are involved with any of these projects, please look into the > errors reported by Gump and either fix it, if you can, or tell the > Xerces-J team what is wrong with the version 2 parser. And if you choose > the latter, please make your bug report correct and complete. Thanks! > > -AndyC > > P.S. Please reply to the [EMAIL PROTECTED] mailing list to > report status. > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
