Mailing-List: contact notifications-help@yetus.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@yetus.apache.org
Date: Tue, 16 Aug 2016 16:30:20 +0000 (UTC)
From: "Allen Wittenauer (JIRA)" <jira@apache.org>
To: notifications@yetus.apache.org
Message-ID: <JIRA.12992623.1469548200000.319154.1471365020760@Atlassian.JIRA>
In-Reply-To: <JIRA.12992623.1469548200000@Atlassian.JIRA>
References: <JIRA.12992623.1469548200000@Atlassian.JIRA> <JIRA.12992623.1469548200594@arcas>
Subject: [jira] [Commented] (YETUS-435) hadoop: always build a custom
 leveldbjni
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 16 Aug 2016 16:30:22 -0000


    [ https://issues.apache.org/jira/browse/YETUS-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422987#comment-15422987 ] 

Allen Wittenauer commented on YETUS-435:
----------------------------------------

It's a bit more complex than that.

Currently, people are working around this by building leveldbjni via mvn install outside of the build process.  This causes the bits to get installed into the ~/.m2 repo so that when Hadoop builds, it picks it up from there.

In the case of Yetus, we can't do that because when we pass --mvn-custom-repos to change from ~/.m2 to a different location (to avoid the maven cache collision problem), we won't have leveldbjni in it. So we have to build leveldbjni during the Yetus run, not before.

 There's also the question around consistency.  Yetus should probably do this for *all* platforms, including the three that leveldbjni-all actually includes.

> hadoop: always build a custom leveldbjni
> ----------------------------------------
>
>                 Key: YETUS-435
>                 URL: https://issues.apache.org/jira/browse/YETUS-435
>             Project: Yetus
>          Issue Type: Bug
>          Components: Test Patch
>            Reporter: Allen Wittenauer
>            Assignee: Allen Wittenauer
>
> Apache Hadoop needs a shared library that is normally embedded in a dependency's jar file.  This breaks all but four platforms.  Response from Hadoop community has been that it is the user's responsibility to provide a working jar.  Therefore, we need to fix this in the Yetus personality so that ASF Jenkins ppc64le builds in the Docker container work properly when custom maven repos are used.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)