sqoop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anna Szonyi (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SQOOP-3052) Introduce Maven/Gradle/etc. based build for Sqoop to make it more developer friendly / open
Date Mon, 19 Mar 2018 13:11:00 GMT

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

Anna Szonyi commented on SQOOP-3052:

 Hi [~maugli],

It seems I've missed your comment - apologies! The patches I attached were in a mostly complete
state, I attached it as I got some requests around trying it out, but there were some files
missing (script templates, etc.) and some further polishing to be done.

I'll attach the finished version.



> Introduce Maven/Gradle/etc. 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, 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

View raw message