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 <nicolas.lale...@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 <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(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 <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 > > -- -- Adrien Lecharpentier
