Re: [5.0] Build notes
Patrick Luby wrote: Costin, [EMAIL PROTECTED] wrote: On Sun, 11 Aug 2002, Patrick Luby wrote: commons-digester/logging, etc. I think that this would make the build more reliable since Tomcat 5 is dependent on very specific versions of Apache dependencies (e.g. Xerces 2.0.1 only). IMHO that's _totally_ unacceptable ( having tomcat5 work only with xerces). I think that the dependency on Xerces 2.0.1 is excessively restrictive as well. IIRC (maybe Jean-François could provide some of the details he found?), Xerces 2.0.1 was the only Xerces parser that we have found so far that does not throw StackOverflow or other fatal exceptions when an XML file using XML schema is parsed. I believe (Jean-François: let me know if my understanding is incorrect) that this problem exists even if schema validation is turned off. The StackOverflowException _only_ occurs with released version of Xerces 2.0.2. It has been fixed since the release (nightly build works fine). Yes the problem exist even if the schema validation is on. And having schema validation turned on by default has a strong -1 from me - if the spec _requires_ schema validation, then implement it at deployment time. The performance hit is just unacceptable. Any performance increases through delayed validation sounds good to me. I agree. What behaviour do we want if a xml instance is not well-formed? ( in the process we should also move DTD validation to the same stage and stop doing it on every startup if the xml file didn't change ) Makes sense. Especially since we use this same technique for JSP page compilation. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Build notes
[EMAIL PROTECTED] wrote: On Sun, 11 Aug 2002, Bill Barker wrote: I don't know anybody that likes it, but it's required by the JSP-1.2 spec (and still in the current draft of the JSP-2.0 spec). The TLDs may contain Listeners, and the only way to get them registered is to scan at startup. Ops, I missed that one. So you mean even if a webapp has no JSP at all - the TLDs are still processed ( sort of extension to web.xml ) ? I allways tought they are for translation, not runtime. Yes, they are. The spec defines many ways to define some things (not a very good idea IMO), like it has many places where you can put the TLD. I just downloaded the new servlet draft - and it seems the welcome file it defines is still unimplementable and violates all the current practices... I've been saying that for a while in a few messages if you look at the archives. I've been emailing the spec people while I was working at Sun, but I have been politely ignored on that issue :-( Oh well, if it's not implementable, then we won't implement it ;-) I'll make a proposal soon (let's say by wed) to rewrite the mapper, and it will partially handle the new spec requirements. I'm beginning to wonder who is Apache's representative to the JCP and how will he make the decision on what to vote... Jason maybe ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Build notes
[EMAIL PROTECTED] wrote: On Sun, 11 Aug 2002, Patrick Luby wrote: commons-digester/logging, etc. I think that this would make the build more reliable since Tomcat 5 is dependent on very specific versions of Apache dependencies (e.g. Xerces 2.0.1 only). IMHO that's _totally_ unacceptable ( having tomcat5 work only with xerces). And having schema validation turned on by default has a strong -1 from me - if the spec _requires_ schema validation, then implement it at deployment time. The performance hit is just unacceptable. I agree with Costin. Startup time of TC 4.1 was bad, 5.0 is unbearable. I now agree with the hacks Costin put in 3.3 ;-) We need that or an option to disable validation. ( in the process we should also move DTD validation to the same stage and stop doing it on every startup if the xml file didn't change ) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Build notes
On Mon, 12 Aug 2002, Jean-francois Arcand wrote: I think that the dependency on Xerces 2.0.1 is excessively restrictive as well. IIRC (maybe Jean-François could provide some of the details he found?), Xerces 2.0.1 was the only Xerces parser that we have found so far that does not throw StackOverflow or other fatal exceptions when an XML file using XML schema is parsed. I believe (Jean-François: let me know if my understanding is incorrect) that this problem exists even if schema validation is turned off. The StackOverflowException _only_ occurs with released version of Xerces 2.0.2. It has been fixed since the release (nightly build works fine). Yes the problem exist even if the schema validation is on. I only tested crimson - it fails if validation is on, but works fine and faster if validation is disabled. And having schema validation turned on by default has a strong -1 from me - if the spec _requires_ schema validation, then implement it at deployment time. The performance hit is just unacceptable. Any performance increases through delayed validation sounds good to me. I agree. What behaviour do we want if a xml instance is not well-formed? Again - this is not 'delayed' validation, the validation and initalization will allways happen before the first request is served, and if an error is found the context will be disabled. There are 2 distinct issues: One is moving the 'validation' to a deploy stage. If validation fails, the app will not be deployed. The second issue is doing the context initialization in background and in parallel. That has nothing to do with validation. If we don't implement the 'deploy' - we can validate the XML file once ( during startup ), and keep a timestamp to avoid future re-validation. But the behavior remains the same - the app will not be started. Costin ( in the process we should also move DTD validation to the same stage and stop doing it on every startup if the xml file didn't change ) Makes sense. Especially since we use this same technique for JSP page compilation. -- 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: [5.0] Build notes
The only snag is that 'ant download' doesn't download optional
components. And some of them are optional the same way that brakes on a
go-cart are optional. It'll work, just not quite the way you expect it to.
More importantly, any developer building Tomcat needs to build a full
version, otherwise you run the risk of breaking parts of the build that
you happen not to be building because you don't have the optional
component that it depends on. And the build process is fairly quiet
about those missing pieces.
Automating the download of optional components, however, is a bit
tricky, as many of the optional components are behind Sun's license page.
Bob Herrmann wrote:
Yea, I liked your script, this one builds Tomcat 5.
BUILDING.TXT could almost just say All you need is JDK1.4 and Ant1.5
then just type 'ant' and a working Tomcat 5 development tree is built.
(If you are behind a firewall, you may need to adjust proxy settings.)
This should be cross platform (haven't tested it on Win32.)
Cheers,
-bob
project name=CVS Retrieval default=populate
property file=build.properties/
property name=apache.dir value=${user.home}/TC5/
property name=base.path value=${apache.dir}/download/
property name=cvsroot
value=:pserver:[EMAIL PROTECTED]:/home/cvspublic/
target name=populate depends=init,checkout,buildit /
target name=init
tstamp/
mkdir dir=${apache.dir}/
mkdir dir=${base.path}/
/target
target name=checkout depends=init
cvs package=jakarta-servletapi-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-catalina
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-connectors
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-jasper
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
/target
target name=buildit depends=init
echo message=Commons-logging build dies without this
file=${base.path}/LICENSE /
ant dir=${apache.dir}/jakarta-tomcat-5
target=download /
ant dir=${apache.dir}/jakarta-tomcat-5
target=dist /
/target
/project
On Tue, 2002-08-06 at 13:43, Ian Darwin wrote:
On August 6, 2002 01:01 pm, you wrote:
The main thing missing is a target which sets up the CVS repositories,
so it's quite close to what we have now. Problem is, I'm not too happy
at the idea of doing that automatically.
Trivial to do with Ant, but I agree, it's risky to automate this. OTOH if
it's well documented what it's doing, people should be OK with it.
Ian
project name=CVS Retrieval default=populate
!-- $Id: build.xml,v 1.1 2002/06/11 15:35:57 ian Exp $ --
!-- Maybe find a better way of setting this --
property name=apache.dir value=${user.home}/src/apache/
property name=cvs.root
value=:pserver:[EMAIL PROTECTED]:/home/cvspublic/
target name=init
tstamp/
mkdir dir=${apache.dir}/
/target
target name=populate depends=init
cvs package=jakarta-tomcat-4.0
cvsRoot=${cvs.root}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-connectors
cvsRoot=${cvs.root}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-jasper
cvsRoot=${cvs.root}
dest=${apache.dir}
/
/target
/project
--
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]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Build notes
Sort of a mini-gump.
No sense in over-doing what the build file is supposed to do. The idea
is cool, but, gump exists for a reason :) I suspect a change like this
would make things slightly more complex, confusing, and in general take
way to much time to implement - not to mention open up the possibility
for abuse.
But that is just my opinion. Anyhow, the one-step build-from-scratch
still rocks. Any idea when nightly Tomcat 5 builds will start appearing
on Jakarta?
Cheers,
Jayson
Bob Herrmann wrote:
On Sun, 2002-08-11 at 11:25, Jayson Falkner wrote:
I have been using the same thing. The only downside is the download
time, but, IMO it would be great to have this included and encouraged
for use with the Tomcat 5 build file.
Way to go Bob!
Thanks, although I just cut/pasted Ian Darwin's example.
It builds tomcat5 pretty well, but I would really like it if it also did
these things,
- building dist, start tomcat up
- download and run watchdog and generate a report
- If the report fails, then send an email to people who committed in
past 24 hours
- run automatically every 24 hours.
Sort of a mini-gump.
Cheers,
-bob
Jayson Falkner
[EMAIL PROTECTED]
Bob Herrmann wrote:
Yea, I liked your script, this one builds Tomcat 5.
BUILDING.TXT could almost just say All you need is JDK1.4 and Ant1.5
then just type 'ant' and a working Tomcat 5 development tree is built.
(If you are behind a firewall, you may need to adjust proxy settings.)
This should be cross platform (haven't tested it on Win32.)
Cheers,
-bob
project name=CVS Retrieval default=populate
property file=build.properties/
property name=apache.dir value=${user.home}/TC5/
property name=base.path value=${apache.dir}/download/
property name=cvsroot
value=:pserver:[EMAIL PROTECTED]:/home/cvspublic/
target name=populate depends=init,checkout,buildit /
target name=init
tstamp/
mkdir dir=${apache.dir}/
mkdir dir=${base.path}/
/target
target name=checkout depends=init
cvs package=jakarta-servletapi-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-catalina
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-connectors
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-jasper
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
/target
target name=buildit depends=init
echo message=Commons-logging build dies without this
file=${base.path}/LICENSE /
ant dir=${apache.dir}/jakarta-tomcat-5
target=download /
ant dir=${apache.dir}/jakarta-tomcat-5
target=dist /
/target
/project
On Tue, 2002-08-06 at 13:43, Ian Darwin wrote:
On August 6, 2002 01:01 pm, you wrote:
The main thing missing is a target which sets up the CVS repositories,
so it's quite close to what we have now. Problem is, I'm not too happy
at the idea of doing that automatically.
Trivial to do with Ant, but I agree, it's risky to automate this. OTOH if
it's well documented what it's doing, people should be OK with it.
Ian
project name=CVS Retrieval default=populate
!-- $Id: build.xml,v 1.1 2002/06/11 15:35:57 ian Exp $ --
!-- Maybe find a better way of setting this --
property name=apache.dir value=${user.home}/src/apache/
property name=cvs.root
value=:pserver:[EMAIL PROTECTED]:/home/cvspublic/
target name=init
tstamp/
mkdir dir=${apache.dir}/
/target
target name=populate depends=init
cvs package=jakarta-tomcat-4.0
cvsRoot=${cvs.root}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-connectors
cvsRoot=${cvs.root}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-jasper
cvsRoot=${cvs.root}
dest=${apache.dir}
/
/target
/project
--
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]
--
To
Re: [5.0] Build notes
I have been using the same thing. The only downside is the download
time, but, IMO it would be great to have this included and encouraged
for use with the Tomcat 5 build file.
Way to go Bob!
Jayson Falkner
[EMAIL PROTECTED]
Bob Herrmann wrote:
Yea, I liked your script, this one builds Tomcat 5.
BUILDING.TXT could almost just say All you need is JDK1.4 and Ant1.5
then just type 'ant' and a working Tomcat 5 development tree is built.
(If you are behind a firewall, you may need to adjust proxy settings.)
This should be cross platform (haven't tested it on Win32.)
Cheers,
-bob
project name=CVS Retrieval default=populate
property file=build.properties/
property name=apache.dir value=${user.home}/TC5/
property name=base.path value=${apache.dir}/download/
property name=cvsroot
value=:pserver:[EMAIL PROTECTED]:/home/cvspublic/
target name=populate depends=init,checkout,buildit /
target name=init
tstamp/
mkdir dir=${apache.dir}/
mkdir dir=${base.path}/
/target
target name=checkout depends=init
cvs package=jakarta-servletapi-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-catalina
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-connectors
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-jasper
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
/target
target name=buildit depends=init
echo message=Commons-logging build dies without this
file=${base.path}/LICENSE /
ant dir=${apache.dir}/jakarta-tomcat-5
target=download /
ant dir=${apache.dir}/jakarta-tomcat-5
target=dist /
/target
/project
On Tue, 2002-08-06 at 13:43, Ian Darwin wrote:
On August 6, 2002 01:01 pm, you wrote:
The main thing missing is a target which sets up the CVS repositories,
so it's quite close to what we have now. Problem is, I'm not too happy
at the idea of doing that automatically.
Trivial to do with Ant, but I agree, it's risky to automate this. OTOH if
it's well documented what it's doing, people should be OK with it.
Ian
project name=CVS Retrieval default=populate
!-- $Id: build.xml,v 1.1 2002/06/11 15:35:57 ian Exp $ --
!-- Maybe find a better way of setting this --
property name=apache.dir value=${user.home}/src/apache/
property name=cvs.root
value=:pserver:[EMAIL PROTECTED]:/home/cvspublic/
target name=init
tstamp/
mkdir dir=${apache.dir}/
/target
target name=populate depends=init
cvs package=jakarta-tomcat-4.0
cvsRoot=${cvs.root}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-connectors
cvsRoot=${cvs.root}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-jasper
cvsRoot=${cvs.root}
dest=${apache.dir}
/
/target
/project
--
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]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Build notes
All,
Couldn't we go a step farther and check any Apache dependencies into the
Tomcat cvs repository and remove them from build.properties.default and
build.xml's download target? Of course, we can't do this for some 3rd
party dependencies, but we can for stuff like Xerces,
commons-digester/logging, etc. I think that this would make the build
more reliable since Tomcat 5 is dependent on very specific versions of
Apache dependencies (e.g. Xerces 2.0.1 only).
I know that a lot of other Jakarta projects do this. Are there any
problems with this?
Patrick
Jayson Falkner wrote:
I have been using the same thing. The only downside is the download
time, but, IMO it would be great to have this included and encouraged
for use with the Tomcat 5 build file.
Way to go Bob!
Jayson Falkner
[EMAIL PROTECTED]
Bob Herrmann wrote:
Yea, I liked your script, this one builds Tomcat 5.
BUILDING.TXT could almost just say All you need is JDK1.4 and Ant1.5
then just type 'ant' and a working Tomcat 5 development tree is built.
(If you are behind a firewall, you may need to adjust proxy settings.)
This should be cross platform (haven't tested it on Win32.)
Cheers,
-bob
project name=CVS Retrieval default=populate
property file=build.properties/
property name=apache.dir value=${user.home}/TC5/
property name=base.path value=${apache.dir}/download/
property name=cvsroot
value=:pserver:[EMAIL PROTECTED]:/home/cvspublic/
target name=populate depends=init,checkout,buildit /
target name=init
tstamp/
mkdir dir=${apache.dir}/ mkdir
dir=${base.path}/ /target
target name=checkout depends=init
cvs package=jakarta-servletapi-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-catalina
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-connectors
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-jasper
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
/target
target name=buildit depends=init
echo message=Commons-logging build dies without this
file=${base.path}/LICENSE /
ant dir=${apache.dir}/jakarta-tomcat-5
target=download /
ant dir=${apache.dir}/jakarta-tomcat-5
target=dist /
/target
/project
On Tue, 2002-08-06 at 13:43, Ian Darwin wrote:
On August 6, 2002 01:01 pm, you wrote:
The main thing missing is a target which sets up the CVS repositories,
so it's quite close to what we have now. Problem is, I'm not too happy
at the idea of doing that automatically.
Trivial to do with Ant, but I agree, it's risky to automate this. OTOH if
it's well documented what it's doing, people should be OK with it.
Ian
project name=CVS Retrieval default=populate
!-- $Id: build.xml,v 1.1 2002/06/11 15:35:57 ian Exp $ --
!-- Maybe find a better way of setting this --
property name=apache.dir value=${user.home}/src/apache/
property name=cvs.root
value=:pserver:[EMAIL PROTECTED]:/home/cvspublic/
target name=init
tstamp/
mkdir dir=${apache.dir}/ /target
target name=populate depends=init
cvs package=jakarta-tomcat-4.0
cvsRoot=${cvs.root}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-connectors
cvsRoot=${cvs.root}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-jasper
cvsRoot=${cvs.root}
dest=${apache.dir}
/
/target
/project
--
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]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
Re: [5.0] Build notes
On Sun, 11 Aug 2002, Patrick Luby wrote: commons-digester/logging, etc. I think that this would make the build more reliable since Tomcat 5 is dependent on very specific versions of Apache dependencies (e.g. Xerces 2.0.1 only). IMHO that's _totally_ unacceptable ( having tomcat5 work only with xerces). And having schema validation turned on by default has a strong -1 from me - if the spec _requires_ schema validation, then implement it at deployment time. The performance hit is just unacceptable. ( in the process we should also move DTD validation to the same stage and stop doing it on every startup if the xml file didn't change ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Build notes
Costin, [EMAIL PROTECTED] wrote: On Sun, 11 Aug 2002, Patrick Luby wrote: commons-digester/logging, etc. I think that this would make the build more reliable since Tomcat 5 is dependent on very specific versions of Apache dependencies (e.g. Xerces 2.0.1 only). IMHO that's _totally_ unacceptable ( having tomcat5 work only with xerces). I think that the dependency on Xerces 2.0.1 is excessively restrictive as well. IIRC (maybe Jean-François could provide some of the details he found?), Xerces 2.0.1 was the only Xerces parser that we have found so far that does not throw StackOverflow or other fatal exceptions when an XML file using XML schema is parsed. I believe (Jean-François: let me know if my understanding is incorrect) that this problem exists even if schema validation is turned off. And having schema validation turned on by default has a strong -1 from me - if the spec _requires_ schema validation, then implement it at deployment time. The performance hit is just unacceptable. Any performance increases through delayed validation sounds good to me. ( in the process we should also move DTD validation to the same stage and stop doing it on every startup if the xml file didn't change ) Makes sense. Especially since we use this same technique for JSP page compilation. -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Build notes
On Sun, 11 Aug 2002, Patrick Luby wrote: IMHO that's _totally_ unacceptable ( having tomcat5 work only with xerces). I think that the dependency on Xerces 2.0.1 is excessively restrictive as well. IIRC (maybe Jean-François could provide some of the details he found?), Xerces 2.0.1 was the only Xerces parser that we have found so far that does not throw StackOverflow or other fatal exceptions when an XML file using XML schema is parsed. I believe (Jean-François: let me know if my understanding is incorrect) that this problem exists even if schema validation is turned off. I can confirm that tomcat5 works just fine with crimson if validation is off ( and it starts much faster - 6-7 seconds ). And having schema validation turned on by default has a strong -1 from me - if the spec _requires_ schema validation, then implement it at deployment time. The performance hit is just unacceptable. Any performance increases through delayed validation sounds good to me. It's not 'delayed'. There are 2 choices: one ( used in 3.3 ) is to put a 'marker' in work/ and check the timestamp to avoid validating a file that was validated before and didn't changed. The 'right' solution (IMO) is to have a clearly defined 'deploy' stage, and have the validation done at deploy time. The 'deploy' stage is also needed for jk2 ( to generate apache config files for example ). Every time web.xml ( or another .xml ) file changes the app should be redeployed ( i.e. the 'deploy' hooks run ). I can live with the first aproach, or even with a global option to turn off validation. ( in the process we should also move DTD validation to the same stage and stop doing it on every startup if the xml file didn't change ) Makes sense. Especially since we use this same technique for JSP page compilation. Do we ? It didn't seem so when I looked at the code. Actually it somehow seems that something is looking for TLDs at startup - that's a bug for me. The TLDs should be processed when the first JSP is complied - not before. If a webapp doesn't use JSPs or uses precompiled JSPs ( which is a very good idea IMO ) - then there is no point on scanning each jar for TLDs. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Build notes
Actually it somehow seems that something is looking for TLDs at startup - that's a bug for me. The TLDs should be processed when the first JSP is complied - not before. If a webapp doesn't use JSPs or uses precompiled JSPs ( which is a very good idea IMO ) - then there is no point on scanning each jar for TLDs. I don't know anybody that likes it, but it's required by the JSP-1.2 spec (and still in the current draft of the JSP-2.0 spec). The TLDs may contain Listeners, and the only way to get them registered is to scan at startup. Costin -- 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: [5.0] Build notes
On Sun, 11 Aug 2002, Bill Barker wrote: I don't know anybody that likes it, but it's required by the JSP-1.2 spec (and still in the current draft of the JSP-2.0 spec). The TLDs may contain Listeners, and the only way to get them registered is to scan at startup. Ops, I missed that one. So you mean even if a webapp has no JSP at all - the TLDs are still processed ( sort of extension to web.xml ) ? I allways tought they are for translation, not runtime. I just downloaded the new servlet draft - and it seems the welcome file it defines is still unimplementable and violates all the current practices... I'm beginning to wonder who is Apache's representative to the JCP and how will he make the decision on what to vote... Costin Costin -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Build notes
On Sun, 2002-08-11 at 11:25, Jayson Falkner wrote:
I have been using the same thing. The only downside is the download
time, but, IMO it would be great to have this included and encouraged
for use with the Tomcat 5 build file.
Way to go Bob!
Thanks, although I just cut/pasted Ian Darwin's example.
It builds tomcat5 pretty well, but I would really like it if it also did
these things,
- building dist, start tomcat up
- download and run watchdog and generate a report
- If the report fails, then send an email to people who committed in
past 24 hours
- run automatically every 24 hours.
Sort of a mini-gump.
Cheers,
-bob
Jayson Falkner
[EMAIL PROTECTED]
Bob Herrmann wrote:
Yea, I liked your script, this one builds Tomcat 5.
BUILDING.TXT could almost just say All you need is JDK1.4 and Ant1.5
then just type 'ant' and a working Tomcat 5 development tree is built.
(If you are behind a firewall, you may need to adjust proxy settings.)
This should be cross platform (haven't tested it on Win32.)
Cheers,
-bob
project name=CVS Retrieval default=populate
property file=build.properties/
property name=apache.dir value=${user.home}/TC5/
property name=base.path value=${apache.dir}/download/
property name=cvsroot
value=:pserver:[EMAIL PROTECTED]:/home/cvspublic/
target name=populate depends=init,checkout,buildit /
target name=init
tstamp/
mkdir dir=${apache.dir}/
mkdir dir=${base.path}/
/target
target name=checkout depends=init
cvs package=jakarta-servletapi-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-catalina
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-connectors
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-jasper
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
/target
target name=buildit depends=init
echo message=Commons-logging build dies without this
file=${base.path}/LICENSE /
ant dir=${apache.dir}/jakarta-tomcat-5
target=download /
ant dir=${apache.dir}/jakarta-tomcat-5
target=dist /
/target
/project
On Tue, 2002-08-06 at 13:43, Ian Darwin wrote:
On August 6, 2002 01:01 pm, you wrote:
The main thing missing is a target which sets up the CVS repositories,
so it's quite close to what we have now. Problem is, I'm not too happy
at the idea of doing that automatically.
Trivial to do with Ant, but I agree, it's risky to automate this. OTOH if
it's well documented what it's doing, people should be OK with it.
Ian
project name=CVS Retrieval default=populate
!-- $Id: build.xml,v 1.1 2002/06/11 15:35:57 ian Exp $ --
!-- Maybe find a better way of setting this --
property name=apache.dir value=${user.home}/src/apache/
property name=cvs.root
value=:pserver:[EMAIL PROTECTED]:/home/cvspublic/
target name=init
tstamp/
mkdir dir=${apache.dir}/
/target
target name=populate depends=init
cvs package=jakarta-tomcat-4.0
cvsRoot=${cvs.root}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-connectors
cvsRoot=${cvs.root}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-jasper
cvsRoot=${cvs.root}
dest=${apache.dir}
/
/target
/project
--
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]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
Cheers,
-bob
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Build notes
Yea, I liked your script, this one builds Tomcat 5.
BUILDING.TXT could almost just say All you need is JDK1.4 and Ant1.5
then just type 'ant' and a working Tomcat 5 development tree is built.
(If you are behind a firewall, you may need to adjust proxy settings.)
This should be cross platform (haven't tested it on Win32.)
Cheers,
-bob
project name=CVS Retrieval default=populate
property file=build.properties/
property name=apache.dir value=${user.home}/TC5/
property name=base.path value=${apache.dir}/download/
property name=cvsroot
value=:pserver:[EMAIL PROTECTED]:/home/cvspublic/
target name=populate depends=init,checkout,buildit /
target name=init
tstamp/
mkdir dir=${apache.dir}/
mkdir dir=${base.path}/
/target
target name=checkout depends=init
cvs package=jakarta-servletapi-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-catalina
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-connectors
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-jasper
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
/target
target name=buildit depends=init
echo message=Commons-logging build dies without this
file=${base.path}/LICENSE /
ant dir=${apache.dir}/jakarta-tomcat-5
target=download /
ant dir=${apache.dir}/jakarta-tomcat-5
target=dist /
/target
/project
On Tue, 2002-08-06 at 13:43, Ian Darwin wrote:
On August 6, 2002 01:01 pm, you wrote:
The main thing missing is a target which sets up the CVS repositories,
so it's quite close to what we have now. Problem is, I'm not too happy
at the idea of doing that automatically.
Trivial to do with Ant, but I agree, it's risky to automate this. OTOH if
it's well documented what it's doing, people should be OK with it.
Ian
project name=CVS Retrieval default=populate
!-- $Id: build.xml,v 1.1 2002/06/11 15:35:57 ian Exp $ --
!-- Maybe find a better way of setting this --
property name=apache.dir value=${user.home}/src/apache/
property name=cvs.root
value=:pserver:[EMAIL PROTECTED]:/home/cvspublic/
target name=init
tstamp/
mkdir dir=${apache.dir}/
/target
target name=populate depends=init
cvs package=jakarta-tomcat-4.0
cvsRoot=${cvs.root}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-connectors
cvsRoot=${cvs.root}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-jasper
cvsRoot=${cvs.root}
dest=${apache.dir}
/
/target
/project
--
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: [5.0] Build notes
Bob Herrmann wrote: Hi. Just thought I would share the steps I followed to Build tomcat 5 on a RedHat 7.2 box. The box is net connected via DSL. I had already downloaded JDK1.4 and Ant1.5 $ mkdir tc5 $ cd tc5 $ export JAVA_HOME=/usr/java/j2sdk1.4.0 $ export PATH=$JAVA_HOME/bin:$PATH:/home/bob/tc5/jakarta-ant-1.5/bin $ cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login $ cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic checkout jakarta-tomcat-5 jakarta-tomcat-connectors jakarta-tomcat-jasper jakarta-servletapi-5 jakarta-tomcat-catalina $ cd jakarta-tomcat-5 $ sed -e 's/^base.path=\/usr\/local$/base.path=\/home\/test\/tc5\/dependson/' build.properties.default t $ mv t build.properties.default $ mkdir /home/bob/tc5/dependson $ echo /home/bob/tc5/dependson/LICENSE $ ant download $ ant dist $ dist/bin/startup.sh $ tail /home/bob/tc5/jakarta-tomcat-5/dist/logs/catalina.out I'd like to wait a bit before we do some instructions, as the build may not be stable yet (see Costin's recent experimentation to try to make building faster). (it looks simpler than 4.x, though, and that's a good thing) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Build notes
Bob, Bob Herrmann wrote: $ sed -e 's/^base.path=\/usr\/local$/base.path=\/home\/test\/tc5\/dependson/' build.properties.default t $ mv t build.properties.default You don't want to replace build.properties.default. Instead you want to put your customized file in build.properties. That way, if build.properties.default changes, you will know. Also, using build.properties prevents accidental commits to build.properties.default. Patrick -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Build notes
On Sun, 4 Aug 2002, Patrick Luby wrote: Bob, Bob Herrmann wrote: $ sed -e 's/^base.path=\/usr\/local$/base.path=\/home\/test\/tc5\/dependson/' build.properties.default t $ mv t build.properties.default You don't want to replace build.properties.default. Instead you want to put your customized file in build.properties. That way, if build.properties.default changes, you will know. Also, using build.properties prevents accidental commits to build.properties.default. Another sugestion ( see my commit ) - just create a ~/build.properties and use it to override base.path. That means: base.path=/. ( and nothing else - unless you have some other overrides to make ). No need to copy the whole file or do any file modifications. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
