[WICKET7] Old Tree/TreeTable removal

[Martijn Dashorst <ma...@gmail.com>]

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

Re: [WICKET7] Old Tree/TreeTable removal

[Martijn Dashorst <ma...@gmail.com>]

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 <sv...@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
>>> <em...@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

Re: [WICKET7] Old Tree/TreeTable removal

[Sven Meier <sv...@meiers.net>]

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

Re: [WICKET7] Old Tree/TreeTable removal

[Emond Papegaaij <em...@topicus.nl>]

On Wednesday 04 March 2015 09:23:06 Martin Grigorov wrote:
> On Wed, Mar 4, 2015 at 9:13 AM, Emond Papegaaij <em...@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

Re: [WICKET7] Old Tree/TreeTable removal

[Martin Grigorov <mg...@apache.org>]

On Wed, Mar 4, 2015 at 9:13 AM, Emond Papegaaij <em...@topicus.nl>
wrote:

> On Tuesday 03 March 2015 21:23:37 Martin Grigorov wrote:
> > On Tue, Mar 3, 2015 at 9:11 PM, Emond Papegaaij <
> emond.papegaaij@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? :)
>

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.



>
> Best regards,
> Emond
>
>

Re: [WICKET7] Old Tree/TreeTable removal

[Emond Papegaaij <em...@topicus.nl>]

On Tuesday 03 March 2015 21:23:37 Martin Grigorov wrote:
> On Tue, Mar 3, 2015 at 9:11 PM, Emond Papegaaij <em...@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

Re: [WICKET7] Old Tree/TreeTable removal

[Martin Grigorov <mg...@apache.org>]

On Tue, Mar 3, 2015 at 9:11 PM, Emond Papegaaij <em...@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.dashorst@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
> >
>

Re: [WICKET7] Old Tree/TreeTable removal

[Emond Papegaaij <em...@topicus.nl>]

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

Re: [WICKET7] Old Tree/TreeTable removal

[Maxim Solodovnik <so...@gmail.com>]

+1

WBR, Maxim
(from mobile, sorry for the typos)
On Mar 3, 2015 11:28 PM, "Martin Grigorov" <mg...@apache.org> wrote:

> I'm +1 to move it to WicketStuff!
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Tue, Mar 3, 2015 at 7:22 PM, Martijn Dashorst <
> martijn.dashorst@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
> >
>

Re: [WICKET7] Old Tree/TreeTable removal

[Martin Grigorov <mg...@apache.org>]

I'm +1 to move it to WicketStuff!

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Tue, Mar 3, 2015 at 7:22 PM, Martijn Dashorst <martijn.dashorst@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
>