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 <nicolas.lale...@hibnet.org> > Le 7 août 2012 à 15:05, Adrien Lecharpentier a écrit : > > 2012/8/7 Nicolas Lalevée <nicolas.lale...@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.lale...@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-unsubscr...@ant.apache.org > >>>> For additional commands, e-mail: dev-h...@ant.apache.org > >>>> > >>>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > >> For additional commands, e-mail: dev-h...@ant.apache.org > >> > >> > > > > > > -- > > > > -- > > Adrien Lecharpentier > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > > -- -- Adrien Lecharpentier
