Chukwa
  1. Chukwa
  2. CHUKWA-241

chukwa doesn't work after building from source

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 0.1.2, 0.2.0, 0.3.0
    • Fix Version/s: 0.4.0
    • Component/s: None
    • Labels:
      None

      Description

      When you build chukwa from source and then try to run a command, it won't work, since the ivy-downloaded libraries aren't on the path.

      1. fixHadopJarDisc.patch
        2 kB
        Ari Rabkin
      2. CHUKWA-241-1.patch
        1.0 kB
        Eric Yang
      3. CHUKWA-241.patch
        0.5 kB
        Ari Rabkin

        Activity

        Hide
        Hudson added a comment -

        Integrated in Chukwa-trunk #220 (See http://hudson.zones.apache.org/hudson/job/Chukwa-trunk/220/)
        . Revise Hadoop jar discovery
        . Revise chukwa-config.sh so that chukwa runs after building from source. Contributed by Eric Yang.

        Show
        Hudson added a comment - Integrated in Chukwa-trunk #220 (See http://hudson.zones.apache.org/hudson/job/Chukwa-trunk/220/ ) . Revise Hadoop jar discovery . Revise chukwa-config.sh so that chukwa runs after building from source. Contributed by Eric Yang.
        Hide
        Ari Rabkin added a comment -

        Committed this patch.

        Show
        Ari Rabkin added a comment - Committed this patch.
        Hide
        Eric Yang added a comment -

        +1 Clean patch, I like it.

        Show
        Eric Yang added a comment - +1 Clean patch, I like it.
        Hide
        Ari Rabkin added a comment -

        How do you feel about this patch? Checks hadoopjars/* instead of ../../..

        Show
        Ari Rabkin added a comment - How do you feel about this patch? Checks hadoopjars/* instead of ../../..
        Hide
        Eric Yang added a comment -

        Unless Hadoop start to push their jar to maven repository, and we use ivy to download it. Otherwise dynamic discovery doesn't work.

        The current implementation is lookup hadoopjars, then environment variable. HADOOP_HOME and HADOOP_CONF_DIR should be the standard way to locate HADOOP. What we can do is to ask user to define them, like ANT_HOME, JAVA_HOME, or stop the program execution.

        Show
        Eric Yang added a comment - Unless Hadoop start to push their jar to maven repository, and we use ivy to download it. Otherwise dynamic discovery doesn't work. The current implementation is lookup hadoopjars, then environment variable. HADOOP_HOME and HADOOP_CONF_DIR should be the standard way to locate HADOOP. What we can do is to ask user to define them, like ANT_HOME, JAVA_HOME, or stop the program execution.
        Hide
        Ari Rabkin added a comment -

        I think the real problem is that our algorithm for finding a Hadoop jar dates to when we lived in contrib. Now that we don't, it doesn't really work.

        Show
        Ari Rabkin added a comment - I think the real problem is that our algorithm for finding a Hadoop jar dates to when we lived in contrib. Now that we don't, it doesn't really work.
        Hide
        Ari Rabkin added a comment -

        I just committed this patch. BUT BUT BUT I don't think we should close the issue. Because svn doesn't include a chukwa-env.sh, none of the environment variables are defined, and therefore stuff still doesn't work when run from trunk svn.

        Show
        Ari Rabkin added a comment - I just committed this patch. BUT BUT BUT I don't think we should close the issue. Because svn doesn't include a chukwa-env.sh, none of the environment variables are defined, and therefore stuff still doesn't work when run from trunk svn.
        Hide
        Ari Rabkin added a comment -

        I like this patch, and forgot to vote for it. +1 to commit.

        Show
        Ari Rabkin added a comment - I like this patch, and forgot to vote for it. +1 to commit.
        Hide
        Eric Yang added a comment -

        Copying ivy download library to lib is likely to mix up the source and temp files. The workaround is to load ivy downloaded libraries, if they exist.

        Show
        Eric Yang added a comment - Copying ivy download library to lib is likely to mix up the source and temp files. The workaround is to load ivy downloaded libraries, if they exist.
        Hide
        Ari Rabkin added a comment -

        This needs to be fixed before we can call it a "release"

        Show
        Ari Rabkin added a comment - This needs to be fixed before we can call it a "release"
        Hide
        Ari Rabkin added a comment -

        A related issue: Where do the chukwa jars get put?

        Show
        Ari Rabkin added a comment - A related issue: Where do the chukwa jars get put?
        Hide
        Eric Yang added a comment -

        Yes.

        Show
        Eric Yang added a comment - Yes.
        Hide
        Ari Rabkin added a comment -

        Eric, I think that's a good approach. Can you code it up?

        Show
        Ari Rabkin added a comment - Eric, I think that's a good approach. Can you code it up?
        Hide
        Eric Yang added a comment -

        It would be better to change the build.xml to move ivy download libraries to lib to reduce the necessity of including stuff from build. The current patch breaks the class path on binary only deployment.

        Show
        Eric Yang added a comment - It would be better to change the build.xml to move ivy download libraries to lib to reduce the necessity of including stuff from build. The current patch breaks the class path on binary only deployment.
        Hide
        Ari Rabkin added a comment -

        Suggested fix: add ivy libs dir to path

        Show
        Ari Rabkin added a comment - Suggested fix: add ivy libs dir to path

          People

          • Assignee:
            Eric Yang
            Reporter:
            Ari Rabkin
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development