On Tuesday 03 March 2015 21:23:37 Martin Grigorov wrote: > On Tue, Mar 3, 2015 at 9:11 PM, Emond Papegaaij <emond.papega...@topicus.nl> > wrote: > > 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. > > What you say is correct but it will be even more work if everyone has to > either migrate his/her *working* code to the new Tree impl or to copy the > classes from 6.x and maintain them locally.
That's always the trade off you have to make. At our company, we have used a special deprecated code module in the past. This module contained code that was working fine, but you were no longer suppose to use. This worked quite well for us. > 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? :) Best regards, Emond
