tomcat 4 head download/dist targets

["Christopher K. St. John" <ck...@distributopia.com>]

 $ ant download

 commons-logging wants a ../LICENSE file. Quick fix by creating an
empty one in ${base.path} Not sure if this is a commons-logging
issue (should it build independently?) or a tomcat 4 download
target issue.

 commons-dbcp (which is optional) croaks the download target when
it can't find javax.sql (which is only available if you've got J2EE
or JDK 1.4) As a workaround, I just commented it out. One possibility
is to check for javax.sql before trying to download and build it.

 $ ant dist

 fails because the default build.properties.sample doesn't have
a "dist" on the end of servlet.home. Not really a bug, since you're
supposed to customize b.p.s, but I think the expectation is that if
you do a download/dist, it will all just work. 

 The issues above go away if actual binary releases are used for
the external packages, but I suppose that's a whole different can
of worms.


-- 
Christopher St. John cks@distributopia.com
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: tomcat 4 head download/dist targets

[jean-frederic clere <jf...@fujitsu-siemens.com>]

Christopher K. St. John wrote:
>  $ ant download
> 
>  commons-logging wants a ../LICENSE file. Quick fix by creating an
> empty one in ${base.path} Not sure if this is a commons-logging
> issue (should it build independently?) or a tomcat 4 download
> target issue.

It wants the jakarta-commons/LICENSE file. I have no noted it because I had a 
./LICENCE file in my ${base.path}.

That is no very nice to put a LICENSE file in ${base.path} but logging is not 
only component that uses the ../LICENCE.
I would like to avoid forcing the download of complete jakarta-commons tree.

> 
>  commons-dbcp (which is optional) croaks the download target when
> it can't find javax.sql (which is only available if you've got J2EE
> or JDK 1.4) As a workaround, I just commented it out. One possibility
> is to check for javax.sql before trying to download and build it.

Sounds good.

> 
>  $ ant dist
> 
>  fails because the default build.properties.sample doesn't have
> a "dist" on the end of servlet.home. Not really a bug, since you're
> supposed to customize b.p.s, but I think the expectation is that if
> you do a download/dist, it will all just work.

A quick patch in download could help - I will do it -

> 
>  The issues above go away if actual binary releases are used for
> the external packages, but I suppose that's a whole different can
> of worms.

I have cc common-dev to share the ideas ;-)

> 
> 




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: tomcat 4 head download/dist targets

[jean-frederic clere <jf...@fujitsu-siemens.com>]

Christopher K. St. John wrote:
>  $ ant download
> 
>  commons-logging wants a ../LICENSE file. Quick fix by creating an
> empty one in ${base.path} Not sure if this is a commons-logging
> issue (should it build independently?) or a tomcat 4 download
> target issue.

It wants the jakarta-commons/LICENSE file. I have no noted it because I had a 
./LICENCE file in my ${base.path}.

That is no very nice to put a LICENSE file in ${base.path} but logging is not 
only component that uses the ../LICENCE.
I would like to avoid forcing the download of complete jakarta-commons tree.

> 
>  commons-dbcp (which is optional) croaks the download target when
> it can't find javax.sql (which is only available if you've got J2EE
> or JDK 1.4) As a workaround, I just commented it out. One possibility
> is to check for javax.sql before trying to download and build it.

Sounds good.

> 
>  $ ant dist
> 
>  fails because the default build.properties.sample doesn't have
> a "dist" on the end of servlet.home. Not really a bug, since you're
> supposed to customize b.p.s, but I think the expectation is that if
> you do a download/dist, it will all just work.

A quick patch in download could help - I will do it -

> 
>  The issues above go away if actual binary releases are used for
> the external packages, but I suppose that's a whole different can
> of worms.

I have cc common-dev to share the ideas ;-)

> 
> 




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>