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.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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
