Hadoop Common
  1. Hadoop Common
  2. HADOOP-6346

Add support for specifying unpack pattern regex to RunJar.unJar

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.21.0
    • Component/s: conf, util
    • Labels:
      None
    • Hadoop Flags:
      Reviewed

      Description

      The changes in Common necessary for MAPREDUCE-967:

      • Adds support for Pattern types to Configuration (plus unit test)
      • Adds support to specify a Pattern to RunJar.unJar to decide which files get unpacked
      1. hadoop-6346.txt
        13 kB
        Todd Lipcon
      2. hadoop-6346.txt
        13 kB
        Todd Lipcon
      3. hadoop-6346.txt
        9 kB
        Todd Lipcon
      4. hadoop-6346.txt
        9 kB
        Todd Lipcon

        Issue Links

          Activity

          Hide
          Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12423637/hadoop-6346.txt
          against trunk revision 831070.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/117/testReport/
          Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/117/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/117/artifact/trunk/build/test/checkstyle-errors.html
          Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/117/console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12423637/hadoop-6346.txt against trunk revision 831070. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/117/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/117/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/117/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/117/console This message is automatically generated.
          Hide
          Vinod Kumar Vavilapalli added a comment -

          Todd,

          • As is mentioned on MAPREDUCE-727, moving RunJar from common to mapreduce is needed also in 0.21 - a sub-task to complete the project split.
          • The changes to Configuration in Common project are, as you've said, needed only in 0.22 for the sake of MAPREDUCE-967.

          So, I think we should do the first for 0.21 too, perhaps as part of MAPREDUCE-727 itself and do only the configurtion changes here. Thoughts?

          Show
          Vinod Kumar Vavilapalli added a comment - Todd, As is mentioned on MAPREDUCE-727 , moving RunJar from common to mapreduce is needed also in 0.21 - a sub-task to complete the project split. The changes to Configuration in Common project are, as you've said, needed only in 0.22 for the sake of MAPREDUCE-967 . So, I think we should do the first for 0.21 too, perhaps as part of MAPREDUCE-727 itself and do only the configurtion changes here. Thoughts?
          Hide
          Todd Lipcon added a comment -

          Vinod: I commented on MAPREDUCE-727 a while back and no one ever responded. If someone gives an opinion there I will go ahead and do the work there - I was just trying to avoid a long dependency chain from MAPREDUCE-967.

          Show
          Todd Lipcon added a comment - Vinod: I commented on MAPREDUCE-727 a while back and no one ever responded. If someone gives an opinion there I will go ahead and do the work there - I was just trying to avoid a long dependency chain from MAPREDUCE-967 .
          Hide
          Vinod Kumar Vavilapalli added a comment -

          Todd, Arun created MAPREDUCE-727, but he didn't come back with a reply to your question. I've discussed with Sharad a bit about this and he too agrees there may be generic uses of bin/hadoop jar. So, for now, can we assume RunJar will stay in common and go ahead with this issue and MAPREDUCE-967?

          Sorry for the confusion. I originally thought there are no road-blocks for moving RunJar into MapReduce and that was why I wished MAPREDUCE-967 to be done after MAPREDUCE-727. I take that back now, let's just do this issue and MAPREDUCE-967 rightaway assuming RunJar in common. Or If you can just wait for a bit more, I'll get Arun to answer your question on MAPREDUCE-727.

          Show
          Vinod Kumar Vavilapalli added a comment - Todd, Arun created MAPREDUCE-727 , but he didn't come back with a reply to your question. I've discussed with Sharad a bit about this and he too agrees there may be generic uses of bin/hadoop jar . So, for now, can we assume RunJar will stay in common and go ahead with this issue and MAPREDUCE-967 ? Sorry for the confusion. I originally thought there are no road-blocks for moving RunJar into MapReduce and that was why I wished MAPREDUCE-967 to be done after MAPREDUCE-727 . I take that back now, let's just do this issue and MAPREDUCE-967 rightaway assuming RunJar in common. Or If you can just wait for a bit more, I'll get Arun to answer your question on MAPREDUCE-727 .
          Hide
          Todd Lipcon added a comment -

          Here's a new patch which keeps RunJar in common, and just adds the necessary Configuration mechanics and changes to RunJar.unJar. I fixed up a couple deprecation warnings while I was in that function, and refactored some common code.

          Show
          Todd Lipcon added a comment - Here's a new patch which keeps RunJar in common, and just adds the necessary Configuration mechanics and changes to RunJar.unJar. I fixed up a couple deprecation warnings while I was in that function, and refactored some common code.
          Hide
          Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12424908/hadoop-6346.txt
          against trunk revision 836019.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/138/testReport/
          Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/138/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/138/artifact/trunk/build/test/checkstyle-errors.html
          Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/138/console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12424908/hadoop-6346.txt against trunk revision 836019. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/138/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/138/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/138/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/138/console This message is automatically generated.
          Hide
          Todd Lipcon added a comment -

          One self-review comment: there's an unused UNPACK_DEFAULT constant that should be removed. I'll wait until someone else chimes in with any review comments to make a new patch.

          Show
          Todd Lipcon added a comment - One self-review comment: there's an unused UNPACK_DEFAULT constant that should be removed. I'll wait until someone else chimes in with any review comments to make a new patch.
          Hide
          Vinod Kumar Vavilapalli added a comment -

          Patch looks mostly good. Two comments:

          • Shouldn't we use the same pattern for RunJar to decide which classes it puts on its own classpath?
          • Add a test in TestRunJar to test particularly this feature? That it only unjars what is specified and leaves everything else jarred?
          Show
          Vinod Kumar Vavilapalli added a comment - Patch looks mostly good. Two comments: Shouldn't we use the same pattern for RunJar to decide which classes it puts on its own classpath? Add a test in TestRunJar to test particularly this feature? That it only unjars what is specified and leaves everything else jarred?
          Hide
          Todd Lipcon added a comment -

          Shouldn't we use the same pattern for RunJar to decide which classes it puts on its own classpath?

          Are you suggesting opening up the jar with a new JarFile instance inside RunJar.main, and then using the pattern to determine what strings to put on classpath? That seems not-quite-right to me, since we want to unjar classes/*/.class, but only added classes/ to the classpath, right?

          Add a test in TestRunJar to test particularly this feature? That it only unjars what is specified and leaves everything else jarred?

          What jar should I use to test this with? There are not currently any jars generated in the build/test directory. I could either (a) add a new ant target to generate a test.jar with some files in it, or (b) generate the test jar from within the test case using JarOutputStream. Any preference which I do?

          Show
          Todd Lipcon added a comment - Shouldn't we use the same pattern for RunJar to decide which classes it puts on its own classpath? Are you suggesting opening up the jar with a new JarFile instance inside RunJar.main, and then using the pattern to determine what strings to put on classpath? That seems not-quite-right to me, since we want to unjar classes/* / .class, but only added classes/ to the classpath, right? Add a test in TestRunJar to test particularly this feature? That it only unjars what is specified and leaves everything else jarred? What jar should I use to test this with? There are not currently any jars generated in the build/test directory. I could either (a) add a new ant target to generate a test.jar with some files in it, or (b) generate the test jar from within the test case using JarOutputStream. Any preference which I do?
          Hide
          Vinod Kumar Vavilapalli added a comment -

          Are you suggesting opening up the jar with a new JarFile instance inside RunJar.main, and then using the pattern to determine what strings to put on classpath? That seems not-quite-right to me, since we want to unjar classes/*/.class, but only added classes/ to the classpath, right?

          hm.. I see the problem. But It's odd that we may not unjar "classes" directory depending on the pattern but still put it on the classpath. May be we should only put the workDir and the direct contents of it on the classpath? Thoughts? Any other ideas? Or leave the classpath alone?

          What jar should I use to test this with? There are not currently any jars generated in the build/test directory. I could either (a) add a new ant target to generate a test.jar with some files in it, or (b) generate the test jar from within the test case using JarOutputStream. Any preference which I do?

          Two choices:

          • Either you can add dummy directories/files under src/test/mapred/testjar/ and build the jar(search for testjar in build.xml).
          • Or, (this is what I would do) build a jar yourselves using JarOutputStream inside the test itself, and create entries(ZipEntries) corresponding to dirs/files you want RunJar to unjar. Something similar is written for TestTaskTrackerLocalization.uploadJobJar(). After building the jar, we can then call RunJar.unJar() and verify that only dirs that are specified via the pattern are unjarred.
          Show
          Vinod Kumar Vavilapalli added a comment - Are you suggesting opening up the jar with a new JarFile instance inside RunJar.main, and then using the pattern to determine what strings to put on classpath? That seems not-quite-right to me, since we want to unjar classes/*/.class, but only added classes/ to the classpath, right? hm.. I see the problem. But It's odd that we may not unjar "classes" directory depending on the pattern but still put it on the classpath. May be we should only put the workDir and the direct contents of it on the classpath? Thoughts? Any other ideas? Or leave the classpath alone? What jar should I use to test this with? There are not currently any jars generated in the build/test directory. I could either (a) add a new ant target to generate a test.jar with some files in it, or (b) generate the test jar from within the test case using JarOutputStream. Any preference which I do? Two choices: Either you can add dummy directories/files under src/test/mapred/testjar/ and build the jar(search for testjar in build.xml). Or, (this is what I would do) build a jar yourselves using JarOutputStream inside the test itself, and create entries(ZipEntries) corresponding to dirs/files you want RunJar to unjar. Something similar is written for TestTaskTrackerLocalization.uploadJobJar() . After building the jar, we can then call RunJar.unJar() and verify that only dirs that are specified via the pattern are unjarred.
          Hide
          Todd Lipcon added a comment -

          hm.. I see the problem. But It's odd that we may not unjar "classes" directory depending on the pattern but still put it on the classpath. May be we should only put the workDir and the direct contents of it on the classpath? Thoughts? Any other ideas? Or leave the classpath alone?

          I think we should leave the classpath alone. As this patch stands, it's not a breaking change, but getting rid of classes/ from the classpath would be. It's already also being put on the classpath even in the case when it doesn't exist, which doesn't cause any problems.

          Either you can add dummy directories/files under src/test/mapred/testjar/ and build the jar(search for testjar in build.xml).

          This only exists in the mapreduce build, not in common. This patch is now in common, so no such luck.

          build a jar yourselves using JarOutputStream inside the test itself

          Done. New patch attached that includes this unit test.

          Show
          Todd Lipcon added a comment - hm.. I see the problem. But It's odd that we may not unjar "classes" directory depending on the pattern but still put it on the classpath. May be we should only put the workDir and the direct contents of it on the classpath? Thoughts? Any other ideas? Or leave the classpath alone? I think we should leave the classpath alone. As this patch stands, it's not a breaking change, but getting rid of classes/ from the classpath would be. It's already also being put on the classpath even in the case when it doesn't exist, which doesn't cause any problems. Either you can add dummy directories/files under src/test/mapred/testjar/ and build the jar(search for testjar in build.xml). This only exists in the mapreduce build, not in common. This patch is now in common, so no such luck. build a jar yourselves using JarOutputStream inside the test itself Done. New patch attached that includes this unit test.
          Hide
          Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12426633/hadoop-6346.txt
          against trunk revision 886003.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 5 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/158/testReport/
          Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/158/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/158/artifact/trunk/build/test/checkstyle-errors.html
          Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/158/console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12426633/hadoop-6346.txt against trunk revision 886003. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 5 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/158/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/158/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/158/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/158/console This message is automatically generated.
          Hide
          Vinod Kumar Vavilapalli added a comment -

          I think we should leave the classpath alone. As this patch stands, it's not a breaking change, but getting rid of classes/ from the classpath would be. It's already also being put on the classpath even in the case when it doesn't exist, which doesn't cause any problems.

          I'm fine with leaving classpath alone.

          Gone through the patch for one final time. Looks good. +1. Can ask someone to commit this, once Hudson blesses it?

          Show
          Vinod Kumar Vavilapalli added a comment - I think we should leave the classpath alone. As this patch stands, it's not a breaking change, but getting rid of classes/ from the classpath would be. It's already also being put on the classpath even in the case when it doesn't exist, which doesn't cause any problems. I'm fine with leaving classpath alone. Gone through the patch for one final time. Looks good. +1. Can ask someone to commit this, once Hudson blesses it?
          Hide
          Todd Lipcon added a comment -

          Gone through the patch for one final time. Looks good. +1. Can ask someone to commit this, once Hudson blesses it?

          Only issue to worry about is that MAPREDUCE-967 really ought to go in at the same time. Otherwise, the "-file" argument in streaming will be broken until that patch is committed (it currently works by sticking files into the job jar and assuming they'll be unpacked automatically; that patch fixes it to use the config parameter added here).

          Unfortunately the dependency is circular - we can't commit MAPREDUCE-967 without compiling against a jar built from HADOOP-6346 :-/

          Show
          Todd Lipcon added a comment - Gone through the patch for one final time. Looks good. +1. Can ask someone to commit this, once Hudson blesses it? Only issue to worry about is that MAPREDUCE-967 really ought to go in at the same time. Otherwise, the "-file" argument in streaming will be broken until that patch is committed (it currently works by sticking files into the job jar and assuming they'll be unpacked automatically; that patch fixes it to use the config parameter added here). Unfortunately the dependency is circular - we can't commit MAPREDUCE-967 without compiling against a jar built from HADOOP-6346 :-/
          Hide
          Vinod Kumar Vavilapalli added a comment -

          Only issue to worry about is that MAPREDUCE-967 really ought to go in at the same time. Otherwise, the "-file" argument in streaming will be broken until that patch is committed (it currently works by sticking files into the job jar and assuming they'll be unpacked automatically; that patch fixes it to use the config parameter added here).

          There is only one way we can do this AFAIK. Let this patch go in as is. If there are any mapred/streaming tests(looked around but can't find any) that fail because of this common project change, let the tests crib - we will just file a JIRA issue saying the test failure will be fixed once MAPREDUCE-967 goes in. This is OK as we are anyways planning MAPREDUCE-967 for the same release (0.22). OK?

          Show
          Vinod Kumar Vavilapalli added a comment - Only issue to worry about is that MAPREDUCE-967 really ought to go in at the same time. Otherwise, the "-file" argument in streaming will be broken until that patch is committed (it currently works by sticking files into the job jar and assuming they'll be unpacked automatically; that patch fixes it to use the config parameter added here). There is only one way we can do this AFAIK. Let this patch go in as is. If there are any mapred/streaming tests(looked around but can't find any) that fail because of this common project change, let the tests crib - we will just file a JIRA issue saying the test failure will be fixed once MAPREDUCE-967 goes in. This is OK as we are anyways planning MAPREDUCE-967 for the same release (0.22). OK?
          Hide
          Todd Lipcon added a comment -

          Sounds great. There are no tests that will currently fail afaik - we found the streaming-related bug in manual testing. I've included a test that would fail as part of MAPREDUCE-967 to make sure it's covered in the future, though.

          Thanks again for the reviews and attention.

          Show
          Todd Lipcon added a comment - Sounds great. There are no tests that will currently fail afaik - we found the streaming-related bug in manual testing. I've included a test that would fail as part of MAPREDUCE-967 to make sure it's covered in the future, though. Thanks again for the reviews and attention.
          Hide
          Tom White added a comment -

          Looks good. One nit: there's a typo in Configuration's javadoc, "ocde" should be "code".

          Show
          Tom White added a comment - Looks good. One nit: there's a typo in Configuration's javadoc, "ocde" should be "code".
          Hide
          Todd Lipcon added a comment -

          Patch fixes the javadoc spelling typo. Thanks for noticing, Tom.

          Show
          Todd Lipcon added a comment - Patch fixes the javadoc spelling typo. Thanks for noticing, Tom.
          Hide
          Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12426950/hadoop-6346.txt
          against trunk revision 887047.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 5 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/168/testReport/
          Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/168/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/168/artifact/trunk/build/test/checkstyle-errors.html
          Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/168/console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12426950/hadoop-6346.txt against trunk revision 887047. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 5 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/168/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/168/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/168/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/168/console This message is automatically generated.
          Hide
          Tom White added a comment -

          I've just committed this. Thanks Todd!

          Show
          Tom White added a comment - I've just committed this. Thanks Todd!
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Common-trunk-Commit #103 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Common-trunk-Commit/103/)
          . Add support for specifying unpack pattern regex to RunJar.unJar. Contributed by Todd Lipcon.

          Show
          Hudson added a comment - Integrated in Hadoop-Common-trunk-Commit #103 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Common-trunk-Commit/103/ ) . Add support for specifying unpack pattern regex to RunJar.unJar. Contributed by Todd Lipcon.
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Common-trunk #183 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Common-trunk/183/)
          . Add support for specifying unpack pattern regex to RunJar.unJar. Contributed by Todd Lipcon.

          Show
          Hudson added a comment - Integrated in Hadoop-Common-trunk #183 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Common-trunk/183/ ) . Add support for specifying unpack pattern regex to RunJar.unJar. Contributed by Todd Lipcon.

            People

            • Assignee:
              Todd Lipcon
              Reporter:
              Todd Lipcon
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development