commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Grobmeier <>
Subject Re: [OGNL] A new release
Date Fri, 08 Mar 2013 07:52:04 GMT
On Wed, Mar 6, 2013 at 10:11 AM, sebb <> wrote:
> On 6 March 2013 06:49, Lukasz Lenart <> 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

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


>> [1]
>> [2]
>> [3]
>> Regards
>> --
>> Ɓukasz
>> + 48 606 323 122
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message