sqoop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SQOOP-3052) Introduce Gradle based build for Sqoop to make it more developer friendly / open
Date Mon, 23 Jul 2018 12:10:00 GMT

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

ASF subversion and git services commented on SQOOP-3052:
--------------------------------------------------------

Commit b148d54000da8d718f95917f8bf805860a6cbfe6 in sqoop's branch refs/heads/trunk from [~vasas]
[ https://git-wip-us.apache.org/repos/asf?p=sqoop.git;h=b148d54 ]

SQOOP-3052: Introduce Gradle based build for Sqoop to make it more developer friendly / open

(Anna Szonyi via Szabolcs Vasas)


> Introduce Gradle based build for Sqoop to make it more developer friendly / open
> --------------------------------------------------------------------------------
>
>                 Key: SQOOP-3052
>                 URL: https://issues.apache.org/jira/browse/SQOOP-3052
>             Project: Sqoop
>          Issue Type: Improvement
>            Reporter: Attila Szabo
>            Assignee: Anna Szonyi
>            Priority: Major
>             Fix For: 1.5.0
>
>         Attachments: SQOOP-3052.patch
>
>
> The current trunk version can only be build with Ant/Ivy combination, which has some
painful limitations (resolve is slow / needs to be tweaked to use only caches, the current
profile / variable based settings are not working in IDEs out of the box, the current solution
does not download the related sources, etc.)
> It would be nice to provide a solution, which would give the possibility for the developers
to choose between the nowadays well used build infrsturctures (e.g. Maven, Gradle, etc.).
For this solution it would be also essential to keep the different build files (if there is
more then one) synchronized easily, and the configuration wouldn't diverege by time. Test
execution has to be solved also, and should cover all the available test cases.
> In this scenario:
> If we can provide one good working solution is much better, then provide three different
ones which become out of sync easily. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message