On Fri, 8 Feb 2002, Steve Loughran wrote: > > > 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: > > <deprecation> > <version release="1.2" action="fail"/> > <version release="1.3" action="warn"/> > <version release="1.4" action="ignore"/> > </deprecation>
Why all that complication ??? The <deprecation> tag will obviously not work with ant1.2 or ant1.3, so it defeats it's purpose ( to allow people to write build.xml files that work with ant1.2 and up ). Also, not sure about 'fail' - if the feature was removed ( because it crashed the computer or was mispelled ), it'll fail anyway. If it is still there, wouldn't a warning be enough ? Javac behavior is good enough. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
