Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] Unification of line endings in the codebase
After formatting sweep it would be impossible (well, much harder than before) to follow revision history for real changes.
Also formatting rules are hard to enforce, especially after the initial enthusiasm is gone ...
On 3/26/2015 9:09 AM, Rick Curtis wrote:
> such as replace tabs for spaces (many files still use tabs), or even apply single formatting rules to all files (many files have broken formatting, non-consistent formatting is used across the codebase), so that we could potentialy integrate checkstyle to make sure we keep the status going forward. Updating to 2015 would be fine, too.

+1

I'd like to see checkstyle run every time we build. It's sometimes a pain, but the best way to ensure that crud doesn't creep into our code base.

On Thu, Mar 26, 2015 at 7:59 AM, Lukas Jungmann <lukas.jungmann@xxxxxxxxxx> wrote:
On 3/25/15 9:26 AM, Martin Grebac wrote:
The main purpose of this is to make reviews easier and code easier to work with, so even though line endings solution would help tremendously if we're doing the mass update I'd be voting for broadening the scope to also apply other formatting - such as replace tabs for spaces (many files still use tabs),

 ok, replacing tabs for spaces together with trimming leading whitespaces can be done

or even apply single formatting rules to all files (many files have broken formatting, non-consistent formatting is used across the codebase), so that we could potentialy integrate checkstyle to make sure we keep the status going forward.

 I haven't found simple way to convert existing eclipse rules, pointed out by Gordon, into checkstyle ones. Not sure how complicated that would be. OTOH there does not seem to be simple way how we could enforce those rules to be followed other then providing client side git pre-commit hook, ie by adopting sth like https://gist.github.com/davetron5000/37350, which would have to be set up manually by each developer on his local machine

Updating to 2015 would be fine, too.

 ok, will do this as well.

thanks,
--lukas



Opinions?

 MartiNG 

On 19.03.15 10:21, Lukas Jungmann wrote:
On 3/18/15 3:40 PM, David Minsky wrote:
+LF

Also consider: any plans to change the date in the copyright headers to 2015 at the same time, since a mass update is being planned for that specific day?

I'm not big fan of these mass updates just because of year has changed, I think it is better to update what actually changed only. But since I'll be touching a lot of files, it perhaps make sense to update the year as well... will think about this

thanks,
--lukas


On 18/03/2015 4:48 AM, Lukas Jungmann wrote:
Hi all,

   currently eclipselink sources contains mix of line endings - some files are using *nix style (LF), some win style (CRLF) and the rest is a mix of *nix and win style (some lines end with LF while others with CRLF). Since we are at the beginning of 2.7 development it looks like a good time to me to unify line endings in our codebase to avoid complete rewrites of files in the future.

Why we should do that?
-make it easier to review incoming as well as own (outgoing) changes
-avoid noise in git log
-use https://help.github.com/articles/dealing-with-line-endings as a guide to properly set up local development environment

Drawbacks:
-one-time full rewrite of some files in the repository
-some backports to previous streams will require manual changes/merges

When?
  if there will be an agreement, I'd like to perform the change next week, on Friday March 27, 2015

Which line endings should be used?
  either *nix or win but definitely not a mix of them in one file

How to cast your vote?
  simply reply to this email with either '+LF', '+CRLF' or 'Leave it as it is' by Thursday March 28, 23:59.

Thanks and happy voting,
--lukas
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev


--
Oracle
David Minsky | Principal Member of Technical Staff | +1 613-288-4605
Oracle Sustaining Engineering | Application Server
45 O'Connor Street, Suite 400, Ottawa, Ontario, Canada, K1P 1A4 


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev



_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

-- 
Martin Grebac, SW Engineering Manager
Oracle Czech, Prague



_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev



--
Rick Curtis


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

Back to the top