Re: Is Compile Failure? was Re: Need some clarifications
Steve Downey wrote: On Thursday 03 October 2002 12:14 pm, Henri Gomez wrote: Steve Downey wrote: Actually, with the recent release of commons-logging, we should be able to get rid of the explicit LogKit and Log4J. They're there so as to get a complete build of commons-logging. Tomcat 5 itself doesn't use either directly. Xerces is a different issue. There was a bug that was preventing Tomcat from migrating to the latest version. Unfortunately, I no longer remember the details. Anyone know why we're using 2.1.0 instead of 2.2.0? From what I experienced with Xerces j 2.2.0 it seems it does much more validity check and for instance found a '--' somewhere in comments (1 EUR to the first who find where). Previous version of Xerces or crimson didn't got that problem. if we could see which xml/dtd/tld is reported buggy, which will able to see if it's a bug or a features (ie a more strict check of xml rules) OK, from the 'this shouldn't work department', this patch 'fixes' the problem: Index: ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 web-jsptaglibrary_1_2.dtd --- ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd13 Aug 2002 16:20:58 - 1.1.1.1 +++ ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd3 Oct 2002 20:42:30 - @@ -304,6 +304,7 @@ java.lang.String is default. declare Whether the variable is declared or not. + True is the default. scopeThe scope of the scripting varaible Something quite strange is going on. You just add an empty line in this dtd and it works now ? I was thinking it could be with -- in some dtd, ie line in web-app_2_3.dtd : !-- Copyright 2000-2001 Sun Microsystems, Inc. 901 San Antonio Road, Palo Alto, CA 94303, U.S.A. All rights reserved. This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or documentation may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Third party software, including font technology, is copyrighted and licensed from Sun suppliers. Sun, Sun Microsystems, the Sun Logo, Solaris, Java, JavaServer Pages, Java Naming and Directory Interface, JDBC, JDK, JavaMail and Enterprise JavaBeans, are trademarks or registered trademarks of Sun Microsystems, Inc in the U.S. and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. PostScript is a registered trademark of Adobe Systems, Inc. Federal Acquisitions: Commercial Software - Government Users Subject to Standard License Terms and Conditions. DOCUMENTATION IS PROVIDED AS IS AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. _ Copyright 2000-2001 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303, Etats-Unis. Tous droits re'serve's. Ce produit ou document est prote'ge' par un copyright et distribue' avec des licences qui en restreignent l'utilisation, la copie, la distribution, et la de'compilation. Aucune partie de ce produit ou de sa documentation associe'e ne peut e^tre reproduite sous aucune forme, par quelque moyen que ce soit, sans l'autorisation pre'alable et e'crite de Sun et de ses bailleurs de licence, s'il y en a. Le logiciel de'tenu par des tiers, et qui comprend la technologie relative aux polices de caracte`res, est prote'ge' par un copyright et licencie' par des fournisseurs de Sun. Sun, Sun Microsystems, le logo Sun, Solaris, Java, JavaServer Pages, Java Naming and Directory Interface, JDBC, JDK, JavaMail, et Enterprise JavaBeans, sont des marques de fabrique ou des marques de'pose'es de Sun Microsystems, Inc. aux Etats-Unis et dans d'autres pays. Toutes les marques SPARC sont utilise'es sous licence et sont des marques de fabrique ou des marques de'pose'es de SPARC International, Inc. aux Etats-Unis et dans d'autres pays. Les produits portant les marques SPARC sont base's sur une architecture de'veloppe'e par Sun Microsystems, Inc. Postcript est une marque enregistre'e d'Adobe Systems Inc. LA DOCUMENTATION EST FOURNIE EN L'ETAT ET TOUTES AUTRES CONDITIONS, DECLARATIONS ET GARANTIES EXPRESSES OU TACITES SONT FORMELLEMENT EXCLUES, DANS LA
Re: Is Compile Failure? was Re: Need some clarifications
On Friday, October 4, 2002, at 12:55 AM, Henri Gomez wrote: Steve Downey wrote: On Thursday 03 October 2002 12:14 pm, Henri Gomez wrote: Steve Downey wrote: Actually, with the recent release of commons-logging, we should be able to get rid of the explicit LogKit and Log4J. They're there so as to get a complete build of commons-logging. Tomcat 5 itself doesn't use either directly. Xerces is a different issue. There was a bug that was preventing Tomcat from migrating to the latest version. Unfortunately, I no longer remember the details. Anyone know why we're using 2.1.0 instead of 2.2.0? From what I experienced with Xerces j 2.2.0 it seems it does much more validity check and for instance found a '--' somewhere in comments (1 EUR to the first who find where). Previous version of Xerces or crimson didn't got that problem. if we could see which xml/dtd/tld is reported buggy, which will able to see if it's a bug or a features (ie a more strict check of xml rules) OK, from the 'this shouldn't work department', this patch 'fixes' the problem: Index: ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/src/share/dtd/web- jsptaglibrary_1_2.dtd,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 web-jsptaglibrary_1_2.dtd --- ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd13 Aug 2002 16:20:58 - 1.1.1.1 +++ ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd3 Oct 2002 20:42:30 - @@ -304,6 +304,7 @@ java.lang.String is default. declare Whether the variable is declared or not. + True is the default. scopeThe scope of the scripting varaible Something quite strange is going on. You just add an empty line in this dtd and it works now ? I was thinking it could be with -- in some dtd, ie line in web-app_2_3.dtd : I checked that long line before. It's made up of underscores. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
Thank-you, but I still seem to get errors. Namely the logkit from Avalon is referencing an old verion. I fixed it up to the following logkit.home=${base.path}/LogKit-1.1 logkit.lib=${logkit.home} logkit.jar=${logkit.lib}/logkit-1.1.jar logkit.loc=http://jakarta.apache.org/builds/jakarta-avalon/release/logkit/latest/LogKit-1.1-bin.tar.gz xerces.home=${base.path}/xerces-2_2_0 xerces.lib=${xerces.home} xercesImpl.jar=${xerces.lib}/xercesImpl.jar xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.2.0.tar.gz I do not know if you can commit changes, but these worked for me, since the old versions either do not exist or the references have been made updated. Christian Gross At 09:40 PM 02/10/2002 -0400, you wrote: You need to be using the HEAD version of digester. It should have been built in the directory specified by base.path. Double check that it was built correctly. I just recreated it in my depends directory, and the system built fine. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
Actually, with the recent release of commons-logging, we should be able to get rid of the explicit LogKit and Log4J. They're there so as to get a complete build of commons-logging. Tomcat 5 itself doesn't use either directly. Xerces is a different issue. There was a bug that was preventing Tomcat from migrating to the latest version. Unfortunately, I no longer remember the details. Anyone know why we're using 2.1.0 instead of 2.2.0? On Thursday 03 October 2002 06:43 am, Christian Gross wrote: Thank-you, but I still seem to get errors. Namely the logkit from Avalon is referencing an old verion. I fixed it up to the following logkit.home=${base.path}/LogKit-1.1 logkit.lib=${logkit.home} logkit.jar=${logkit.lib}/logkit-1.1.jar logkit.loc=http://jakarta.apache.org/builds/jakarta-avalon/release/logkit/l atest/LogKit-1.1-bin.tar.gz xerces.home=${base.path}/xerces-2_2_0 xerces.lib=${xerces.home} xercesImpl.jar=${xerces.lib}/xercesImpl.jar xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.2.0.tar.gz I do not know if you can commit changes, but these worked for me, since the old versions either do not exist or the references have been made updated. Christian Gross At 09:40 PM 02/10/2002 -0400, you wrote: You need to be using the HEAD version of digester. It should have been built in the directory specified by base.path. Double check that it was built correctly. I just recreated it in my depends directory, and the system built fine. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
Steve Downey wrote: Actually, with the recent release of commons-logging, we should be able to get rid of the explicit LogKit and Log4J. They're there so as to get a complete build of commons-logging. Tomcat 5 itself doesn't use either directly. Xerces is a different issue. There was a bug that was preventing Tomcat from migrating to the latest version. Unfortunately, I no longer remember the details. Anyone know why we're using 2.1.0 instead of 2.2.0? From what I experienced with Xerces j 2.2.0 it seems it does much more validity check and for instance found a '--' somewhere in comments (1 EUR to the first who find where). Previous version of Xerces or crimson didn't got that problem. if we could see which xml/dtd/tld is reported buggy, which will able to see if it's a bug or a features (ie a more strict check of xml rules) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
Henri Gomez wrote: Steve Downey wrote: Actually, with the recent release of commons-logging, we should be able to get rid of the explicit LogKit and Log4J. They're there so as to get a complete build of commons-logging. Tomcat 5 itself doesn't use either directly. Xerces is a different issue. There was a bug that was preventing Tomcat from migrating to the latest version. Unfortunately, I no longer remember the details. Anyone know why we're using 2.1.0 instead of 2.2.0? Because, I think, Xerces 2.2.0 was relased two weeks ago. I'm actually testing Xerces 2.2.knowing how much problem we have with Xerces 2.0.1 - 2.0.2 and XML Schema, I just want to be sure there is no regression ;-) -- Jeanfrancois From what I experienced with Xerces j 2.2.0 it seems it does much more validity check and for instance found a '--' somewhere in comments (1 EUR to the first who find where). Previous version of Xerces or crimson didn't got that problem. if we could see which xml/dtd/tld is reported buggy, which will able to see if it's a bug or a features (ie a more strict check of xml rules) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
Jean-Francois Arcand wrote: Henri Gomez wrote: Steve Downey wrote: Actually, with the recent release of commons-logging, we should be able to get rid of the explicit LogKit and Log4J. They're there so as to get a complete build of commons-logging. Tomcat 5 itself doesn't use either directly. Xerces is a different issue. There was a bug that was preventing Tomcat from migrating to the latest version. Unfortunately, I no longer remember the details. Anyone know why we're using 2.1.0 instead of 2.2.0? Because, I think, Xerces 2.2.0 was relased two weeks ago. I'm actually testing Xerces 2.2.knowing how much problem we have with Xerces 2.0.1 - 2.0.2 and XML Schema, I just want to be sure there is no regression ;-) I upgraded the properties file (sorry, didn't know you hadn't done it on purpose), as IMO it's a good idea to test as much as possible since we're still in pre-alpha stages. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
On Thursday 03 October 2002 12:14 pm, Henri Gomez wrote: Steve Downey wrote: Actually, with the recent release of commons-logging, we should be able to get rid of the explicit LogKit and Log4J. They're there so as to get a complete build of commons-logging. Tomcat 5 itself doesn't use either directly. Xerces is a different issue. There was a bug that was preventing Tomcat from migrating to the latest version. Unfortunately, I no longer remember the details. Anyone know why we're using 2.1.0 instead of 2.2.0? From what I experienced with Xerces j 2.2.0 it seems it does much more validity check and for instance found a '--' somewhere in comments (1 EUR to the first who find where). Previous version of Xerces or crimson didn't got that problem. if we could see which xml/dtd/tld is reported buggy, which will able to see if it's a bug or a features (ie a more strict check of xml rules) Going through my old mail, I was remembering the 2.0.1/2.0.2 problems that were keeping us on xerces nightly for a while. 2.1.0 fixed those problems. This seems to be a problem in parsing the 1.2 taglibs DTD. This one fails http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd where this one http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd succeeds. Failure is at line 307, column 39. But I don't see anything significant there. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
On Thursday, October 3, 2002, at 09:14 AM, Henri Gomez wrote: Steve Downey wrote: Actually, with the recent release of commons-logging, we should be able to get rid of the explicit LogKit and Log4J. They're there so as to get a complete build of commons-logging. Tomcat 5 itself doesn't use either directly. Xerces is a different issue. There was a bug that was preventing Tomcat from migrating to the latest version. Unfortunately, I no longer remember the details. Anyone know why we're using 2.1.0 instead of 2.2.0? From what I experienced with Xerces j 2.2.0 it seems it does much more validity check and for instance found a '--' somewhere in comments (1 EUR to the first who find where). :-) I scanned though quite a lot of xml/dtd/tld in 4.1.12, hoping to get that elusive 1 EUR. Not such luck. The only thing that I can come up with is: the TLDs are referring an DTD that has been moved by Sun. Here's what you get when you go to http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_2.dtd The file named http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_2.dtd has been renamed to http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd in the most current version of the specification. Please update your application to use the new name. Thus, if the parser has been set to be validating, it would fail (albeit with a different error). Maybe updating the DOCTYPE in the TLDs should help? Previous version of Xerces or crimson didn't got that problem. if we could see which xml/dtd/tld is reported buggy, which will able to see if it's a bug or a features (ie a more strict check of xml rules) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
On Thursday 03 October 2002 12:14 pm, Henri Gomez wrote: Steve Downey wrote: Actually, with the recent release of commons-logging, we should be able to get rid of the explicit LogKit and Log4J. They're there so as to get a complete build of commons-logging. Tomcat 5 itself doesn't use either directly. Xerces is a different issue. There was a bug that was preventing Tomcat from migrating to the latest version. Unfortunately, I no longer remember the details. Anyone know why we're using 2.1.0 instead of 2.2.0? From what I experienced with Xerces j 2.2.0 it seems it does much more validity check and for instance found a '--' somewhere in comments (1 EUR to the first who find where). Previous version of Xerces or crimson didn't got that problem. if we could see which xml/dtd/tld is reported buggy, which will able to see if it's a bug or a features (ie a more strict check of xml rules) OK, from the 'this shouldn't work department', this patch 'fixes' the problem: Index: ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 web-jsptaglibrary_1_2.dtd --- ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd13 Aug 2002 16:20:58 - 1.1.1.1 +++ ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd3 Oct 2002 20:42:30 - @@ -304,6 +304,7 @@ java.lang.String is default. declare Whether the variable is declared or not. + True is the default. scopeThe scope of the scripting varaible Something quite strange is going on. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Is Compile Failure? was Re: Need some clarifications
Thanks for your answer. That helps quite a bit. Now I have another issue... build-catalina: [javac] Compiling 94 source files to D:\Instructor\Projects\jakarta-tomcat-c atalina\build\server\classes [javac] D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or g\apache\catalina\startup\ContextConfig.java:537: cannot resolve symbol [javac] symbol : method setEntityResolver (org.apache.catalina.util.Schema Resolver) [javac] location: class org.apache.commons.digester.Digester [javac] tldDigester.setEntityResolver(tldEntityResolver); [javac]^ [javac] D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or g\apache\catalina\startup\ContextConfig.java:595: cannot resolve symbol [javac] symbol : method setEntityResolver (org.apache.catalina.util.Schema Resolver) [javac] location: class org.apache.commons.digester.Digester [javac] webDigester.setEntityResolver(webEntityResolver); [javac]^ [javac] D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or g\apache\catalina\util\SchemaResolver.java:154: cannot resolve symbol [javac] symbol : method setPublicId (java.lang.String) [javac] location: class org.apache.commons.digester.Digester [javac] digester.setPublicId(publicId); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [javac] 3 errors BUILD FAILED file:D:/Instructor/Projects/jakarta-tomcat-catalina/catalina/build.xml:801: Comp ile failed; see the compiler error output for details. I checked out digester 1.3 and 1.2 and there does not seem to be a method setEntityResolver. Or am I missing something? Christian Gross At 14:18 02/10/2002 -0400, you wrote: On Wednesday 02 October 2002 09:38 am, Christian Gross wrote: Hi So I worked myself through the various CVS sources and have a couple of official position questions to ask. The CVS projects jakarta-tomcat-catalina and jakarta-tomcat-jasper, will be forming the Tomcat 5 work? jakarta-servletapi-5, jakarta-tomcat-5, jakarta-tomcat-catalina, jakarta-tomcat-connectors, jakarta-tomcat-jasper, and jakarta-watchdog-4.0 are the CVS repositories involved in Tomcat 5.0 The CVS project jakarta-tomcat-4.0 is the 4.x branch? Yes The CVS project jakarta-tomcat is anything before 4.0 Tomcat 3.x, at least. The CVS project jakarta-tomcat-5.0 does nothing?? It's the master project for the whole Tomcat 5.0 project. To use it, start with a directory like tc5-workspace. In that directory: export CVSROOT=:pserver:[EMAIL PROTECTED]:/home/cvspublic cvs co jakarta-servletapi-5 cvs co jakarta-tomcat-5 cvs co jakarta-tomcat-catalina cvs co jakarta-tomcat-connectors cvs co jakarta-tomcat-jasper then, in jakarta-tomcat-5 create a build.properties file with the following definition base.path = /home/sdowney/tc5-workspace/depends (replace /home/sdowney/tc5-workspace with path to your workspace. I don't know if relative will work. I stopped dinking when I got my build system to function) You need ant 1.5 to build Tomcat 5 export ANT_HOME=/home/sdowney/tools/jakarta-ant-1.5 PATH=$PATH:$ANT_HOME/bin ant download The download target in Tomcat 5 gets the necessary ancillary libraries to build the system. I'm using JDK 1.4, which has a few things built in. You may need to install some things in JDK 1.3, like JCE. I'm not sure. Then: ant build ant test [Not many tests at the moment] If you're contributing, you may also want to do ant -Dfull.dist=on build That will force a full compile, rather than checking which optional components are available and setting things on or off based on the presense or absense of classes. That useful for building a customized version, but for testing purposes, a full build is better. To run the watchdog conformance test suite: ant watchdog -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Christian Gross Software Engineering Consultant http://www.devspace.com North America: 1-450-675-4208 Europe +41.1.701.1166 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
You need to be using the HEAD version of digester. It should have been built in the directory specified by base.path. Double check that it was built correctly. I just recreated it in my depends directory, and the system built fine. A number of the dependencies are unreleased at this point. 'ant download' tries to grab the correct ones. On Wednesday 02 October 2002 07:54 pm, Christian Gross wrote: Thanks for your answer. That helps quite a bit. Now I have another issue... build-catalina: [javac] Compiling 94 source files to D:\Instructor\Projects\jakarta-tomcat-c atalina\build\server\classes [javac] D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or g\apache\catalina\startup\ContextConfig.java:537: cannot resolve symbol [javac] symbol : method setEntityResolver (org.apache.catalina.util.Schema Resolver) [javac] location: class org.apache.commons.digester.Digester [javac] tldDigester.setEntityResolver(tldEntityResolver); [javac]^ [javac] D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or g\apache\catalina\startup\ContextConfig.java:595: cannot resolve symbol [javac] symbol : method setEntityResolver (org.apache.catalina.util.Schema Resolver) [javac] location: class org.apache.commons.digester.Digester [javac] webDigester.setEntityResolver(webEntityResolver); [javac]^ [javac] D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or g\apache\catalina\util\SchemaResolver.java:154: cannot resolve symbol [javac] symbol : method setPublicId (java.lang.String) [javac] location: class org.apache.commons.digester.Digester [javac] digester.setPublicId(publicId); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [javac] 3 errors BUILD FAILED file:D:/Instructor/Projects/jakarta-tomcat-catalina/catalina/build.xml:801: Comp ile failed; see the compiler error output for details. I checked out digester 1.3 and 1.2 and there does not seem to be a method setEntityResolver. Or am I missing something? Christian Gross At 14:18 02/10/2002 -0400, you wrote: On Wednesday 02 October 2002 09:38 am, Christian Gross wrote: Hi So I worked myself through the various CVS sources and have a couple of official position questions to ask. The CVS projects jakarta-tomcat-catalina and jakarta-tomcat-jasper, will be forming the Tomcat 5 work? jakarta-servletapi-5, jakarta-tomcat-5, jakarta-tomcat-catalina, jakarta-tomcat-connectors, jakarta-tomcat-jasper, and jakarta-watchdog-4.0 are the CVS repositories involved in Tomcat 5.0 The CVS project jakarta-tomcat-4.0 is the 4.x branch? Yes The CVS project jakarta-tomcat is anything before 4.0 Tomcat 3.x, at least. The CVS project jakarta-tomcat-5.0 does nothing?? It's the master project for the whole Tomcat 5.0 project. To use it, start with a directory like tc5-workspace. In that directory: export CVSROOT=:pserver:[EMAIL PROTECTED]:/home/cvspublic cvs co jakarta-servletapi-5 cvs co jakarta-tomcat-5 cvs co jakarta-tomcat-catalina cvs co jakarta-tomcat-connectors cvs co jakarta-tomcat-jasper then, in jakarta-tomcat-5 create a build.properties file with the following definition base.path = /home/sdowney/tc5-workspace/depends (replace /home/sdowney/tc5-workspace with path to your workspace. I don't know if relative will work. I stopped dinking when I got my build system to function) You need ant 1.5 to build Tomcat 5 export ANT_HOME=/home/sdowney/tools/jakarta-ant-1.5 PATH=$PATH:$ANT_HOME/bin ant download The download target in Tomcat 5 gets the necessary ancillary libraries to build the system. I'm using JDK 1.4, which has a few things built in. You may need to install some things in JDK 1.3, like JCE. I'm not sure. Then: ant build ant test [Not many tests at the moment] If you're contributing, you may also want to do ant -Dfull.dist=on build That will force a full compile, rather than checking which optional components are available and setting things on or off based on the presense or absense of classes. That useful for building a customized version, but for testing purposes, a full build is better. To run the watchdog conformance test suite: ant watchdog -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Christian Gross Software Engineering Consultant http://www.devspace.com North America: 1-450-675-4208 Europe +41.1.701.1166 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]