+1, go for it. Now its time to see if our testcases are good. I also think we should test it in conjunction with struts.
On Tue, Mar 26, 2013 at 9:31 AM, Lukasz Lenart <lukaszlen...@apache.org> wrote: > Ok, done. Should I just commit the changes? Or do I have to register > an issue first in JIRA? Maybe it will be better... > > > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > > 2013/3/26 Lukasz Lenart <lukaszlen...@apache.org>: >> I'm not sure what API should be removed/renamed/etc as almost >> everything is public static ;-) >> >> Anyway, I'm trying to remove two deprecated classes right now. >> >> >> Regards >> -- >> Łukasz >> + 48 606 323 122 http://www.lenart.org.pl/ >> >> 2013/3/8 Christian Grobmeier <grobme...@gmail.com>: >>> On Wed, Mar 6, 2013 at 10:11 AM, sebb <seb...@gmail.com> wrote: >>>> On 6 March 2013 06:49, Lukasz Lenart <lukaszlen...@apache.org> wrote: >>>>> Hi, >>>>> >>>>> I was checking out what should be solved before releasing a new >>>>> version and in my opinion most of PMD [1] errors can be omitted, maybe >>>>> "These nested if statements could be combined" should be resolved, but >>>>> the rest I don't see a point instead of just satisfying PMD itself. >>>>> >>>>> Some of the Findbugs [2] errors are related to generated classes, >>>>> should I exclude them? >>>>> >>>>> Another thing is Checkstyle [3], especially "Missing a Javadoc >>>>> comment." - I don't know what to put as it without analysing source >>>>> code deeply. >>>>> >>>>> My question is what really should be solved to be ready to release a >>>>> new version? >>>> >>>> I don't personally worry too much about PMD or Checkstyle; they depend >>>> so much on the rules chosen. >>> >>> Guess we need to decide on a few rules here. If they are somehow >>> connected to method naming et al we should look at them more closely >>> >>> >>>> Findbugs is more useful, but it looks like most of the errors are for >>>> generated code. >>>> >>>> Bugs can be fixed by a new release, but future binary compatibility >>>> can easily be compromised. >>>> >>>> Once a bad or broken API is released, it's very difficult to fix it. >>>> >>>> So I would say the most important aspect to get right is to fix >>>> anything that makes it more difficult to maintain binary compatibility >>>> in future. >>>> >>>> For example, if one of the new methods has a name that is >>>> non-standard, it is easy to change it now. >>>> Likewise, if there is a new public method which should be private or >>>> package protected, do it now. >>>> >>>> Or new non-private mutable variables - they make thread-safety - and >>>> testing - much more difficult >>> >>> +1 >>> We should look over all of our methods right now and discuss >>> everything which is public. >>> >>>> Speaking of which, there does not seem to be a Clirr report. >>> >>> I have added the clirr report plugin right now. I doesn't report for >>> the first build, as it cannot compare to anything. >>> I am bit confused since there is basically no configuration necessary, >>> just the plugin definition - is it correct? >>> >>>> That's very important. >>>> Apart from checking for unintended compatibility issues, it is useful >>>> in ensuring that new classes and methods etc. are annotated with >>>> @since markers. >>> >>> We have moved OGNL to 4.0 and Apache - should we annotate everything >>> with since 4.0.0 then? >>> Imho it doesn't make much sense to annotate with 3.x, as the package >>> has changed and both releases are not fully interchangeable >>> >>> Cheers >>> >>> >>>> >>>>> [1] http://commons.apache.org/proper/commons-ognl/pmd.html >>>>> [2] http://commons.apache.org/proper/commons-ognl/findbugs.html >>>>> [3] http://commons.apache.org/proper/commons-ognl/checkstyle.html >>>>> >>>>> >>>>> Regards >>>>> -- >>>>> Łukasz >>>>> + 48 606 323 122 http://www.lenart.org.pl/ >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> >>> >>> -- >>> http://www.grobmeier.de >>> https://www.timeandbill.de >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- http://www.grobmeier.de https://www.timeandbill.de --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
