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

[Tony F. <ton...@ya...>]

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).  
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
>