dev@glassfish.java.net

Re: pom change review request (long but simple)

From: Ken Cavanaugh <Ken.Cavanaugh_at_Sun.COM>
Date: Thu, 17 Sep 2009 16:58:22 -0700

Bill Shannon wrote:
> Ken Cavanaugh wrote:
>> Bill Shannon wrote:
>>> The copyright situation is a mess. I've complained about this to
>>> Abhijit several times, still no action.
>>>
>>> *Many* files have completely the wrong license, or worse yet no
>>> copyright
>>> or license at all.
>>>
>>> No one seems to update the copyright year when they modify a file,
>>> like they should.
>>>
>> And I think we all know that no one ever will, at least not
>> consistently.
>> But this sort of problem is very amenable to a tools solution.
>>
>> I already have a copyright header checking/updating tool that I use
>> in CORBA. A variant of the same tool is also used in Metro, and is
>> available as the license-tool project on java.net. The tool runs
>> quickly:
>> on my current machine (3 Core AMD/2.8 GHz/8 GB RAM) it processes
>> around 1000 files/second.
>>
>> It should be fairly easy in most revision control systems to extract the
>> year in which a file was last updated. For example, in mercurial using
>> CORBA as an example (this is in
>> src/share/classes/com/sun/corba/se/spi/transport):
>>
>> > hg log CorbaAcceptor.java | grep changeset:
>>
>> changeset: 324:34a977b07ae0
>> changeset: 300:e2b177d79942
>> changeset: 0:0fc818f2f9e5
>>
>> > hg log -r 324 | grep date
>>
>> date: Thu Aug 27 13:59:49 2009 -0700
>>
>> So we can extract the year of the last change, and while updating the
>> file header,
>> insert the correct year. Gluing this together in a shell script is
>> easy enough, and I'd
>> imagine something similar is possible in svn.
>>
>> Putting this all together, you could easily have a Hudson job that
>> fixed everything up
>> automatically that can be run whenever desired in the release cycle.
>> The tool
>> can also be run as a copyright header validator.
>
> The date should be checked/updated on every commit. Even if the tool is
> fast, I'm not sure I'd want it automatically introducing future conflicts
> into my files.
OK. The conflict problem is pretty trivial in mercurial, especially
with jfilemerge
as the merge tool: it automatically merges stuff like this. But things
are more difficult
in the svn world.

The maven plugin that Justin mentioned sounds fairly similar to my tool,
but I haven't
done a detailed comparison.
>
> Right now we need to update all the files to have the correct license and
> at least this year's copyright date. Getting the right license on each
> file can be complicated.
The tool handles a lot of this. It understand directories and file names to
skip, plus file-suffix specific processing. It can handle special files
as well.
license-tool can handle multiple
formats (XML, scheme, text, java, and shell comment syntax at least,
and it's easy to add others) using the same basic license text.
The tool also understand shell scripts, so that the initial #! comment
is preserved in
the correct position.

I'm not entirely sure about what changes have been made in the license-tool
project itself. I contributed the original code, but someone from the
Metro
team has done a good bit of work on the tool.
                                                                  

License-tool will also detect all license headers (e.g. IBM copyrights) and
preserves those. Only Sun copyright headers are affected.

The copyright date handling is the main part that could use some improvement
as previously mentioned.

>
> Once that's done having a tool to detect and report missing updates would
> be helpful, although I fear people wouldn't pay any more attention to it
> than they do to the FindBugs reminders they get.
Yes, that is a risk. I use the tool to automatically update the CORBA
files,
though of course that may make some people nervous.
>
> Maybe this is something that Jane and/or Terena can work on, perhaps with
> some help from some of us?
>
Certainly, but this seems like a post-HCF task at this point.

Ken.