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 14:23:49 GMT

Le 7 août 2012 à 15:40, Adrien Lecharpentier a écrit :

> The main idea of this story is to have all the conflicts resolution on the
> server so that all the users could have the same answer. All the users
> doesn't only mean "all ivy users" but also maven and also other
> technologies users (php, c++, .net,…).
> 
> We wrote an article about that here:
> http://blog.zenika.com/index.php?post/2012/07/24/Gestion-de-d%C3%A9pendances-et-conflits-CUDF-1/3
> 
> We are implementing in Ivy and Archiva all the code about CUDF.

ok.
Then I feel uncomfortable adding support within Ivy for a specific resolver which will only
work with the proper repository which contains the proper plugin. Seems to me a too narrow
use case.
So sorry but unless another Ivy committer want to step up, I think it will a little bit of
burden on us (which are not many).

I hope I won't demotivate you from trying to contribute to Ivy. Every involvement is appreciated.

cheers,
Nicolas

> 2012/8/7 Nicolas Lalevée <nicolas.lalevee@hibnet.org>
> 
>> 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(atsome
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
>> 
>> 
> 
> 
> -- 
> 
> --
> 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