sqoop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Attila Szabo <asz...@cloudera.com>
Subject Re: Ivy local resolve
Date Wed, 18 May 2016 19:05:58 GMT
Hi,

I think in my previous mail I've an invalid review ticket link.

The proper one is this:
https://reviews.apache.org/r/47110/diff/1#index_header

Sorry for the confusion!

Cheers,
M.

On Tue, May 10, 2016 at 9:02 PM, Attila Szabo <aszabo@cloudera.com> wrote:

> Hi all,
>
> Do you have got any comments on this?
>
> Thanks,
> M.
>
> On Mon, May 9, 2016 at 9:27 AM, Attila Szabo <aszabo@cloudera.com> wrote:
>
>> Hey Jarcec,
>>
>> Sorry for this, but I've forgot this one...
>>
>> Please find my proposed changes here:
>>
>> https://reviews.apache.org/r/47108/diff/1#index_header
>>
>> Please also review it when you'll have time for that!
>>
>> Cheers,
>> Maugli
>>
>> On Thu, Apr 21, 2016 at 4:30 PM, Jarek Jarcec Cecho <jarcec@apache.org>
>> wrote:
>>
>>> Hi Attila,
>>> thank you for looking into how to make Sqoop 1 compilation faster. I’m
>>> also in the camp of devs who is affected by the turn around of at least 3
>>> minutes for one simple change :( I’m sadly not an ivy expert either, but
>>> I’m sure that we can do some staged approach to make at least option to
>>> build faster. Could you open a JIRA and attach the patch there? Sadly our
>>> mailing lists doesn’t allow attachments so the patch did not made it to
>>> list.
>>>
>>> Jarcec
>>>
>>> > On Apr 18, 2016, at 4:26 AM, Attila Szabo <aszabo@cloudera.com> wrote:
>>> >
>>> > Hi all,
>>> >
>>> > First let me introduce myself to the community:
>>> > I'm Attila Szabo. I'm a software engineer at Cloudera since Oct. 2015,
>>> and I've just recently (March this year) started to contribute Sqoop. So as
>>> you can see I'm quite new in this community, but also I'm very enthusiastic
>>> to join the Sqoop development.
>>> >
>>> > I'd like to ask a question about Ivy resolve, and how to make it
>>> affective.
>>> > I have to highlight that I'm not an ant or ivy expert, so maybe this
>>> is possible I've missed something!
>>> >
>>> > However I've faced the following issue on my dev pc:
>>> >
>>> > Every ant operation is very slow at me, because regardless I have the
>>> artifacts in my local ivy cache or not, it goes to the maven2 repo to check
>>> something connected to the resolve process. It doesn't download anything,
>>> as I've already got the dependencies, however this process is still quite
>>> slow (on my home network for example it could take 2-5 minutes).
>>> >
>>> > I've seen that it looks for the dependencies in the local .m2
>>> repository, but usually I do not have those artifacts in my local .m2 and
>>> also for me it would make sense to have a maven independent solution.
>>> >
>>> > So I've read a few things about ivy resolver, and got a workaround
>>> (details in the attached patch file), which provides another FS related
>>> resolver points to my local ivy cache, and that gives the required
>>> performance for me (10 seconds max the resolve phase, once I've downloaded
>>> all the dependencies).
>>> >
>>> > My questions are the following:
>>> >       • Is it a valid solution, or did I make any fundamental mistakes?
>>> >       • If the ivy cache related way is not preferred (by any reason),
>>> is there any EZ to access and run solution to have the related artifacts
>>> installed/downloaded in my local maven repo.
>>> >       • Is there any other way to have a fast resolution without
>>> "hacking" around the ivysettings or the local maven repo (it is possible
>>> I've just missed an ant task, or something in the docs).
>>> > Many thanks for the help,
>>> >
>>> >
>>> > --
>>> > Best regards,
>>> >
>>> > Attila Szabo
>>> > Sotware Engineer
>>> >
>>> >
>>>
>>>
>>
>>
>> --
>> Best regards,
>>
>> Attila Szabo
>> Sotware Engineer
>>
>> <http://www.cloudera.com>
>>
>
>
>
> --
> Best regards,
>
> Attila Szabo
> Sotware Engineer
>
> <http://www.cloudera.com>
>



-- 
Best regards,

Attila Szabo
Sotware Engineer

<http://www.cloudera.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message