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

Eugene Koontz updated GIRAPH-168:
---------------------------------

    Description: 
This JIRA relates to the mail thread here: 

http://mail-archives.apache.org/mod_mbox/incubator-giraph-dev/201203.mbox/browser

Currently we check for the munge flags HADOOP, HADOOP_FACEBOOK and 
HADOOP_NON_SECURE when using munge in a few places. Hopefully we can eliminate 
usage of munge in the future, but until then, we can mitigate the complexity by 
consolidating the number of flags checked. This JIRA renames HADOOP_FACEBOOK to 
HADOOP_SECURE, and removes usages of HADOOP, to handle the same conditional 
compilation requirements. It also makes it easier to add more maven profiles so 
that we can easily increase our hadoop version coverage.

This patch modifies the existing hadoop_facebook profile to use the new 
HADOOP_SECURE munge flag, rather than HADOOP_FACEBOOK.

It also adds a new hadoop maven profile, hadoop_trunk, which also sets 
HADOOP_SECURE. 

Finally, it adds a default profile, hadoop_0.20.203. This is needed so that we 
can specify its dependencies separately from hadoop_trunk, because the hadoop 
dependencies have changed between trunk and 0.205.0 - the former requires 
hadoop-common, hadoop-mapreduce-client-core, and 
hadoop-mapreduce-client-common, whereas the latter requires hadoop-core. 

With this patch, the following passes:

{code}
mvn clean verify && mvn -Phadoop_trunk clean verify && mvn -Phadoop_0.20.203 
clean verify
{code}

Current problems: 

* I left in place the usage of HADOOP_NON_SECURE, but note that the profile 
that uses this is hadoop_non_secure, which fails to compile on trunk: 
https://issues.apache.org/jira/browse/GIRAPH-167 .

* I couldn't get -Phadoop_facebook to work; does this work outside of Facebook?



  was:
This JIRA relates to the mail thread here: 

http://mail-archives.apache.org/mod_mbox/incubator-giraph-dev/201203.mbox/browser

Currently we check for the munge flags HADOOP and HADOOP_FACEBOOK and 
HADOOP_NON_SECURE when using munge in a few places. Hopefully we can eliminate 
usage of munge in the future, but until then, we can mitigate the complexity by 
consolidating the number of flags checked. This JIRA proposes a single flag, 
HADOOP_SECURE, to handle the same conditional compilation requirements. It also 
makes it easier to add more maven profiles so that we can easily increase our 
hadoop version coverage.

This patch modifies the existing hadoop_facebook profile to use the new 
HADOOP_SECURE munge flag, rather than HADOOP_FACEBOOK.

It also adds a new hadoop maven profile, hadoop_trunk, which also sets 
HADOOP_SECURE. 

Finally, it adds a default profile, hadoop_0.20.203. This is needed so that we 
can specify its dependencies separately from hadoop_trunk, because the hadoop 
dependencies have changed between trunk and 0.205.0 - the former requires 
hadoop-common, hadoop-mapreduce-client-core, and 
hadoop-mapreduce-client-common, whereas the latter requires hadoop-core. 

With this patch, the following passes:

{code}
mvn clean verify && mvn -Phadoop_trunk clean verify && mvn -Phadoop_0.20.203 
clean verify
{code}

Current problems: 

* I left in place the usage of HADOOP_NON_SECURE, but note that the profile 
that uses this is hadoop_non_secure, which fails to compile on trunk: 
https://issues.apache.org/jira/browse/GIRAPH-167 .

* I couldn't get -Phadoop_facebook to work; does this work outside of Facebook?



        Summary: Simplify munge directive usage with new munge flag 
HADOOP_SECURE (rather than HADOOP_FACEBOOK) and remove usage of HADOOP  (was: 
Simplify munge directive usage with new munge flag HADOOP_SECURE rather than 
HADOOP_FACEBOOK)
    
> Simplify munge directive usage with new munge flag HADOOP_SECURE (rather than 
> HADOOP_FACEBOOK) and remove usage of HADOOP
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: GIRAPH-168
>                 URL: https://issues.apache.org/jira/browse/GIRAPH-168
>             Project: Giraph
>          Issue Type: Improvement
>    Affects Versions: 0.2.0
>            Reporter: Eugene Koontz
>            Assignee: Eugene Koontz
>         Attachments: GIRAPH-168.patch
>
>
> This JIRA relates to the mail thread here: 
> http://mail-archives.apache.org/mod_mbox/incubator-giraph-dev/201203.mbox/browser
> Currently we check for the munge flags HADOOP, HADOOP_FACEBOOK and 
> HADOOP_NON_SECURE when using munge in a few places. Hopefully we can 
> eliminate usage of munge in the future, but until then, we can mitigate the 
> complexity by consolidating the number of flags checked. This JIRA renames 
> HADOOP_FACEBOOK to HADOOP_SECURE, and removes usages of HADOOP, to handle the 
> same conditional compilation requirements. It also makes it easier to add 
> more maven profiles so that we can easily increase our hadoop version 
> coverage.
> This patch modifies the existing hadoop_facebook profile to use the new 
> HADOOP_SECURE munge flag, rather than HADOOP_FACEBOOK.
> It also adds a new hadoop maven profile, hadoop_trunk, which also sets 
> HADOOP_SECURE. 
> Finally, it adds a default profile, hadoop_0.20.203. This is needed so that 
> we can specify its dependencies separately from hadoop_trunk, because the 
> hadoop dependencies have changed between trunk and 0.205.0 - the former 
> requires hadoop-common, hadoop-mapreduce-client-core, and 
> hadoop-mapreduce-client-common, whereas the latter requires hadoop-core. 
> With this patch, the following passes:
> {code}
> mvn clean verify && mvn -Phadoop_trunk clean verify && mvn -Phadoop_0.20.203 
> clean verify
> {code}
> Current problems: 
> * I left in place the usage of HADOOP_NON_SECURE, but note that the profile 
> that uses this is hadoop_non_secure, which fails to compile on trunk: 
> https://issues.apache.org/jira/browse/GIRAPH-167 .
> * I couldn't get -Phadoop_facebook to work; does this work outside of 
> Facebook?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to