Re: Creation of a new ivy resolver
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 > > 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 > > > >> Le 7 août 2012 à 15:05, Adrien Lecharpentier a écrit : > >>> 2012/8/7 Nicolas Lalevée > >>> > 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 d
Re: Creation of a new ivy resolver
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 > >> Le 7 août 2012 à 15:05, Adrien Lecharpentier a écrit : >>> 2012/8/7 Nicolas Lalevée >>> 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 > >> 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
Re: Creation of a new ivy resolver
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. 2012/8/7 Nicolas Lalevée > Le 7 août 2012 à 15:05, Adrien Lecharpentier a écrit : > > 2012/8/7 Nicolas Lalevée > > > >> 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 > >>> > 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 i
Re: Creation of a new ivy resolver
Le 7 août 2012 à 15:05, Adrien Lecharpentier a écrit : > 2012/8/7 Nicolas Lalevée > >> 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 >>> 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 >> >>
Re: Creation of a new ivy resolver
Thank you for your time, I've answered in your mail. -- Adrien 2012/8/7 Nicolas Lalevée > 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 > > > >> 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
Re: Creation of a new ivy resolver
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 > >> 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
Re: Creation of a new ivy resolver
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 > 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 > >
Re: Creation of a new ivy resolver
Reply to Ant Developers List From: Nicolas Lalevée To: Ant Developers List Sent: Friday, May 25, 2012 10:33 AM Subject: Re: Creation of a new ivy resolver 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
Re: Creation of a new ivy resolver
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
Creation of a new ivy resolver
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
