Thank you for your time, I've answered in your mail. -- Adrien
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. > 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 <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
