Community
Participate
Working Groups
The eclipse copyright tool creates comments that have a line length of 81. For example, when I 'Fix Copyrights' the plugin 'Checkstyle' complains that the line length is greater than 80 characters. The following is a sample comment. /******************************************************************************* * Copyright (c) 2013 NAME. * All rights reserved. This program and the accompanying materials * are made available under the terms of the GNU Public License * v3.0 which accompanies this distribution, and is available at * http://www.gnu.org/licenses/gpl.html * * Contributors: * NAME - initial API and implementation *******************************************************************************/ A possible solution is to remove an asterisk from the first and last line.
Found this bug in "tools-pmc" in-box. Was opened relatively recently, so I assume still relevant. Now ... who's in charge of the releng copyright tool? :)
http://dev.eclipse.org/viewsvn/viewvc.cgi/org.eclipse.releng.tools/src/org/eclipse/releng/tools/CopyrightComment.java?revision=1.7&view=markup This file may contain the bug, on line 86 there is an extra space at the beginning. Also one astericks could be removed here to solve the issue with the Checkstyle plugin.
(In reply to Fred Laderoute from comment #2) > http://dev.eclipse.org/viewsvn/viewvc.cgi/org.eclipse.releng.tools/src/org/ > eclipse/releng/tools/CopyrightComment.java?revision=1.7&view=markup > > This file may contain the bug, on line 86 there is an extra space at the > beginning. Also one astericks could be removed here to solve the issue with > the Checkstyle plugin. The white space is intentional, on that line (which you can see in your example copyright, in comment 0. Now, about the "80 characters" limit. I've checked the source, currently in Git, at http://git.eclipse.org/c/platform/eclipse.platform.releng.git/tree/bundles/org.eclipse.releng.tools/src/org/eclipse/releng/tools/CopyrightComment.java and counted the characters carefully ... well, not really, I used Java scrape book page to 'display' String comment="/*******************************************************************************"; comment.length(); (int) 80 And as you can see, the comment actually is 80 characters long. So ... this makes me wonder if "check style" is including the "line ending" (EOL) in its count. Do you know? Do you know if it matters? Or if it is "configurable". And, I've no idea of "right or wrong" way to count characters for this purpose, but I ask since if we needed to account for "line endings" then chances are "78" is the right "max width" to shoot for, to allow for Windows CRLF ... (and, this is one case, we would not want to make depend on "the line ending currently in use" since then projects that used a mix of OSes would sometimes have "79" (which would mess up "check style" ran on someone's Windows box, etc. That is, in this case we want "one length" of visible characters, no matter what the line ending was.
Adding Dani as he was the last to "touch" this code ... granted, 2 years ago :) But, I think you do use it Dani ... and wanted to ask in your experience, would changing comment line lengths only have an effect if "copyright changed" for other reasons ... or, would it be "seen" as a change? Otherwise, I fear that people using it on established code would have hundreds of "changes" just due to a few asterisks ... and they may not care about "check style". I know that there is a "template" people can define. If there is danger of "erroneous changes", perhaps comments could be made part of template, and then they could use what ever length they wanted? Or perhaps a preference on copyright tool to "use 78 characters" (which would be "off" be default so no change in behavior for those that don't care, where as those that do, can set the flag, even if it re-writes hundreds of their files?
Created attachment 240523 [details] patch to use 78 characters max. Here's a patch to make "maximum" comment line 78 characters. I suspect that's the only (easy) solution to address the "check style" issue, ... and that depends on it not changing existing copyright's, unless there is a reason to (which, from quick glance at the code would seem to be the cases.).
(In reply to David Williams from comment #4) > Adding Dani as he was the last to "touch" this code ... granted, 2 years ago > :) Yeah, I know a few things about it :-) > But, I think you do use it Dani ... and wanted to ask in your experience, > would changing comment line lengths only have an effect if "copyright > changed" for other reasons ... or, would it be "seen" as a change? There's an option to always use the template. This would result in massive changes if we simply change the first and last comment line in the code. I like the idea to move the first and last line of the comment into the template. But we need to make sure not to break existing templates stored in a workspace. And me must add a note, that the first and last line will be replaced with the comment style of the file type. Plus, the template preference should use the editor font (usually a monospaced font).
Doing a mass "reset to default assignee" of 52 bugs to help make clear it will (very likely) not be me working on things I had previously planned to work on. I hope this will help prevent the bugs from "getting lost" in other people's queries. Feel free to "take" a bug if appropriate.
