Hadoop Common
  1. Hadoop Common
  2. HADOOP-3676

Remove Hadoop's dependance on the cli 2 snapshot

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: 0.20.1
    • Component/s: util
    • Labels:
      None
    • Hadoop Flags:
      Incompatible change

      Description

      Currently, the Hadoop release includes a jar of the Apache commons-cli from a snapshot of 2.0. Hadoop isn't getting a major benefit from the 2.0 api, which in fact is pretty buggy, and we should just roll back to the cli 1.1 release.

        Issue Links

        There are no Sub-Tasks for this issue.

          Activity

          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Resolved Resolved
          427d 5h 17m 1 Owen O'Malley 01/Sep/09 22:13
          Carl Steinbach made changes -
          Link This issue relates to HIVE-1817 [ HIVE-1817 ]
          Owen O'Malley made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 0.20.1 [ 12313866 ]
          Resolution Duplicate [ 3 ]
          Hide
          Owen O'Malley added a comment -

          This was closed by MAPREDUCE-767.

          Show
          Owen O'Malley added a comment - This was closed by MAPREDUCE-767 .
          Amar Kamat made changes -
          Link This issue is blocked by HADOOP-6213 [ HADOOP-6213 ]
          Giridharan Kesavan made changes -
          Link This issue is blocked by MAPREDUCE-767 [ MAPREDUCE-767 ]
          Hide
          Steve Loughran added a comment -

          Frederick,
          The issue is not that we can't get hold of a CLI snapshot (we have one checked in), but that apache rules say "don't release snapshort artifacts as they haven't been through the full legally backed release process". to put it differently: SNAPSHOTS are nightly builds, not releases, don't depend on them.

          That holds for the SNAPSHOT repository, which is an interesting area, and not anything that anyone who wants a replicable build should be including in their dependency graph, as it becomes impossible to build a previous version of your application if that artifact changes.

          Show
          Steve Loughran added a comment - Frederick, The issue is not that we can't get hold of a CLI snapshot (we have one checked in), but that apache rules say "don't release snapshort artifacts as they haven't been through the full legally backed release process". to put it differently: SNAPSHOTS are nightly builds, not releases, don't depend on them. That holds for the SNAPSHOT repository, which is an interesting area, and not anything that anyone who wants a replicable build should be including in their dependency graph, as it becomes impossible to build a previous version of your application if that artifact changes.
          Hide
          Edward J. Yoon added a comment -

          +1, and I also agree with steve loughran.

          frederick, thanks for your good tip, but there is no pom.xml file and that matter is of no significance on this issue.

          Show
          Edward J. Yoon added a comment - +1, and I also agree with steve loughran. frederick, thanks for your good tip, but there is no pom.xml file and that matter is of no significance on this issue.
          Amareshwari Sriramadasu made changes -
          Link This issue blocks HADOOP-3986 [ HADOOP-3986 ]
          Hide
          Frederick Haebin Na added a comment - - edited

          Oops again,
          0.20.0 already using it.

          why don't you close this issue.
          this is not a blocker anymore rite?

          ------------------------------------------------------------------------------------------------------------------------------
          Oops,
          what I was trying to say was that you could use snapshot release.
          You can depend on the both versions since they use different package name. (I tested with my pom file)

          -------------------------------------------------------------------------------------------------------------------------------
          Add following scripts in the pom.

          <repositories>
          <repository>
          <id>apache snapshot</id>
          <url>http://people.apache.org/repo/m2-snapshot-repository</url>
          </repository>
          </repositories>

          ...

          <dependencies>
          ...
          <!--CLI is needed to scan the command line, but only the 1.0 branch is released -->
          <dependency>
          <groupId>commons-cli</groupId>
          <artifactId>commons-cli</artifactId>
          <version>1.1</version>
          </dependency>
          <dependency>
          <groupId>org.apache.commons</groupId>
          <artifactId>commons-cli</artifactId>
          <version>2.0-SNAPSHOT</version>
          </dependency>
          ...
          </dependencies>

          Then, you will be able to use the both versions of commons-cli.

          Show
          Frederick Haebin Na added a comment - - edited Oops again, 0.20.0 already using it. why don't you close this issue. this is not a blocker anymore rite? ------------------------------------------------------------------------------------------------------------------------------ Oops, what I was trying to say was that you could use snapshot release. You can depend on the both versions since they use different package name. (I tested with my pom file) ------------------------------------------------------------------------------------------------------------------------------- Add following scripts in the pom. <repositories> <repository> <id>apache snapshot</id> <url> http://people.apache.org/repo/m2-snapshot-repository </url> </repository> </repositories> ... <dependencies> ... <!--CLI is needed to scan the command line, but only the 1.0 branch is released --> <dependency> <groupId>commons-cli</groupId> <artifactId>commons-cli</artifactId> <version>1.1</version> </dependency> <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-cli</artifactId> <version>2.0-SNAPSHOT</version> </dependency> ... </dependencies> Then, you will be able to use the both versions of commons-cli.
          Amareshwari Sriramadasu made changes -
          Link This issue blocks HADOOP-3986 [ HADOOP-3986 ]
          Hide
          Steve Loughran added a comment -

          well lets target a later version; or push the commons 2 team to roll out a stable 2.0 release.

          Show
          Steve Loughran added a comment - well lets target a later version; or push the commons 2 team to roll out a stable 2.0 release.
          Hide
          Owen O'Malley added a comment -

          which means this should really be a blocker, since we have been making releases with it. sigh Unfortunately, this means I have to re-write the cli handling for both streaming and pipes, so I think putting this into 0.18 would be a very bad idea from a reliability point of view.

          Show
          Owen O'Malley added a comment - which means this should really be a blocker, since we have been making releases with it. sigh Unfortunately, this means I have to re-write the cli handling for both streaming and pipes, so I think putting this into 0.18 would be a very bad idea from a reliability point of view.
          Hide
          Steve Loughran added a comment -

          +1

          this complicates downstream applications, and as there is no sign of a cli-2.0 coming out, would be a blocker when hadoop got round to a 1.0 release, as ASF rules say "Dont release with unreleased versions of other bits of apache code"

          Show
          Steve Loughran added a comment - +1 this complicates downstream applications, and as there is no sign of a cli-2.0 coming out, would be a blocker when hadoop got round to a 1.0 release, as ASF rules say "Dont release with unreleased versions of other bits of apache code"
          Owen O'Malley made changes -
          Field Original Value New Value
          Link This issue blocks HADOOP-3305 [ HADOOP-3305 ]
          Owen O'Malley created issue -

            People

            • Assignee:
              Owen O'Malley
              Reporter:
              Owen O'Malley
            • Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development