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