[jira] Updated: (HADOOP-5203) TT's version build is too restrictive

["Rick Cox (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HADOOP-5203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick Cox updated HADOOP-5203:
-----------------------------

    Attachment: HADOOP-5203-md5.patch

Doug's patch definitely provides a functional work around. I'm attaching the current state of the checksum patch. The core part of the patch is this shell line, which computes a checksum of the *.java files in src:

{{srcChecksum=`find src -name '*.java' | LC_ALL=C sort | xargs md5sum | md5sum | cut -d ' ' -f 1`}}

I'd definitely appreciate suggestions for improving that. Some other obvious solutions don't work because they don't produce the same checksums on various platforms (including using a "tar cf - -T -" in place of the "xargs md5sum"). For now, that does produce the same checksum value on Mac OS X and Linux; I'll dig out a Cygwin box and test there next, but don't have access to a Solaris box. For reference, the checksum it computes is 8238dee4c81d21734c34d7e5c420cfe2 for source at svn revision 762607 plus the attached patch.

I used *.java because it seems pretty unlikely you could produce an incompatible protocol change without modifying any java files, but could expand that if it seems too restrictive. This does allow documentation changes and build file changes, for example.

> TT's version build is too restrictive
> -------------------------------------
>
>                 Key: HADOOP-5203
>                 URL: https://issues.apache.org/jira/browse/HADOOP-5203
>             Project: Hadoop Core
>          Issue Type: Bug
>          Components: mapred
>    Affects Versions: 0.19.0
>            Reporter: Runping Qi
>            Assignee: Rick Cox
>         Attachments: HADOOP-5203-md5.patch, HADOOP-5203.patch
>
>
> At start time, TT checks whether its version is compatible with JT.
> The condition is too restrictive. 
> It will shut down itself if one of the following conditions fail:
> * the version numbers must match
> * the revision numbers must match
> * the user ids who build the jar must match
> * the build times must match
> I think it should check the major part of the version numbers only (thus any version like 0.19.xxxx should be compatible).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.