Community
Participate
Working Groups
Build Identifier: Version: 3.6.2 Build id: M20110210-1200 My project uses copyright notices like: © Copyright 2001, 2007-2009, 2011 CompanyName. All rights reserved. or © Copyright 2007-2009, 2011 CompanyName. All rights reserved. Note all the years we've touched the file are listed. Hyphens separate sequential years in a range and all ranges are separated by a comma. The "Fix Copyrights" tool (properly configured to match the template, using ${date} in place of the full date range) replaces these with: © Copyright 2001, 2012-2009, 2011 CompanyName. All rights reserved. © Copyright 2007, 2012, 2011 CompanyName. All rights reserved. Instead, it should be: © Copyright 2001, 2007-2009, 2011-2012 CompanyName. All rights reserved. © Copyright 2007-2009, 2011-2012 CompanyName. All rights reserved. I'd be ok with just comma-separated years (2001, 2002, 2003 rather than 2001-2003) as long as the tool could smartly append to the list instead of always using the 2nd position. Reproducible: Always Steps to Reproduce: 1. Configuration: Fix Copyrights template: © Copyright ${date} CompanyName. All rights reserved. Options: Default creation year: 2012 Default revision year: 2012 All options are unchecked: "Always use default revision year instead of repository lookup" "Replace all existing copyright comments with this copyright template" "Skip over properties files" "Skip over XML files" 2. Right-click project or file with copyrights in format listed in "Details" section. 3. Choose "Fix Copyrights"
Just FYI, it may depend on jurisdiction but this is overkill. In most countries copyright lasts at least 50 years (95 in USA), so you would only really need more than two dates if you wanted to cover a very long period of time (e.g., Copyright 2008, 2058, 2108). Anyway you're welcome to write whatever you want and to request that the copyright tool support it... http://en.wikipedia.org/wiki/List_of_countries%27_copyright_length
So basically it always selects the *2nd* date element instead of the last one. This has been bugging me also as we have a lot of headers with more than one date. I'll work on fixing this.
I rewrote the parse method and large chuncks of the class in AdvancedCopyrightComment to handle multiple revision years. In addition I wrote a lot of test cases to make sure that parsing works well across many different scenarios: AdvancedCopyrightCommentTestsJunit4.java I tested quite extensively with Java/Xml... files. It functions as before but handles multiple years in a copyright notice. Please review: https://git.eclipse.org/r/#/c/30385/ Please let me know if I can improve multi-year functionality further.
I know it's confusing to make some comment in Gerrit, and some here in Bugzilla, bug Gerrit is beginning to confuse me, so I'll leave a few concluding comments here, then you me or others can open new bugs if there are remaining issues. On printing IFile vs. not, since "full path" is printed else where ... agreed I did not know the context, so probably suffices for all practical purposes. But, will add, doesn't hurt to be a little redundant. For example, perhaps full path would show certain "NLS characters" or spaces, but the IFile name would not -- hence providing a pretty good sign of what the bug was. But, not worth holding up accepting what you have. I'll leave to your discretion if requires further testing at this point. (But, do plan to "accept" into master soon, so a new bug should be used for those issues, if any). As for returning null vs returning zero in error condition; null (meaning "undefined") is definitely better than 0 (where an integer is expected anyway) [my license plate says null!=0 :) ] as long as it's well documented (which is what I mean by gerrit confuses me ... I can't even find it easily :( As for ensure the case of non numeric input failing gracefully -- please open a few bug after you test that, if more work is needed there. (I think Gerrit is better for small changes ... not to mention I need to better learn how to work with it. Thanks for the contribution. Take all my comments with a grain of salt ... as you've seen, some might be helpful, but I'm looking at things in isolation and am no expert in how "fix copyrights" was designed.
Thanks Leo, big improvement so far ... if other fringe cases end up needing attention, please open new bugs for those.
I see what you mean. I was also thinking of the 0 v null business. Perhaps I should work with Integer objects rather than int primitives to get the null functionality. p.s I like your license plate.
I've lost track of where this is, but the last Gerrit contribution was committed, so believe we are done? If not, please clone and have a "continuation" bug. Thanks,
Yes this is done. Thank you for closing. I'm now working on the performance issue.
