[jira] [Commented] (BIGTOP-1577) refactor our Gradle packaging build to get rid of direct exec's

["Olaf Flebbe (JIRA)" <ji...@apache.org>]

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

Olaf Flebbe commented on BIGTOP-1577:
-------------------------------------

Hi [~rvs] !

The rm -rf was there because of GRADLE-2892. Since it seems to be fixed in gradle-2.14 we should upgrade gradle as a prerequisite to this patch.

Background info: hue contains links in its tar. the gradle delete  created corrupt packages.

 I do not get the intention of introducing your "shell"  construct. What are you trying to accomplish ? What is the advantage of running the build tool like this rather than within the container?

BTW: I have the impression that the shell construct may not terminate synchronously. Using /dev/stdin is ugly as hell.

The real benefit of reeingineering this would have been in my opinion to get rid of the bind mount (-v) , since it results in a permission chaos and cannot be used in swarm. I was think about running the whole process in a docker build started by an Dockerfile and get the sources within the container. (Like the docker build itself is working : see github/docker/docker .


> refactor our Gradle packaging build to get rid of direct exec's
> ---------------------------------------------------------------
>
>                 Key: BIGTOP-1577
>                 URL: https://issues.apache.org/jira/browse/BIGTOP-1577
>             Project: Bigtop
>          Issue Type: Bug
>          Components: build
>    Affects Versions: 0.8.0
>            Reporter: Roman Shaposhnik
>            Assignee: Roman Shaposhnik
>             Fix For: backlog
>
>         Attachments: BIGTOP-2170.patch.txt
>
>
> Most of the use of exec tasks (e.g. for tar'ing/file manipulation/etc) can be wrapped into a native Gradle way of accomplishing the same thing. The rest are OS specific (rpmbuild, createrepo, etc.) and need to be made flexible enough so that the action can at least happen in a container.



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