Re: cvs commit: jakarta-tomcat build.xml

[Henri Gomez]

[EMAIL PROTECTED] a écrit :

larryi  2003/10/01 19:50:59

  Modified:.build.xml
  Log:
  Update to build using MAIN branch of JTC coyote and http11.  The jars are
  a little different from coyote_10 version.
Thanks Larry

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat build.xml

[Bill Barker]

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 25, 2003 7:05 PM
Subject: cvs commit: jakarta-tomcat build.xml


> larryi  2003/01/25 19:05:33
>
>   Modified:.build.xml
>   Log:
>   Update commons-logging default version and add commons-modeler
>   properties.  Pass commons-modeler to http11 build.
>

modeler-1.0 doesn't work with j-t-c HEAD (the main reason that I was pushing
for a branch), and the j-t-c coyote_10 branch doesn't require modeler at all
for Tomcat 3.3.  What is the reason for adding in modeler to TC 3.3?



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat build.xml

[Larry Isaacs]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, April 09, 2002 3:11 PM
> To: Tomcat Developers List
> Subject: RE: cvs commit: jakarta-tomcat build.xml
> 
> 
> I'll commit a fix.
> 
> Larry, is it ok if we call the buildfile for j-t-c from 3.3's 
> build.xml ? 
> ( 4.0 is doing that too ).

I'm fine with that, though I think "clean" should also call "clean"
target(s) in j-t-c too, so "clean" cleans everything that
Tomcat 3.3.x uses.

> 
> The problem is the order which may be tricky - tomcat33 
> depends on j-t-c 
> utils and it will copy coyote. But coyote depens on tomcat33 
> beeing build, 
> so it can find the classes.
> 
> It would make things cleaner I think - right now I'm using 
> scripts and 
> workarounds... Tomcat3.3 will call things in the right order 
> and get all
> things in place.

This sounds fine.  I was trying in my initial build.xml update to
keep Gump working, but wasn't wasn't successful. :-(

Larry

> 
> Costin
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:tomcat-dev-> [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: cvs commit: jakarta-tomcat build.xml

[costinm]

I'll commit a fix.

Larry, is it ok if we call the buildfile for j-t-c from 3.3's build.xml ? 
( 4.0 is doing that too ).

The problem is the order which may be tricky - tomcat33 depends on j-t-c 
utils and it will copy coyote. But coyote depens on tomcat33 beeing build, 
so it can find the classes.

It would make things cleaner I think - right now I'm using scripts and 
workarounds... Tomcat3.3 will call things in the right order and get all
things in place.

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat build.xml

[Bill Barker]

- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, April 09, 2002 10:14 AM
Subject: Re: cvs commit: jakarta-tomcat build.xml


> > On Tue, 9 Apr 2002, Larry Isaacs wrote:
> >
> > > The instructions for installing Coyote on Tomcat 3.3.x say to
> > > replace connectors_util.jar with j-t-c's tomcat-utils.jar.  Since
> >
> > j-t-c tomcat-utils are a subset of tomcat-utils.jar from container/
> >
> > Sorry, I didn't read the instructions for Coyote - I'm using coyote
> > with the 'old' minimal common loader and it works fine.
>
> If there are problems with those install instructions, let me know.
> Coyote used some bugfixes which were included in TC after 3.3, so that's
the
> reason for those instructions.
>
The tomcat-utils.jar replacement is optional with 3.3.1, but at the moment
they are fine.

Neither of the CoyoteInterceptors is passing watchdog at the moment.  This
mostly means that the original version is likely to get deprecated sooner
rather than later.  At that point, the instructions will change.
> Remy
>
>
> --
> 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: cvs commit: jakarta-tomcat build.xml

[Larry Isaacs]

> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, April 09, 2002 1:15 PM
> To: Tomcat Developers List
> Subject: Re: cvs commit: jakarta-tomcat build.xml
> 
> 
> > On Tue, 9 Apr 2002, Larry Isaacs wrote:
> >
> > > The instructions for installing Coyote on Tomcat 3.3.x say to
> > > replace connectors_util.jar with j-t-c's tomcat-utils.jar.  Since
> >
> > j-t-c tomcat-utils are a subset of tomcat-utils.jar from container/
> >
> > Sorry, I didn't read the instructions for Coyote - I'm using coyote
> > with the 'old' minimal common loader and it works fine.
> 
> If there are problems with those install instructions, let me know.
> Coyote used some bugfixes which were included in TC after 
> 3.3, so that's the
> reason for those instructions.

The instructions are fine.  It's just that after following them for
Tomcat 3.3, you have a tomcat-util.jar in lib/common and a
tomcat_util.jar in lib/container.  We have just demonstrated how
easy it is to get them confused. :)

To avoid confusion, I'll go with Costin's suggestion of renaming the
tomcat_util.jar in lib/container to container_util.jar.

Cheers,
Larry

> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:tomcat-dev-> [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: cvs commit: jakarta-tomcat build.xml

[Larry Isaacs]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, April 09, 2002 2:09 PM
> To: Tomcat Developers List
> Subject: RE: cvs commit: jakarta-tomcat build.xml
> 
> 
> On Tue, 9 Apr 2002, Larry Isaacs wrote:
> 
> > The instructions for installing Coyote on Tomcat 3.3.x say to
> > replace connectors_util.jar with j-t-c's tomcat-utils.jar.  Since
> 
> j-t-c tomcat-utils are a subset of tomcat-utils.jar from container/
> 
> Sorry, I didn't read the instructions for Coyote - I'm using coyote
> with the 'old' minimal common loader and it works fine.
> 
> I have 2 concerns:
> - we can't have same tomcat-utils.jar name and different content 
> in common and container. 
> - I want to make sure all code that goes to common is carefully 
> reviewed from security standpoint. We had a potential problem
> with jdk11 compat package ( now it is safe, but at some point it 
> wasn't ). That's the main reason for keeping only minimal utils.

I'm +1 on this too.

> 
> 
> > the tomcat-utils.jar that j-t-c builds.  So why not just use the
> > "util" jar that j-t-c builds?  I would be +1 for renaming the
> > "util" jar that j-t-c builds to connectors_util.jar to avoid
> > name confusion with the tomcat_util.jar.
> 
> Or we can rename container/tomcat_util.jar to 
> container/container_util.jar, and leave tomcat_util name to j-t-c.

You mean leave "tomcat-util" to j-t-c.  Yes, '-' and '_' aren't
sufficient differences in the name.  Using container_util.jar sounds
good to me.  Are you okay with using the tomcat-utils.jar built
by j-t-c, rather than the current build creation of
connector_utils.jar?

> 
> Both are fine - but we still need to review any extra class that 
> ends in common ( i.e. re-read the code and look for static
> methods/fields, package-protected methods, doPriviledged blocks, etc )
> I will do that, but it would help if you could duplicate :-)
> ( duplication is good sometimes ).

I'll try to find some time to help with this.

Cheers,
Larry


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: cvs commit: jakarta-tomcat build.xml

[Remy Maucherat]

> On Tue, 9 Apr 2002, Larry Isaacs wrote:
>
> > The instructions for installing Coyote on Tomcat 3.3.x say to
> > replace connectors_util.jar with j-t-c's tomcat-utils.jar.  Since
>
> j-t-c tomcat-utils are a subset of tomcat-utils.jar from container/
>
> Sorry, I didn't read the instructions for Coyote - I'm using coyote
> with the 'old' minimal common loader and it works fine.

If there are problems with those install instructions, let me know.
Coyote used some bugfixes which were included in TC after 3.3, so that's the
reason for those instructions.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat build.xml

[costinm]

On Tue, 9 Apr 2002, Larry Isaacs wrote:

> The instructions for installing Coyote on Tomcat 3.3.x say to
> replace connectors_util.jar with j-t-c's tomcat-utils.jar.  Since

j-t-c tomcat-utils are a subset of tomcat-utils.jar from container/

Sorry, I didn't read the instructions for Coyote - I'm using coyote
with the 'old' minimal common loader and it works fine.

I have 2 concerns:
- we can't have same tomcat-utils.jar name and different content 
in common and container. 
- I want to make sure all code that goes to common is carefully 
reviewed from security standpoint. We had a potential problem
with jdk11 compat package ( now it is safe, but at some point it 
wasn't ). That's the main reason for keeping only minimal utils.


> the tomcat-utils.jar that j-t-c builds.  So why not just use the
> "util" jar that j-t-c builds?  I would be +1 for renaming the
> "util" jar that j-t-c builds to connectors_util.jar to avoid
> name confusion with the tomcat_util.jar.

Or we can rename container/tomcat_util.jar to 
container/container_util.jar, and leave tomcat_util name to j-t-c.

Both are fine - but we still need to review any extra class that 
ends in common ( i.e. re-read the code and look for static
methods/fields, package-protected methods, doPriviledged blocks, etc )
I will do that, but it would help if you could duplicate :-)
( duplication is good sometimes ).

> 
> I don't have any special urge to have a single "util" jar.
> I find it preferable to not have a XML parser in the common loader.
> IMHO, auto-adding the XML parser to the web application loader is a
> good solution for providing a default XML parser.  If this means we
> keep separate common and container "util" jars, I'm in favor of that.

No, xml parser in common was not the issue. XmlMapper is also ok and
could sit in common loader. The only problem is that XmlMapper doesn't
work at this moment in common/ because we don't set the
context loader to point to container/ ( this also affects common-logger ).

I think the only reason for keeping some utils in container is 
security and webapp-awareness - as we find time and review the code we can
move it to common.

By webapp-awareness I mean it should deal with the fact that webapps
may use it and use thread class loader instead of Class.forName, etc.
Not all code 'behaves' nicely in commons, and I would like to avoid
playing ClassLoader tricks and breaking delegation.

Costin 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat build.xml

[GOMEZ Henri]

>> tomcat_util.jar ( in container ) has all of the tools.
>
>The instructions for installing Coyote on Tomcat 3.3.x say to
>replace connectors_util.jar with j-t-c's tomcat-utils.jar.  Since
>I plan to include Coyote in Tomcat 3.3.2 distribution, then
>the "util" jar we ship in common loader must remain compatible with
>the tomcat-utils.jar that j-t-c builds.  So why not just use the
>"util" jar that j-t-c builds?  I would be +1 for renaming the
>"util" jar that j-t-c builds to connectors_util.jar to avoid
>name confusion with the tomcat_util.jar.

+1

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat build.xml

[Larry Isaacs]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, April 09, 2002 2:50 AM
> To: Tomcat Developers List
> Subject: RE: cvs commit: jakarta-tomcat build.xml
> 
> 
> On Mon, 8 Apr 2002, Larry Isaacs wrote:
> 
> > It's not so much having one "util" jar, but understanding 
> the differences
> > between jakarta-tomcat-connectors' tomcat-util.jar and 
> connectors_util.jar.
> > If they are the same, then I would prefer to use a single name.
> 
> They are certainly not the same ( or they weren't in 3.3.0/3.3.1 ).
> 
> "Tomcat utils" are a collection of (more or less independent) 
> tools. In 
> tomcat3.3 we put some of them in the common loader ( the minimal set 
> required to get things running ), and the rest in the 
> container loader.
> 
> The 'minimal' set consist of core_util.jar and connectors_util.jar.
> 
> tomcat_util.jar ( in container ) has all of the tools.

The instructions for installing Coyote on Tomcat 3.3.x say to
replace connectors_util.jar with j-t-c's tomcat-utils.jar.  Since
I plan to include Coyote in Tomcat 3.3.2 distribution, then
the "util" jar we ship in common loader must remain compatible with
the tomcat-utils.jar that j-t-c builds.  So why not just use the
"util" jar that j-t-c builds?  I would be +1 for renaming the
"util" jar that j-t-c builds to connectors_util.jar to avoid
name confusion with the tomcat_util.jar.

> 
> I think it would be a mistake to name the jar in common with the same 
> name, since they have different content. If we put all the 
> utils in common 
> ( which wouldn't be bad - the reasons for keeping the 
> 'minimal set' only
> are not very strong ) - then we can name it tomcat_util.jar, 
> and remove
> the one in container.
> 
> If we do that, we need to fix few bugs - XmlMapper will not 
> work because
> crimson is in container/, and we don't set the thread class loader to
> container/ when starting up. 

I don't have any special urge to have a single "util" jar.
I find it preferable to not have a XML parser in the common loader.
IMHO, auto-adding the XML parser to the web application loader is a
good solution for providing a default XML parser.  If this means we
keep separate common and container "util" jars, I'm in favor of that.

Cheers,
Larry

> 
> The main reason for doing the minimal set was a bit of 
> security paranoia,
> the utils are used by the core and we must be sure they don't expose 
> anything ( static fields/methods, priviledged actions, etc ). 
> For example
> the compat util used to have a bug allowing untrusted code to 
> run trusted
> apps ( it had a doPriviledged without checking the source ). 
> I'm 99% sure
> we're ok.
> 
> Other reasons - like allowing apps to load different versions 
> of utils -
> are not that important. Somehow important is to make sure all utils 
> are webapp-friendly ( ie. use thread class loader - like  
> commons-logging for example )
> 
> Costin

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: cvs commit: jakarta-tomcat build.xml

[costinm]

On Mon, 8 Apr 2002, Larry Isaacs wrote:

> It's not so much having one "util" jar, but understanding the differences
> between jakarta-tomcat-connectors' tomcat-util.jar and connectors_util.jar.
> If they are the same, then I would prefer to use a single name.

They are certainly not the same ( or they weren't in 3.3.0/3.3.1 ).

"Tomcat utils" are a collection of (more or less independent) tools. In 
tomcat3.3 we put some of them in the common loader ( the minimal set 
required to get things running ), and the rest in the container loader.

The 'minimal' set consist of core_util.jar and connectors_util.jar.

tomcat_util.jar ( in container ) has all of the tools.

I think it would be a mistake to name the jar in common with the same 
name, since they have different content. If we put all the utils in common 
( which wouldn't be bad - the reasons for keeping the 'minimal set' only
are not very strong ) - then we can name it tomcat_util.jar, and remove
the one in container.

If we do that, we need to fix few bugs - XmlMapper will not work because
crimson is in container/, and we don't set the thread class loader to
container/ when starting up. 

The main reason for doing the minimal set was a bit of security paranoia,
the utils are used by the core and we must be sure they don't expose 
anything ( static fields/methods, priviledged actions, etc ). For example
the compat util used to have a bug allowing untrusted code to run trusted
apps ( it had a doPriviledged without checking the source ). I'm 99% sure
we're ok.

Other reasons - like allowing apps to load different versions of utils -
are not that important. Somehow important is to make sure all utils 
are webapp-friendly ( ie. use thread class loader - like  
commons-logging for example )

Costin


> Cheers,
> Larry
>  
> 
> -Original Message- 
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
> Sent: Mon 4/8/2002 6:37 PM 
> To: Tomcat Developers List 
> Cc: 
> Subject: RE: cvs commit: jakarta-tomcat build.xml
> 
> 
> 
> On Mon, 8 Apr 2002, Larry Isaacs wrote: 
> 
> > Hi Costin, 
> >  
> > I'm curious as to the reason to have connectors_util.jar instead 
> > of just using the tomcat-utils.jar built by j-t-c/util? 
> 
> We have 2 'sets' of utils - one in j-t-c/util, one in j-t. 
> We also have 2 lib dirs - lib/common and lib/container. 
> 
> The way we used to split the utils - we put minimal stuff in common, 
> and that was core_utils and connector_utils. That's how 3.3.0/3.3.1 
> are doing it.  
> 
> I'm +1 to change to a single tomcat-util.jar in common, but 
> that requires few fixes in xml-mapper ( actually in startup, to 
> make xml-mapper find the thread loader pointing to container ). 
> It also requires another review of the utils/ from security 
> point of view - whatever is in common must be safe, since 
> it'll be exposed to untrusted apps. 
> 
> Costin 
> 
> 
> 
> 



msg24683/bin0.bin
Description: application/ms-tnef

--
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: cvs commit: jakarta-tomcat build.xml

[Larry Isaacs]

It's not so much having one "util" jar, but understanding the differences
between jakarta-tomcat-connectors' tomcat-util.jar and connectors_util.jar.
If they are the same, then I would prefer to use a single name.
 
Cheers,
Larry
 

-Original Message- 
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
Sent: Mon 4/8/2002 6:37 PM 
To: Tomcat Developers List 
Cc: 
Subject: RE: cvs commit: jakarta-tomcat build.xml



On Mon, 8 Apr 2002, Larry Isaacs wrote: 

> Hi Costin, 
>  
> I'm curious as to the reason to have connectors_util.jar instead 
> of just using the tomcat-utils.jar built by j-t-c/util? 

We have 2 'sets' of utils - one in j-t-c/util, one in j-t. 
We also have 2 lib dirs - lib/common and lib/container. 

The way we used to split the utils - we put minimal stuff in common, 
and that was core_utils and connector_utils. That's how 3.3.0/3.3.1 
are doing it.  

I'm +1 to change to a single tomcat-util.jar in common, but 
that requires few fixes in xml-mapper ( actually in startup, to 
make xml-mapper find the thread loader pointing to container ). 
It also requires another review of the utils/ from security 
point of view - whatever is in common must be safe, since 
it'll be exposed to untrusted apps. 

Costin 



-- 
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]> > 
For additional commands, e-mail: <mailto:[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]> > 




msg24681/bin0.bin
Description: application/ms-tnef

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: cvs commit: jakarta-tomcat build.xml

[costinm]

On Mon, 8 Apr 2002, Larry Isaacs wrote:

> Hi Costin,
>  
> I'm curious as to the reason to have connectors_util.jar instead
> of just using the tomcat-utils.jar built by j-t-c/util?

We have 2 'sets' of utils - one in j-t-c/util, one in j-t.
We also have 2 lib dirs - lib/common and lib/container. 

The way we used to split the utils - we put minimal stuff in common,
and that was core_utils and connector_utils. That's how 3.3.0/3.3.1
are doing it.  

I'm +1 to change to a single tomcat-util.jar in common, but 
that requires few fixes in xml-mapper ( actually in startup, to
make xml-mapper find the thread loader pointing to container ).
It also requires another review of the utils/ from security
point of view - whatever is in common must be safe, since
it'll be exposed to untrusted apps.

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat build.xml

[Larry Isaacs]

Hi Costin,
 
I'm curious as to the reason to have connectors_util.jar instead
of just using the tomcat-utils.jar built by j-t-c/util?
 
Cheers,
Larry

-Original Message- 
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
Sent: Mon 4/8/2002 4:00 PM 
To: [EMAIL PROTECTED] 
Cc: 
Subject: cvs commit: jakarta-tomcat build.xml



costin  02/04/08 13:00:37 

  Modified:.build.xml 
  Log: 
  Forgot one jar, resources. 
  
  XXX Must fix the bugs that prevent putting the whole tomcat_util.jar in common, 
  check that all utils are 'safe', and move them. Same for common-logging. 
  
  Revision  ChangesPath 
  1.168 +11 -0 jakarta-tomcat/build.xml 
  
  Index: build.xml 
  === 
  RCS file: /home/cvs/jakarta-tomcat/build.xml,v 
  retrieving revision 1.167 
  retrieving revision 1.168 
  diff -u -r1.167 -r1.168 
  --- build.xml 8 Apr 2002 19:44:28 -   1.167 
  +++ build.xml 8 Apr 2002 20:00:37 -   1.168 
  @@ -300,6 +300,17 @@ 
  

   
  + 
  +   
  + 
  + 
  + 
  + 
  + 
  + 
  +   
  + 
  + 

  

  
  
  

-- 
To unsubscribe, e-mail:    > 
For additional commands, e-mail:  > 




msg24657/bin0.bin
Description: application/ms-tnef

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat build.xml

[Mike Anderson]

No problem.   Of course I would never make
a mistake like that  unless of course I
actually try to modify the code :-)

Mike Anderson

>>> [EMAIL PROTECTED] 06/19/01 01:23AM >>>
doh, thanks Mike..

Saludos ,
Ignacio J. Ortega


> -Mensaje original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
> Enviado el: martes 19 de junio de 2001 2:35
> Para: [EMAIL PROTECTED] 
> Asunto: cvs commit: jakarta-tomcat build.xml
> 
> 
> mmanders01/06/18 17:34:38
> 
>   Modified:.build.xml
>   Log:
>   Updated conditionals for commons-dbcp.  This will now build 
> properly even if jakarta-commons isn't available.
>   
>   Revision  ChangesPath
>   1.135 +29 -30jakarta-tomcat/build.xml
>   
>   Index: build.xml
>   ===
>   RCS file: /home/cvs/jakarta-tomcat/build.xml,v
>   retrieving revision 1.134
>   retrieving revision 1.135
>   diff -u -r1.134 -r1.135
>   --- build.xml   2001/06/17 18:59:39 1.134
>   +++ build.xml   2001/06/19 00:34:37 1.135
>   @@ -38,10 +38,16 @@
>
>  location="${ws}/jakarta-tomcat-jasper" />
>   +
>   + +location="${ws}/jakarta-commons" />
>
>  
>  
>   @@ -54,18 +60,6 @@
>  
>  
>
>   -  
>   -
>   -
>   -
>   -
>   -
>   -
>   -
>   -
>   -
>   -  
>   -
>  
>  
>   @@ -80,8 +74,7 @@
>   file="${jsse.lib}/jsse.jar"/>
>   -   
> classname="org.apache.commons.dbcp.DriverManagerConnectionFactory"
>   -   classpathref="commons-dbcp"/>
>   +   
> file="${jakarta-commons}/dbcp/dist/commons-dbcp.jar" />
>   classname="java.security.PrivilegedAction"/>
>   @@ -109,6 +102,7 @@
>  
>
>  
>   +  
>   depends="detect,msg.jdk12,msg.jsse,msg.jtc,msg.jtj,msg.commons-dbcp" >
>  
>
>   @@ -380,23 +374,26 @@
>  
>
>
>   -  
>   -
>   -
>   -
>   -
>   -
>   -
>   -
>   -
>   -
>   -
>   -
>   -
>   +-->
>   +
>   +
>   +
>   +
>   +
>   +
>   +
>   +
>   +
>   +
>   +
>   +
>  
>
>  
>   @@ -410,8 +407,10 @@
> location="${tomcat.build}/lib/common/connector_util.jar"/>
> location="${tomcat.build}/lib/container/tomcat_util.jar"/>
> location="${tomcat.build}/lib/common/tomcat_core.jar"/>
>   +
>   +
>   +
>  
>   -  
>  
>
> name="org/apache/tomcat/modules/config/LoaderInterceptor12.java"
>   
>   
>   
> 

RE: cvs commit: jakarta-tomcat build.xml

[Ignacio J. Ortega]

doh, thanks Mike..

Saludos ,
Ignacio J. Ortega


> -Mensaje original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Enviado el: martes 19 de junio de 2001 2:35
> Para: [EMAIL PROTECTED]
> Asunto: cvs commit: jakarta-tomcat build.xml
> 
> 
> mmanders01/06/18 17:34:38
> 
>   Modified:.build.xml
>   Log:
>   Updated conditionals for commons-dbcp.  This will now build 
> properly even if jakarta-commons isn't available.
>   
>   Revision  ChangesPath
>   1.135 +29 -30jakarta-tomcat/build.xml
>   
>   Index: build.xml
>   ===
>   RCS file: /home/cvs/jakarta-tomcat/build.xml,v
>   retrieving revision 1.134
>   retrieving revision 1.135
>   diff -u -r1.134 -r1.135
>   --- build.xml   2001/06/17 18:59:39 1.134
>   +++ build.xml   2001/06/19 00:34:37 1.135
>   @@ -38,10 +38,16 @@
>
>  location="${ws}/jakarta-tomcat-jasper" />
>   +
>   + +location="${ws}/jakarta-commons" />
>
>  
>  
>   @@ -54,18 +60,6 @@
>  
>  
>
>   -  
>   -
>   -
>   -
>   -
>   -
>   -
>   -
>   -
>   -
>   -  
>   -
>  
>  
>   @@ -80,8 +74,7 @@
>   file="${jsse.lib}/jsse.jar"/>
>   -   
> classname="org.apache.commons.dbcp.DriverManagerConnectionFactory"
>   -   classpathref="commons-dbcp"/>
>   +   
> file="${jakarta-commons}/dbcp/dist/commons-dbcp.jar" />
>   classname="java.security.PrivilegedAction"/>
>   @@ -109,6 +102,7 @@
>  
>
>  
>   +  
>   depends="detect,msg.jdk12,msg.jsse,msg.jtc,msg.jtj,msg.commons-dbcp" >
>  
>
>   @@ -380,23 +374,26 @@
>  
>
>
>   -  
>   -
>   -
>   -
>   -
>   -
>   -
>   -
>   -
>   -
>   -
>   -
>   -
>   +-->
>   +
>   +
>   +
>   +
>   +
>   +
>   +
>   +
>   +
>   +
>   +
>   +
>  
>
>  
>   @@ -410,8 +407,10 @@
> location="${tomcat.build}/lib/common/connector_util.jar"/>
> location="${tomcat.build}/lib/container/tomcat_util.jar"/>
> location="${tomcat.build}/lib/common/tomcat_core.jar"/>
>   +
>   +
>   +
>  
>   -  
>  
>
> name="org/apache/tomcat/modules/config/LoaderInterceptor12.java"
>   
>   
>   
>