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.
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...


>
> 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
> >
>

Reply via email to