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

[Rod J. <rod...@in...>]

Much as I love Eclipse, I think it's important that our build/commit process
is purely handled by Ant. I don't like forcing people to use a particular
IDE (or _any_ IDE, for that matter).

Also, Juergen Hoeller is one active contributor who's not using Eclipse.
(IDEA).

----- Original Message -----
From: "Tony Falabella" <ton...@ya...>
To: "William G. Thompson, Jr." <wg...@rc...>
Cc: <spr...@li...>
Sent: Monday, March 03, 2003 4:33 PM
Subject: Re: [Springframework-developer] Code format tools Part II


>
> I see your point now.  Actually it is not enough for us to set up the
format template to just perform indentation, we will have to have it sort
methods/attributes at least by name, and by modifier (according to
recommendation in the book).
> This should then accomplish what we need.
> I can't comment on whether or not Eclipse settings would also do the same
thing, but I don't think we should require all developers to use Eclipse
(and if everyone does do the same thing consistently there's no point in
doing any of this).
> If our format template includes sorting, do you concur that it should
address our needs?
>
>  "William G. Thompson, Jr." <wg...@rc...> wrote: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." /* 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
> > >
> >
>
>