I've removed 'final' and the build is OK now here. I won't be able to work on this more tonight. If you find better solution feel free to apply it!
Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, Sep 27, 2016 at 4:26 PM, Tobias Soloschenko < [email protected]> wrote: > Hi, > > if the final modifier is the only reason why clirr breaks I would also > suggest to remove it from the methods. > > There are also methods in Component that tell users only to use them and > not to override. > > kind regards > > Tobias > > > Am 27.09.2016 um 16:07 schrieb Emond Papegaaij < > [email protected]>: > > > > Well, I'm not a big fan of final myself, but I see no reason to change > the > > behavior of those methods so I made them final. They were private > before, but > > that made it impossible to reuse them from a subclass. In the case of > this > > class, a user can copy-paste the entire class and circumvent the final > > methods, so there's no absolute necessity for them to be final. It does > > however indicate to the user which methods are meant to be overridden, > and > > which are not. > > > > If you feel that removing the final modifier is the easiest fix for the > bug in > > clirr, feel free to change the class (don't forget wicket 8). > > > > Best regards, > > Emond > > > >> On dinsdag 27 september 2016 15:24:01 CEST Martin Grigorov wrote: > >> We can argue whole day... > >> There is no perfect software... > >> > >> Is there a good reason to use "protected final" ? > >> Google "Wicket final modifier" and you will see a lot of complains by > users. > >> I know that methods and classes should be final sometimes. Please > convince > >> us this is one of those cases. > >> > >> Martin Grigorov > >> Wicket Training and Consulting > >> https://twitter.com/mtgrigorov > >> > >> On Tue, Sep 27, 2016 at 3:18 PM, Emond Papegaaij < > [email protected] > >>> wrote: > >>> > >>> No, adding new methods is also allowed (public or protected). If > adding a > >>> new > >>> final method is considered an API break, adding a new non-final method > >>> must be > >>> considred an API break as well. Suppose you have the following method > in a > >>> subclass: > >>> > >>> protected String myMethod() {} > >>> > >>> And I add the following non-final method to a superclass: > >>> > >>> public Integer myMethod() {} > >>> > >>> This breaks twice. > >>> > >>> Best regards, > >>> Emond > >>> > >>>> On dinsdag 27 september 2016 14:59:40 CEST Martin Grigorov wrote: > >>>> Hi Emond, > >>>> > >>>> It is considered as API break because a sub-class may already have > this > >>>> method and 'final' would break it. > >>>> Is it OK to remove the 'final's ? > >>>> > >>>> Martin Grigorov > >>>> Wicket Training and Consulting > >>>> https://twitter.com/mtgrigorov > >>>> > >>>> On Tue, Sep 27, 2016 at 2:51 PM, Emond Papegaaij < > >>> > >>> [email protected] > >>> > >>>>> wrote: > >>>>> > >>>>>> On dinsdag 27 september 2016 14:17:37 CEST Martin Grigorov wrote: > >>>>>> Fixed! > >>>>>> > >>>>>> It seems the backport from 8.x (master) broke it. > >>>>>> The generics are fine with JDK 8. > >>>>>> > >>>>>> But now there is broken Clirr because of Csrf request cycle listener > >>>>> > >>>>> This is a bug in Clirr, which I think I fixed. A private methode has > >>>>> become > >>>>> protected final, this is NOT an API change. I tried adding it to the > >>>>> whitelist. I do not have the time to look at this at the moment, > >>> > >>> perhaps > >>> > >>>>> someone else can have a look? > >>>>> > >>>>> Best regards, > >>>>> Emond > >>>>> > >>>>>> Martin Grigorov > >>>>>> Wicket Training and Consulting > >>>>>> https://twitter.com/mtgrigorov > >>>>>> > >>>>>> On Tue, Sep 27, 2016 at 2:07 PM, Martijn Dashorst < > >>>>>> > >>>>>> [email protected]> wrote: > >>>>>>> In ApplicationSettings this fails. Both in Eclipse and maven. > >>>>>>> > >>>>>>> Martijn > >>>>>>> > >>>>>>> -- > >>> > >>>>>>> Become a Wicket expert, learn from the best: > >>> http://wicketinaction.com > > > > >
