Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 91708 invoked from network); 28 Nov 2001 00:17:26 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 28 Nov 2001 00:17:26 -0000 Received: (qmail 1243 invoked by uid 97); 28 Nov 2001 00:17:30 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 1227 invoked by uid 97); 28 Nov 2001 00:17:29 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 1216 invoked from network); 28 Nov 2001 00:17:28 -0000 From: "Conor MacNeill" To: "Ant Developers List" Subject: RE: removing deprecated stuff Date: Wed, 28 Nov 2001 11:19:49 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200111230402.fAN42rO03987@mail016.syd.optusnet.com.au> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > From: Peter Donald [mailto:peter@apache.org] >=20 > deprecation does not imply that we are removing the=20 > functionality. Just that=20 > it is unsafe, unsupported whatever or perhaps we just prefer you=20 > write build=20 > files like this rather than that. I have to disagree. Deprecation is an indication that a feature is going = to be removed and its future use is not supported. Further it is, IMHO, = a warning of a small backward compatability break in a controlled = fashion. =20 If we could never remove such features, then why bother deprecating at = all? Is it just to make the build output ugly? An example below from = Tomcat build. Why do we make the users who do bother to upgrade = continually jump through hoops changing attribute names to avoid = warnings? Is it just because *we* feel "file" is better than "jarfile"? = How conceited we are then! So, if we are not going to remove deprecated features, I would vote that = we remove deprecation warnings. They are useless. Conor deploy-static: [fixcrlf] DEPRECATED: The cr attribute has been deprecated, [fixcrlf] Please us the eol attribute instead [fixcrlf] DEPRECATED: The cr attribute has been deprecated, [fixcrlf] Please us the eol attribute instead deploy-main: [jar] DEPRECATED - The jarfile attribute is deprecated. Use file = attribute instead. [jar] Building jar: = D:\antdev\jakarta-tomact-4.0\build\jasper\jasper-compiler.jar [jar] DEPRECATED - The jarfile attribute is deprecated. Use file = attribute instead. [jar] Building jar: = D:\antdev\jakarta-tomact-4.0\build\lib\jasper-runtime.jar -- To unsubscribe, e-mail: For additional commands, e-mail: