Re: [Springframework-developer] Code format tools Part II

[William G. T. Jr. <wg...@rc...>]

Tony Falabella wrote:
> Bill,
> 
> I believe the main point of the exercise is to easily see diffs in 
> changes in the repos.  As such, I believe issue #2 has to be ruled out 
> (please read on). 

The issues with diffs is exactly why #2 is important.  In other words, 
unless the the automated mechanism can be garunteed to only munge code 
changed by a developer, diffs will get corrupted.  I have not used 
Jalopy, so I can not comment on its consistency.

The diff problem is easily solved if #2 is our mode of operation.  The 
goodliness of the code formating can be solved simply with the correct 
eclipse settings.  This does not rule out the one-time reformating of 
the code base.

Bill

> My thoughts are I will check out ALL code the first time, run it through 
> the formatter with an agreed upon template and check it back in 
> (comments for checkin will be something like "reformatted to group 
> standard format"). 
> 
> After that, the requirement on developers will simply be to make sure 
> you run the Ant build/tests RIGHT BEFORE checking in your code (a 
> procedure all should be following anyway).  This will ensure it is in 
> the format that the group agreed upon when you perform your checkin (FYI 
> - only classes you have as writable will be effected).
> 
> There is no mandate that any developer use the beautifier themselves.  
> If you so choose to use a beautifier yourself, you can pick any 
> beautifier you'd like, and create any format you like.  Your changes 
> will not be seen by the group though since the Ant script will reformat 
> the code to the group's agreed upon format prior to you checking that 
> code in.
> 
> In case you wish to use Jalopy yourself within an IDE I will tell the 
> group where the format file is located (and this is specific to 
> Jalopy).  You will then just need to point Jalopy to this file.
> 
>  
> 
> */"William G. Thompson, Jr." <wg...@rc...>/* wrote:
> 
>     William G. Thompson, Jr. wrote:
>      > Tony Falabella wrote:
>      >
>      >> BTW - I've tried to put hooks into CVS to have it run a program
>     (using
>      >> a filter like *.java) prior to commits to it. While the hook
>     appears
>      >> to be there (and you'll see mention of being able to do this in the
>      >> documentation for CVS), the code within CVS has actually been
>      >> commented out. What will happen is you'll get an error like
>      >> "Unimplemented in this version of CVS, consult the reference guide."
>      >> Apparently they added this functionality to CVS, found it was too
>      >> buggy for some platforms/files/etc. so rather than take it out they
>      >> just now return that msg above. Someone has a workaround for it,
>     but
>      >> it doesn't seem recommended. Thus my ANT suggestion.
>      >>
>      >
>      > Folks,
>      >
>      > some suggestions:
>      > 1 agree on source formating and post the eclipse settings
>      > 2) agree to _not_ reformat other ppls code just for the sake of
>      > reformatting
>      > 3) let social mechanisms or our benefical dictator take care of
>     source
>      > formating issues
>     I really mean let social mechanisms or our beneficial dictator take
>     care
>     of enforcement. (as opposed to some software imposed mechanism that
>     will
>     complicate the process)
> 
>      > 4) keep it simple ;)
>      >
>      > Cheers,
>      > Bill
>      >
>