I wonder how much work we could make Eclipse do for us. Under the 'Refactor' menu there are a few useful optional to record / playback refactorings:
Migrate JAR File Migrates a JAR File on the build path of a project in your workspace to a newer version, possibly using refactoring information stored in the new JAR File to avoid breaking changes. Available: JAR Files on build path Create Script Creates a script of the refactorings that have been applied in the workspace. Refactoring scripts can either be saved to a file or copied to the clipboard. See *Apply Script*. Available: Always Apply Script Applies a refactoring script to projects in your workspace. Refactoring scripts can either be loaded from a file or from the clipboard. See *Create Script*. Available: Always History Browses the workspace refactoring history and offers the option to delete refactorings from the refactoring history. Available: Always What if you recorded all the refactorings you wanted to make and then let developers simply replay them on their own projects? In fact, the Eclipse plugin could potentially prompt to auto upgrade projects to the new API. Fred On Mon, Aug 3, 2009 at 7:10 AM, Joel Webber <j...@google.com> wrote: > I'd be a lot more comfortable if our own code didn't have reams of > deprecation warnings. The good news is that it's actually pretty easy to do > -- it's damned near rote, though not quite enough to automate. I did it for > a few large classes in 1.5 (though I didn't commit the changes), just to > make sure I didn't miss anything too important. > > > On Mon, Aug 3, 2009 at 10:06 AM, John Tamplin <j...@google.com> wrote: > >> On Mon, Aug 3, 2009 at 8:30 AM, Joel Webber <j...@google.com> wrote: >> >>> I've been wanting to do this since we first introduced the dom package in >>> 1.5. The plan is to remove all extant references to user.Element and >>> friends, as well as the DOM.* static methods, at which point they can be >>> deprecated. I'd like to do this as part of 2.0, so that we can go ahead and >>> get them deprecated, but it remains to be seen if there's enough time in the >>> schedule. >>> >> >> Do we have to remove internal references to it before marking it >> deprecated? Obviously, those would have to be cleaned up before we actually >> remove it, but it doesn't seem necessary to require it earlier. >> >> -- >> John A. Tamplin >> Software Engineer (GWT), Google >> >> >> >> > > > > -- Fred Sauer Developer Advocate Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 fre...@google.com --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
