You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Adrien Lecharpentier <ad...@gmail.com> on 2012/05/24 10:19:57 UTC
Creation of a new ivy resolver
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
Re: Creation of a new ivy resolver
Posted by Adrien Lecharpentier <ad...@gmail.com>.
Nicolas,
I'm not sure this feature is too narrow. It is just at its beginning.
The CUDF will permit to have proper validation of repository
content independently of the type of content type. The cudf "resolver" (it
has only the name of it) can give the entire list of dependencies needed
for the project to run, then the client can choose to discuss with some ivy
or maven repository or even a samba folder.
I understand that you see this as a time-consumer feature (as you are not
many commiters on ivy) but I'm not supposed to leave this dev project in a
near futur.
-- Adrien
2012/8/7 Nicolas Lalevée <ni...@hibnet.org>
>
> 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 <ni...@hibnet.org>
> >
> >> Le 7 août 2012 à 15:05, Adrien Lecharpentier a écrit :
> >>> 2012/8/7 Nicolas Lalevée <ni...@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(atsomepoint 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 <ni...@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
>
>
--
--
Adrien Lecharpentier
Re: Creation of a new ivy resolver
Posted by Nicolas Lalevée <ni...@hibnet.org>.
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 <ni...@hibnet.org>
>
>> Le 7 août 2012 à 15:05, Adrien Lecharpentier a écrit :
>>> 2012/8/7 Nicolas Lalevée <ni...@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 <ni...@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
Re: Creation of a new ivy resolver
Posted by Adrien Lecharpentier <ad...@gmail.com>.
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.
2012/8/7 Nicolas Lalevée <ni...@hibnet.org>
> Le 7 août 2012 à 15:05, Adrien Lecharpentier a écrit :
> > 2012/8/7 Nicolas Lalevée <ni...@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 <ni...@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
Re: Creation of a new ivy resolver
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 7 août 2012 à 15:05, Adrien Lecharpentier a écrit :
> 2012/8/7 Nicolas Lalevée <ni...@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 <ni...@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
Re: Creation of a new ivy resolver
Posted by Adrien Lecharpentier <ad...@gmail.com>.
Thank you for your time, I've answered in your mail.
-- Adrien
2012/8/7 Nicolas Lalevée <ni...@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.
> 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 <ni...@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
Re: Creation of a new ivy resolver
Posted by Nicolas Lalevée <ni...@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. 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 ?
For instance the configurations declared for a parsed module are computed from the "root" ones. 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.
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 ?
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 <ni...@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
Re: Creation of a new ivy resolver
Posted by Adrien Lecharpentier <ad...@gmail.com>.
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 <ni...@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
>
>
Re: Creation of a new ivy resolver
Posted by Vimil Saju <vi...@yahoo.com>.
Reply to Ant Developers List
________________________________
From: Nicolas Lalevée <ni...@hibnet.org>
To: Ant Developers List <de...@ant.apache.org>
Sent: Friday, May 25, 2012 10:33 AM
Subject: Re: Creation of a new ivy resolver
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
Re: Creation of a new ivy resolver
Posted by Nicolas Lalevée <ni...@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