tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: PATCH: build test broken on Windows: moo not in classpath
Date Sat, 11 Dec 1999 16:00:35 GMT

> True, a much better solution would be to have elements inside elements
> and use XML syntax to do the job (as it should have since the
> beginning), on the other hand this requires much more changes on both
> code and build files.
> Can we vote on this?

>I think its better to do the right fix... The attribute based stuff is
>and easy but what your really want to do is express your build correctly,
>right ?
>Probably attributes should be limited to the case where there's a one to
>relationship between the tag and the attribute value.  The classpath can
>viewed as having different components in which case it would be better to
>have child elements.

You both are correct.  Before I go any further, however, let me first state
that my first priority is to get ant back to the point where it builds on
Windows with a 1.1.8 level of the JDK.  There have been a number of reports
of problems, but little in way of response.  Now I have some patches in the
queue, and we'll see how far that advances the cause.

I am prepared to apply the same "energy and persistence" which endeared me
to tomcat team to this - If and only if I see some evidence that patches
are being accepted and applied *OR* I get sufficient Karma to make the
changes myself.  My preference is for the latter.

Given that Ant is now being used in multiple projects, a phased
implementation is called for.

1. The internal representation should be fixed.  It shouldn't be modeled as
   a simple bean property, instead it should be modeled as an indexed

2. An _additional_ XML representation for this information should be
   defined, and at the same time all the Tomcat usages should be cut over
   to the new method.  This should be preceded by proposals and a vote on
   the actual DTD.  My preference is for a <classpath> entity to be nested
   directly inside of <target> entity to which it affects.  This
   <classpath> entity would contain one or more nexted <pathentry>

3. Code should be put in place to issue deprecation warnings on the prior
   usage.  The date for this should be well known, and need not coincide
   with the provision of the alternative syntax.

4. After a suitable period of time, the old support should be summarily

P.S. I now know the root cause of the process breakdown on getting
   committer status.  The process calls for a vote, and calls for Brian to
   do the necessary authorizations.  What is not specified is the mechanism
   for informing Brian of the result.  Brian only requires nofication by "
   someone authoritative for the relevant code base".

View raw message