commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: [vfs] checkstyle - was Re: svn commit: r1245166 - in /commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs2: provider/ provider/http/ provider/https/ provider/ram/ provider/sftp/ provider/tar/ util/
Date Sat, 18 Feb 2012 14:12:20 GMT
On Feb 18, 2012, at 6:19, Luc Maisonobe <> wrote:

> Le 17/02/2012 23:30, Ralph Goers a écrit :
>> On Feb 17, 2012, at 2:18 PM, Gary Gregory wrote:
>>> On Fri, Feb 17, 2012 at 5:05 PM, Ralph Goers <>wrote:
>>>> On Feb 17, 2012, at 1:17 PM, Gary Gregory wrote:
>>>>> On Fri, Feb 17, 2012 at 4:12 PM, Ralph Goers <
>>>>> wrote:
>>>>>> Really?  I've gotten so used to putting the '{' at the end of the
>>>>>> that I assumed VFS was that way.
>>>>> I'm happy to change the style to what we both seem to consider normal
>>>> but I
>>>>> am not sure what the rest of the community feels like...
>>>> That seems like way too much effort for very little benefit.  In fact,
>>>> when I created the checkstyle configuration I started from the one used by
>>>> Commons Configuration and then tweaked it to shut up a bunch of the
>>>> "errors" I didn't care about and that seemed to have been the convention
>>>> the existing code base.  I'd prefer that all of commons use the same
>>>> checkstyle configuration.
>>> +1, that would be great, we could put it in the parent POM and be done with
>>> it once and for all.
> Are we sure all components use the same style ?
> The checkstyle.xml file for [math] origin has evolved its own way,
> partly when the mantissa library has been merged. I am pretty sure it is
> not compatible with other ones.
> Luc
>>> Can you have a checkstyle.xml reused that way?
>> Not easily.  If you look at how the checkstyle.xml is used in VFS you will see it
is a bit of a hack. The plugin has
>> <configLocation>${vfs.parent.dir}/checkstyle.xml</configLocation>
>> In the parent the variable is defined as "." and in each module it is defined as
needed to get it to the root.  If it is in commons parent it would have to be somewhere on
the disk that it could be located.
>> the other way to do it is the way it is documented at
and requires a separate project just for checkstyle. I've always hated this solution but for
a project like commons it probably makes the most sense.

Well, that's part of the overall parent issue.

I work on several commons project and it's a pain and ugly -- to me --
to deal with arbitrary differences in style, reports and so on. The
differences make common feel less, well, common.

For example I'd like to see cobertura, checkstyle, pmd and findbugs in
all reports, so it makes sense to use the parent POM for that. Then,
if a component has a need to do something different, it can override
the parent POM. But it would need a good reason for that. If a new
component is started, it gets all this for free. Especially for the


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

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

View raw message