I wonder why there is such a strong opinion on removing or trashing these components.
They are old and so forth, but they have value. Keeping them in wicket stuff in a keep it compiling mode, accepting the odd bug fix is perfectly fine for these components. They have been around for a long time, have few if no discernible bugs in them and frankly, they have been in this state for a major release or 3. There is no need to warn users about the state these components are in: they have been in this state for ages. The last commits to any of the files was 3 or 4 years ago [1]. There really is no need to remove any quality control that exists like the one unit test [2]. Why would we? Keep the value. When the test starts failing, we can decide to fix it or to disable the project. Until then, why remove it? Martijn [1] https://github.com/apache/wicket/tree/wicket-6.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/markup/html/tree [2] https://github.com/apache/wicket/tree/wicket-6.x/wicket-extensions/src/test/java/org/apache/wicket/extensions/markup/html/tree On Wed, Mar 4, 2015 at 10:10 AM, Sven Meier <s...@meiers.net> wrote: > Hi, > > I agree with Edmond: We could move the code to a new "attic" module in > wicket-stuff. > > Have fun > Sven > > Am 04.03.2015 um 08:38 schrieb Emond Papegaaij: > >> On Wednesday 04 March 2015 09:23:06 Martin Grigorov wrote: >>> >>> On Wed, Mar 4, 2015 at 9:13 AM, Emond Papegaaij >>> <emond.papega...@topicus.nl> >>>>> >>>>> WicketStuff InMethodGrid is currently excluded from the build in 7.x >>>>> because it uses the old Tree and for 2 years no one spend his time to >>>>> fix >>>>> the deprecation warnings and migrate it to the new Tree impl... >>>> >>>> So are we going to re-introduce it now the code stays available? :) >>> >>> Yes. InMethod Grid is used by many applications. Most of its users >>> probably >>> do not even know it uses deprecated APIs. >>> >>> One way is to leave it disabled and force the community to migrate it. >>> Another way is to copy the old Tree classes in InMethod Grid project and >>> use them locally. >>> The third way is to introduce a project for the old Tree, with deprecated >>> classes and documentation explaining that it is not maintained. >>> >> I'd go for the third option then. Put all deprecated code in a separate >> project (or module), disable things like tests and code analysis, mark all >> classes as deprecated and leave them there to rot away. This keeps the >> work >> required to a minimum while still keeping the classes available for as >> long as >> possible. >> >> Best regards, >> Emond > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com
