You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jon Stevens <jo...@latchkey.com> on 2001/09/18 06:04:22 UTC
[T4] Build Frustration
It frustrates me to no end that building Tomcat 4 is dependent on Sun .jar
files that require a registration in order to download.
BUILD FAILED
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/build.xml:117: Could not
find file /Users/jon/checkout/jndi-1.2.1/lib/ldap.jar to copy.
At least one of them (jndi/ldap.jar) is required. The jmx.jar is also behind
a registration.
In general, I don't mind the fact that we rely on Sun .jar files. What I
mind is that we depend on Sun .jar files which are behind a registration
process.
What can be done about this?
-jon
Re: [T4] Build Frustration
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
Remy Maucherat wrote:
>
> > It frustrates me to no end that building Tomcat 4 is dependent on Sun .jar
> > files that require a registration in order to download.
>
> I was about complain, but I didn't want to tweak too much the build system
> just before the final release.
>
> Since both sides have a point (for the record, I'm on the
> as-many-optional-dependencies-as-possible side), I'd suggest implementing
> both in the build scripts (see below).
>
> > BUILD FAILED
> > /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build.xml:117: Could not
> > find file /Users/jon/checkout/jndi-1.2.1/lib/ldap.jar to copy.
> >
> > At least one of them (jndi/ldap.jar) is required. The jmx.jar is also
> behind
> > a registration.
> >
> > In general, I don't mind the fact that we rely on Sun .jar files. What I
> > mind is that we depend on Sun .jar files which are behind a registration
> > process.
>
> I totally agree.
>
> > What can be done about this?
>
> I suggest having two build targets (and two matching dist targets) :
> - main, which would have as few dependencies as possible (using lots of
> conditional compile / copy switches)
> - main-full (or main-all, or something like it), which would compile and
> copy everything, as the current build system does (and therefore, be used
> for releases and full regression testing)
>
> My main concern is that the current build system will definitely scare away
> the casual contributor (who usually submits one or two patches to fix the
> bug / problem he found, or add one or two features). Yet, having bug reports
> with patch attached is exremely helpful (since reproducing the bug in the
> first place can be very time consuming).
>
> I would suggest we vote on the issue:
>
> [ ] A: Leave the build system as is
> [ ] B: Make as many libraries as possible optional
> [ ] C: Provide both, as discussed above; I'll volunteer to implement it (but
> of course, others can help)
>
> I vote C.
>
> Remy
I vote B, but C would be acceptable also.
Perhaps now that Tomcat 4 final is released we can make the build more
flexible. The change I to the build a few days ago which Craig reverted
would be a start.
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: [T4] Build Frustration
Posted by Punky Tse <pu...@yahoo.com>.
>
> The current build system has gotten to be a mess (again) in the last few
> months.
>
Jon,
I worked very hard every few days in this month to make my TC4 built
successfully.... May be I was the one who found more frustrated than you.
Although I see that there are active changes to the build system a week or
so ago, I don't believe that the 4.0 Release will come out so soon.
Nothing is perfect. May be next time, TC4.1 should have a better, more
stablilized and flexible build system.
Punky
Re: [T4] Build Frustration
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/17/01 9:25 PM, "Remy Maucherat" <re...@apache.org> wrote:
> My main concern is that the current build system will definitely scare away
> the casual contributor (who usually submits one or two patches to fix the
> bug / problem he found, or add one or two features). Yet, having bug reports
> with patch attached is exremely helpful (since reproducing the bug in the
> first place can be very time consuming).
The current build system has gotten to be a mess (again) in the last few
months.
> I would suggest we vote on the issue:
>
> [ ] A: Leave the build system as is
> [ ] B: Make as many libraries as possible optional
> [X] C: Provide both, as discussed above; I'll volunteer to implement it (but
> of course, others can help)
-jon
Re: [T4] Build Frustration
Posted by Remy Maucherat <re...@apache.org>.
> It frustrates me to no end that building Tomcat 4 is dependent on Sun .jar
> files that require a registration in order to download.
I was about complain, but I didn't want to tweak too much the build system
just before the final release.
Since both sides have a point (for the record, I'm on the
as-many-optional-dependencies-as-possible side), I'd suggest implementing
both in the build scripts (see below).
> BUILD FAILED
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build.xml:117: Could not
> find file /Users/jon/checkout/jndi-1.2.1/lib/ldap.jar to copy.
>
> At least one of them (jndi/ldap.jar) is required. The jmx.jar is also
behind
> a registration.
>
> In general, I don't mind the fact that we rely on Sun .jar files. What I
> mind is that we depend on Sun .jar files which are behind a registration
> process.
I totally agree.
> What can be done about this?
I suggest having two build targets (and two matching dist targets) :
- main, which would have as few dependencies as possible (using lots of
conditional compile / copy switches)
- main-full (or main-all, or something like it), which would compile and
copy everything, as the current build system does (and therefore, be used
for releases and full regression testing)
My main concern is that the current build system will definitely scare away
the casual contributor (who usually submits one or two patches to fix the
bug / problem he found, or add one or two features). Yet, having bug reports
with patch attached is exremely helpful (since reproducing the bug in the
first place can be very time consuming).
I would suggest we vote on the issue:
[ ] A: Leave the build system as is
[ ] B: Make as many libraries as possible optional
[ ] C: Provide both, as discussed above; I'll volunteer to implement it (but
of course, others can help)
I vote C.
Remy