The reason I prefer to remove code that is no longer recommended is maintenance. If the recommendation is to use the new approach (the plugin, in this case), then we should remove examples from the demo and tutorial projects that use the old approach so there is no confusion. We then end up with code that is no longer called by the platform or examples and stops getting tested.
In this case, leaving the code as-is is not a big deal because it is fairly trivial. However, my feeling in general is that there's not much value in preserving unrecommended APIs, especially across a major version change. G On Jul 30, 2010, at 12:31 AM, Chris Bartlett wrote: > The introduction of this method came before I discovered Pivot so I can't > comment on use cases, but seeing as it works I would prefer not to remove it > unless doing so provides a benefit such reducing complexity within the code > base. > > Updated Pivot & javadocs can point users to whatever preferred/recommended > launch methods exist and allow them to choose, but removing it seems a > little fastidious IMHO. > > Chris > > On Fri, Jul 30, 2010 at 7:19 AM, Greg Brown <[email protected]> wrote: > >> Hi all, >> >> Given that we now have a plugin that makes it easy to launch Pivot >> applications within Eclipse via a context menu, I'm wondering if we still >> need the DesktopApplicationContext.main(Class<? extends Application>, >> String[]) method. As I recall, the primary reason this method was created >> was to support this use case. It was a great suggestion (care of Noel) and >> it has worked quite well - I'm just wondering if it is worth preserving in >> Pivot 2.0. >> >> Let me know what you think. >> >> Greg >> >>
