ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: Speaking of deprecation...
Date Sat, 09 Feb 2002 07:18:33 GMT

----- Original Message -----
From: "Conor MacNeill" <>
To: "Ant Developers List" <>
Sent: Friday, February 08, 2002 4:17 PM
Subject: Re: Speaking of deprecation...

> Stephane Bailliez wrote:
> > ----- Original Message -----
> > From: <>
> >
> >>I really _hate_ the 'deprecated' message in ant. Especially when it's
> >>
> >
> > I hate also the deprecated message in the java compiler but it is here
> > remind me something.
> > Fortunately I think I rarely use deprecated methods/class since a
> > sophisticated IDE usually identify this during auto-completion.
> >
> > But maybe we can add a -deprecated to Ant to be javac like.
> >
> What about if deprecation warnings were a different message level,
> something like Project.MSG_DEPRECATED, perhaps between INFO and VERBOSE.
> A command line option to show them or not would be possible and we could
> print a summary at the end if there are any deprecated messages
> received, just as javac does. It would also explicitly mark deprecated
> tasks and attributes.

I was thinking today that maybe a better approach would be to have a method
in Task in which the ant version at which the task was removed in was
retained, giving supervision code a bit more control about information.

void DeprecationWarning(double version,string text)

this could deal with warnings; you could somehow configure the runtime with
a version config flag:

     <version release="1.2" action="fail"/>
     <version release="1.3" action="warn"/>
     <version release="1.4" action="ignore"/>

which would say ignore 1.2 or earlier, warn for 1.3 and ignore 1.4 hints

but the trouble with that approach is that you are speccing deprecation
policy in the build file, not in the command line.

you could do something convoluted on the command line:

-deprecation:warn:1.3  -deprecation:fail:1.2

; it might be better to spec on the command line the version of ant you want
deprecation warnings to be ignored at and be done, with one call, the
version of ant you want deprecation warnings to be silent app.

Of course, the first implementation could just print stuff out; but ensuring
that version info is kept in the deprecation message gives us the
opportunity to change that behavior without fixing up all the old code.

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

View raw message