I don't like keeping code around just for the sake of keeping it around. Even unmaintained code takes time to maintain. For example, the code needs to be updated for Wicket 7 to keep it compiling, this will happen again with Wicket 8 etc. It might also need changes to migrate to newer servlet api's, Java versions, etc. What will happen with deprecation warnings that are introduced when dependencies get updated? All this takes time we could also spend on other things.
I don't want to block this, so I'll keep my vote to -0. Best regards, Emond On Tue, Mar 3, 2015 at 6:22 PM, Martijn Dashorst <martijn.dasho...@gmail.com > wrote: > With Wicket 7 we cleaned up some old code, most notably the Swing > based Tree and TreeTable. While that is an excellent idea, most pages > that are based on these components are rather expensive to rewrite > using the newer non-Swing based Tree components. > > Is it an idea to move the old deprecated code from extensions to > WicketStuff and keep it compiling over there? If issues are reported > against it, we don't fix, unless someone provides a PR with the fix... > > We (my company) can of course pull the code internal and maintain it > until we can scrap the pages using these components, but if other > community members are in the same boat, why not keep them around in > Wicket Stuff, in a well maintained grave, i.e. keeping them compiling? > > Is moving our old friends to Wicket Stuff an idea that rings a bell? > Or is that bell an alarm bell and should I just move the code > internally? > > Martijn >
