Re: Need some clarifications
In order to thank you for your kind explanation, I'd like to share my
TC5 pre-build and post-build result and some updated tips .(Notice: The
following processes are wholly up to 7 Oct. 2002.)
Test Build Environment:
IBM ThinkPad R32
Windows XP
JDK 1.4.1
Ant 1.5.1
WinCVS 1.3b8(dos command cvs is based on cvs 1.11)
Python 2.2.1
First, we need to modify jakart-tomcat-5's build.properties as followed.
1. Since there's no LogKit-1.0.1 in latest directory,
# - LogKit -
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
2. There's brand-new Java Mail and JAF libraries now, so I downloaded
and copied them instead of previously specified versions. (Make
javamail-1.3 and jaf-1.0.2 directories and copy the specified jar files
to there respectively.)
# - Java Mail, version 1.2 or later -
mail.home=${base.path}/javamail-1.3
mail.lib=${mail.home}
mail.jar=${mail.lib}/mailapi.jar
# - Java Activation Framework (JAF), version 1.0.1 or later -
activation.home=${base.path}/jaf-1.0.2
activation.lib=${activation.home}
activation.jar=${activation.lib}/activation.jar
3. This is optional, however, I prefer JDK 1.4 version.
#Build lightweight JDK 1.4 distribution
light.dist=on
Next, we are on the step of build stage. Unfortunately, there's no
build target in tomcat 5 ant build.xml. Instead, we can do ant dist
after ant download. Actually it emitted quite many warnings including
deprecations and absences of libraries, but successfully completed.
I put some built distribution(zip format) here:
http://www.iasandcb.pe.kr/starbucks/special/jakarta-tomcat-5.0-ias-
build.zip
I've not tested fully enough, but tomcat startup shell displayed like
this:
2002. 10. 7. ¿ÀÈÄ 1:44:26 org.apache.commons.modeler.Registry
loadRegistry
Á¤º¸: Loading registry information
2002. 10. 7. ¿ÀÈÄ 1:44:26 org.apache.commons.modeler.Registry
getRegistry
Á¤º¸: Creating new Registry instance
2002. 10. 7. ¿ÀÈÄ 1:44:26 org.apache.commons.modeler.Registry getServer
Á¤º¸: Creating MBeanServer
2002. 10. 7. ¿ÀÈÄ 1:44:28 org.apache.coyote.http11.Http11Protocol init
Á¤º¸: Initializing Coyote HTTP/1.1 on port 8080
Starting service Tomcat-Standalone
Apache Tomcat/5.0
2002. 10. 7. ¿ÀÈÄ 1:44:30 org.apache.catalina.startup.ContextConfig
tldScan
Á¤º¸: Processed tld jar /WEB-INF/lib/struts.jar 261
2002. 10. 7. ¿ÀÈÄ 1:44:30 org.apache.catalina.startup.ContextConfig
authenticato
rConfig
Á¤º¸: Configured an authenticator for method FORM
2002. 10. 7. ¿ÀÈÄ 1:44:39 org.apache.catalina.startup.ContextConfig
authenticato
rConfig
Á¤º¸: Configured an authenticator for method BASIC
2002. 10. 7. ¿ÀÈÄ 1:44:41 org.apache.catalina.startup.ContextConfig
authenticato
rConfig
Á¤º¸: Configured an authenticator for method FORM
2002. 10. 7. ¿ÀÈÄ 1:44:42 org.apache.catalina.startup.ContextConfig
authenticato
rConfig
Á¤º¸: Configured an authenticator for method FORM
2002. 10. 7. ¿ÀÈÄ 1:44:42 org.apache.coyote.http11.Http11Protocol start
Á¤º¸: Starting Coyote HTTP/1.1 on port 8080
2002. 10. 7. ¿ÀÈÄ 1:44:42 org.apache.jk.common.ChannelSocket init
Á¤º¸: JK2: ajp13 listening on tcp port 8009
2002. 10. 7. ¿ÀÈÄ 1:44:42 org.apache.jk.server.JkMain start
Á¤º¸: Jk running ID=0 time=10/30 config=C:\java\jakarta\cvs\jakarta-
tomcat-5\di
st\bin\..\conf\jk2.properties
(Sorry for some broken characters. They are Korean.)
The built Tomcat 5 examples with EL-based JSP 2 style works fine.
I wish all the Tomcat players and spectators good luck with version 5.
IAS
Independent Java Technical Evangelist
http://www.iasandcb.pe.kr
From: Steve Downey
Subject: Re: Need some clarifications
Date: Wed, 02 Oct 2002 10:54:53 -0700
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
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]
Need some clarifications
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? The CVS project jakarta-tomcat-4.0 is the 4.x branch? The CVS project jakarta-tomcat is anything before 4.0 The CVS project jakarta-tomcat-5.0 does nothing?? Thanks, for any help 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: Need some clarifications
On Wed, 2002-10-02 at 09:38, 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? Yup. The CVS project jakarta-tomcat-4.0 is the 4.x branch? yes. I think the 4.0 is tagged in there, but the HEAD is 4.1 The CVS project jakarta-tomcat is anything before 4.0 yup. The CVS project jakarta-tomcat-5.0 does nothing?? It is jakarta-tomcat-5, not 5.0 and it is used to pull together the other bits to make Tomcat5. If you want to build TC5, just use the attached build.xml and type ant Cheers, -bob Thanks, for any help 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] -- Bob Herrmann [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Need some clarifications
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]
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]
