----- Original Message ----- From: "Peter Donald" <[EMAIL PROTECTED]> To: "Ant Developers List" <[EMAIL PROTECTED]> Sent: Saturday, November 24, 2001 9:19 PM Subject: Re: removing deprecated stuff
> On Sun, 25 Nov 2001 10:31, Steve Loughran wrote: > > Actually, we can something very simple for deprecation: > > > > pull the deprecated entry points out into a separate library. > > works for me. Woudn't this only work for deprecated tasks? What about the deprecated APIs? How would you remove the deprecated methods within an undeprecated task? Also, how are we planning to migrate those folks who have been using Ant's APIs? build.xml migration may be done (?) with XSL translation, but what about the custom tasks that are coded with Ant's API? By moving deprecated stuff into a separate jar, what do we really achieve? It is just one level closer to extinction, but it is still there, right? So, why bother splitting it up into 2 jars? What if we just say bold and clear that deprecated tasks/APIs will not be *supported*? i.e., if any enhancement requests, etc. are made on those, we don't do anything - same as shelving it, without having to maintain 2 jars. Didn't we heave a sigh when optional.jar merged with the main jar? > The size of the jars are not really an issue I wouldn'y think. I would be > very surprised if they got close to 100k. So I would include it by default > and allow people to nuke em if they saw fit. Very few would actually bother to get rid of it. How many times do users who download applications bother to study which files are useful and which aren't? Raise your hands, those of you, who confidently delete unused dlls when uninstalling windows applications ;-) What I am trying to say is that users wouldn't have enough confidence to nuke the extra jar - they would rather leave an additional 100k in there. Magesh -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
