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 <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
