ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <nicolas.lale...@hibnet.org>
Subject Re: Creation of a new ivy resolver
Date Tue, 07 Aug 2012 13:24:54 GMT
Le 7 août 2012 à 15:05, Adrien Lecharpentier a écrit :
> 2012/8/7 Nicolas Lalevée <nicolas.lalevee@hibnet.org>
> 
>> I have looked at you patch more closely, and there are indeed some strange
>> things. I don't understand why the parsing of a cudf file have to depend on
>> the resolve context.
> 
> 
> In fact, the resolving is done on server-side for CUDF. That's why we use
> the resolve context to be able to ask the resolution for each specific
> configuration.

"server side" ? Sorry, but you get me even more confused :)
If the resolution is done server side, where is the code of the algorithm ? How would a user
of Ivy is supposed to use it ?

Nicolas

> 
> 
>> It means that this file format is not describing dependencies
>> independently of a resolve. This format could not be used to describe the
>> dependencies of a project in development ? It should only be used to
>> describe transitive dependencies ?
>> 
> 
> We want to use this format to be able to generate resolution Q&A so that
> client side doesn't have to care about conflicts.
> 
> 
>> For instance the configurations declared for a parsed module are computed
>> from the "root" ones.
> 
> 
> We are working to modify that to be able to send all the dependencies set
> in a configuration to have the list of all dependencies needed for the
> configuration (1st-level and transitive deps).
> 
> 
>> I understand the notion of configuration might not exist for cudf files.
>> But then just choose the "default" configuration for instance. Then it is
>> up to the root ivy file, if it is xml, to properly reference the "default"
>> configuration implicitly declared in a cudf file.
>> 
> 
> We want to make one resolution question for each configuration of ivy file.
> 
> 
>> And about the conflict resolution, it should be independent of the format
>> of the module descriptor. Why and how the cudf format is enforcing it ?
>> 
> 
> Resolution is done on server side. The "list" of dependencies the client
> gets is conflict-less.
> 
> 
>> I think that what you should focus on is the mapping between the cudf
>> format and the Ivy "ModuleDescriptor" model. AFAI, the cudf format has less
>> features than Ivy does, so once you have done that, it will plug nicely
>> into Ivy.
> 
> Look at how the OSGi support was implemented. First the mapping :
>> http://ant.apache.org/ivy/history/latest-milestone/osgi/osgi-mapping.html(at some
point it will be really great the you write a such doc about the
>> cudf format). Then, as the OSGi model has features Ivy doesn't have, I had
>> to work around it by writing a resolver. But I don't think you need to for
>> cudf.
>> 
>> But I probably not know the cudf format as well as you do. Please correct
>> me if I'm wrong.
>> 
>> Nicolas
>> 
>> Le 7 août 2012 à 11:33, Adrien Lecharpentier a écrit :
>> 
>>> Hello,
>>> 
>>> some updates on this question.
>>> We've notice that the resolver is called at each dependency fetched. The
>>> problem with that is the list of dependencies returned in the cudf
>>> file/output is already conflict-less.
>>> 
>>> That was on of the reason why we implement a resolver at first.
>>> 
>>> Any thought about this?
>>> 
>>> Thanks!
>>> 
>>> --
>>> Adrien Lecharpentier
>>> 
>>> 
>>> 2012/5/25 Nicolas Lalevée <nicolas.lalevee@hibnet.org>
>>> 
>>>> Hi Adrien,
>>>> 
>>>> I just saw your patch in IVY-1352. So you found out that jira is the way
>>>> to go, cool :)
>>>> 
>>>> About the submission, given the size of the patch, when uploading your
>>>> patch, you should check the button "Grant license to ASF for inclusion
>> in
>>>> ASF works". You should also remove the copyright notices in the header
>> of
>>>> the files. So it would clear the legal work.
>>>> 
>>>> About the technical details, we'll discuss it in the jira issue.
>>>> 
>>>> cheers,
>>>> Nicolas
>>>> 
>>>> Le 24 mai 2012 à 10:19, Adrien Lecharpentier a écrit :
>>>> 
>>>>> Hello,
>>>>> 
>>>>> I create a new resolver in Ivy and would like to integrate it into the
>>>>> official source code repository.
>>>>> 
>>>>> This new resolver is using a CUDF format to describe the dependencies
>> of
>>>> a
>>>>> module. This description file is generated by a server. The aim is to
>>>> have
>>>>> a server side dependency resolution, the client site is onyl about to
>>>>> download the description file, parse it and use information it
>> contains.
>>>>> 
>>>>> I used a fork of the github repository, work on a separate branch but
I
>>>>> integrate the changes you've done on trunk. How can I proceed to give
>> you
>>>>> the source code ?
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> --
>>>>> Adrien Lecharpentier
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>>>> For additional commands, e-mail: dev-help@ant.apache.org
>>>> 
>>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>> 
>> 
> 
> 
> -- 
> 
> --
> Adrien Lecharpentier


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message