[GitHub] ant-ivy pull request #65: IVY-1485 Ensure dependency is applicable to all co...
Github user twogee closed the pull request at: https://github.com/apache/ant-ivy/pull/65 --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy issue #65: IVY-1485 Ensure dependency is applicable to all configura...
Github user jaikiran commented on the issue: https://github.com/apache/ant-ivy/pull/65 These changes don't solve the real issue. The details of this issue are part of the discussion in ant dev mailing list, where I explained what the real issue is. I do have a completely different code with tests that's not yet ready to be merged. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy issue #65: IVY-1485 Ensure dependency is applicable to all configura...
Github user twogee commented on the issue: https://github.com/apache/ant-ivy/pull/65 @jaikiran please let me know if you did some addition coding, otherwise I hope you would rather focus on JUnit 5 ð --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy pull request #65: IVY-1485 Ensure dependency is applicable to all co...
GitHub user twogee opened a pull request: https://github.com/apache/ant-ivy/pull/65 IVY-1485 Ensure dependency is applicable to all configurations I adopted a patch by @tbingaman You can merge this pull request into a Git repository by running: $ git pull https://github.com/twogee/ant-ivy ivy-1485 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ant-ivy/pull/65.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #65 commit fbac59fbbd6f7c7fa8aa99597f8804211d05bd26 Author: twogee Date: 2018-02-01T13:54:30Z IVY-1485 Ensure dependency is applicable to all configurations --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: IVY-1485
Great! Should I look into documentation-related issues in more detail? Gintas 2017-08-08 6:06 GMT+02:00 Jaikiran Pai : > I'm looking into that JIRA. I'll assigned it to my name now. > > -Jaikiran > > > > On 06/08/17 12:52 PM, Gintautas Grigelionis wrote: > >> I went through JIRA issues and noticed >> https://issues.apache.org/jira/browse/IVY-1485 was discussed relatively >> recently ;-) Anybody looking into it? >> >> Gintas >> >> P.S. JIRA lists about 100 documentation related issues. Should be a low >> hanging fruit... >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
Re: IVY-1485
I'm looking into that JIRA. I'll assigned it to my name now. -Jaikiran On 06/08/17 12:52 PM, Gintautas Grigelionis wrote: I went through JIRA issues and noticed https://issues.apache.org/jira/browse/IVY-1485 was discussed relatively recently ;-) Anybody looking into it? Gintas P.S. JIRA lists about 100 documentation related issues. Should be a low hanging fruit... - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
IVY-1485
I went through JIRA issues and noticed https://issues.apache.org/jira/browse/IVY-1485 was discussed relatively recently ;-) Anybody looking into it? Gintas P.S. JIRA lists about 100 documentation related issues. Should be a low hanging fruit...
Re: IVY-1485, resolve report and resolved versions
> Le 26 mai 2017 à 13:23, J Pai a écrit : > > Thank you very much Nicolas for digging more into this and getting hold of > these details. What you explain, backed by the details, makes clear sense. > > I will attempt to go with this option that you suggest: > >> - drop this property file, make the xml report always produced, and make the >> deliver read the report rather than the property file. > > From looking at the code and documentation, the option that decides whether > to create the XML report seems to be an internal only option (in Ivy 2.x > world) i.e. not exposed or documented as something that the user can fiddle > with. That’s a good thing since removing it or fiddling with its semantics, > won’t affect the users. ha, ok. good then. > P.S: I don’t mean to step on your toes here if you were planning to work on > this. If not, I’ll gladly try and come up with the suggested fix. Please, be my guest. Nicolas > > -Jaikiran > > > On 26-May-2017, at 2:20 PM, Nicolas Lalevée > wrote: > > After some digging, I found out that the resolved revisions property file is > very old (git is awesome, even better within sourcetree). It is so old that > at that time the xml resolve report didn’t exist. And this property file > seems to have been created just in order to make the deliver task work [1]. > And a comment still state this too [2]. And the purpose of the lines from 248 > to 326 are about to compute these versions and write them down, it can be > extracted in a function without side effect. > > So most probably this property file is redundant with the xml resolve report. > But the thing is the resolve may not be produced, it is an option [3], > defaulting to true [4]. > > Two options: > - continue to support the property file and correctly produce it to fix > IVY-1485 [5]. > - drop this property file, make the xml report always produced, and make the > deliver read the report rather than the property file. > > Makes sense ? > > Nicolas > > [1] > https://github.com/apache/ant-ivy/commit/3081a1b16a2fcb13b7a13bf761d6a625598d0325 > > <https://github.com/apache/ant-ivy/commit/3081a1b16a2fcb13b7a13bf761d6a625598d0325> > [2] > https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveEngine.java#L247 > > <https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveEngine.java#L247> > [3] > https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveEngine.java#L338 > > <https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveEngine.java#L338> > [4] > https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveOptions.java#L99 > > <https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveOptions.java#L99> > [5] https://issues.apache.org/jira/browse/IVY-1485 > <https://issues.apache.org/jira/browse/IVY-1485> >> Le 25 mai 2017 à 12:11, Nicolas Lalevée a écrit >> : >> >> Thank you very much Jaikiran for your detailed explanation. >> >> I have to admit that I don’t know the answer to which is the source of truth >> about the resolution report. I have also wondered why the resolve report >> should have to be always wrote and then read from file. I’ll try to get an >> answer myself too while reading the code. >> >> Nicolas >> >>> Le 22 mai 2017 à 07:37, J Pai a écrit : >>> >>> One other thing about this issue - this is reproducible (as shown in the >>> test case) with static revisions too and isn’t specific to any dynamic >>> revision resolution. >>> >>> -Jaikiran >>> On 22-May-2017, at 11:02 AM, J Pai wrote: >>> >>> I have had a look at that issue, this last week and I have been able to >>> reproduce it in a simple test case[1]. I kind of understand what the issue >>> is in there, but given my lack of knowledge of the Ivy codebase, I haven’t >>> been able to figure how to fix this correctly. In fact, this issue is what >>> prompted me to ask this question [2] in the dev list a day or so back, >>> since basically comes down to those files. Here’s my understanding of the >>> problem (backed by that test case[1] which reproduces it). >>> >>> Imagine you have a module org:hello-world and imagine it has 2 >>> configurations conf1 and conf2. Now consider the case where this >>> hello-world module depends on org:module1:1.0 in conf1 (a direct >>> dependency) and on org:module2:1.0
Re: IVY-1485, resolve report and resolved versions
Thank you very much Nicolas for digging more into this and getting hold of these details. What you explain, backed by the details, makes clear sense. I will attempt to go with this option that you suggest: > - drop this property file, make the xml report always produced, and make the > deliver read the report rather than the property file. From looking at the code and documentation, the option that decides whether to create the XML report seems to be an internal only option (in Ivy 2.x world) i.e. not exposed or documented as something that the user can fiddle with. That’s a good thing since removing it or fiddling with its semantics, won’t affect the users. P.S: I don’t mean to step on your toes here if you were planning to work on this. If not, I’ll gladly try and come up with the suggested fix. -Jaikiran On 26-May-2017, at 2:20 PM, Nicolas Lalevée wrote: After some digging, I found out that the resolved revisions property file is very old (git is awesome, even better within sourcetree). It is so old that at that time the xml resolve report didn’t exist. And this property file seems to have been created just in order to make the deliver task work [1]. And a comment still state this too [2]. And the purpose of the lines from 248 to 326 are about to compute these versions and write them down, it can be extracted in a function without side effect. So most probably this property file is redundant with the xml resolve report. But the thing is the resolve may not be produced, it is an option [3], defaulting to true [4]. Two options: - continue to support the property file and correctly produce it to fix IVY-1485 [5]. - drop this property file, make the xml report always produced, and make the deliver read the report rather than the property file. Makes sense ? Nicolas [1] https://github.com/apache/ant-ivy/commit/3081a1b16a2fcb13b7a13bf761d6a625598d0325 <https://github.com/apache/ant-ivy/commit/3081a1b16a2fcb13b7a13bf761d6a625598d0325> [2] https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveEngine.java#L247 <https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveEngine.java#L247> [3] https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveEngine.java#L338 <https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveEngine.java#L338> [4] https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveOptions.java#L99 <https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveOptions.java#L99> [5] https://issues.apache.org/jira/browse/IVY-1485 <https://issues.apache.org/jira/browse/IVY-1485> > Le 25 mai 2017 à 12:11, Nicolas Lalevée a écrit : > > Thank you very much Jaikiran for your detailed explanation. > > I have to admit that I don’t know the answer to which is the source of truth > about the resolution report. I have also wondered why the resolve report > should have to be always wrote and then read from file. I’ll try to get an > answer myself too while reading the code. > > Nicolas > >> Le 22 mai 2017 à 07:37, J Pai a écrit : >> >> One other thing about this issue - this is reproducible (as shown in the >> test case) with static revisions too and isn’t specific to any dynamic >> revision resolution. >> >> -Jaikiran >> On 22-May-2017, at 11:02 AM, J Pai wrote: >> >> I have had a look at that issue, this last week and I have been able to >> reproduce it in a simple test case[1]. I kind of understand what the issue >> is in there, but given my lack of knowledge of the Ivy codebase, I haven’t >> been able to figure how to fix this correctly. In fact, this issue is what >> prompted me to ask this question [2] in the dev list a day or so back, since >> basically comes down to those files. Here’s my understanding of the problem >> (backed by that test case[1] which reproduces it). >> >> Imagine you have a module org:hello-world and imagine it has 2 >> configurations conf1 and conf2. Now consider the case where this hello-world >> module depends on org:module1:1.0 in conf1 (a direct dependency) and on >> org:module2:1.0 in conf2 (a direct dependency). That translates to a module >> descriptor like: >> >> >> > module="hello-world" >> revision="1.2.3" >> >> /> >> >> >> >> >> >> >> >> >> >> >> Now take this one step further and consider that org:module2:1.0 (that >> hello-world depends on, in conf2) has a dependency of its own on >> org:module1:2.0. So module2’s module descriptor
IVY-1485, resolve report and resolved versions
After some digging, I found out that the resolved revisions property file is very old (git is awesome, even better within sourcetree). It is so old that at that time the xml resolve report didn’t exist. And this property file seems to have been created just in order to make the deliver task work [1]. And a comment still state this too [2]. And the purpose of the lines from 248 to 326 are about to compute these versions and write them down, it can be extracted in a function without side effect. So most probably this property file is redundant with the xml resolve report. But the thing is the resolve may not be produced, it is an option [3], defaulting to true [4]. Two options: - continue to support the property file and correctly produce it to fix IVY-1485 [5]. - drop this property file, make the xml report always produced, and make the deliver read the report rather than the property file. Makes sense ? Nicolas [1] https://github.com/apache/ant-ivy/commit/3081a1b16a2fcb13b7a13bf761d6a625598d0325 <https://github.com/apache/ant-ivy/commit/3081a1b16a2fcb13b7a13bf761d6a625598d0325> [2] https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveEngine.java#L247 <https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveEngine.java#L247> [3] https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveEngine.java#L338 <https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveEngine.java#L338> [4] https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveOptions.java#L99 <https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveOptions.java#L99> [5] https://issues.apache.org/jira/browse/IVY-1485 <https://issues.apache.org/jira/browse/IVY-1485> > Le 25 mai 2017 à 12:11, Nicolas Lalevée a écrit : > > Thank you very much Jaikiran for your detailed explanation. > > I have to admit that I don’t know the answer to which is the source of truth > about the resolution report. I have also wondered why the resolve report > should have to be always wrote and then read from file. I’ll try to get an > answer myself too while reading the code. > > Nicolas > >> Le 22 mai 2017 à 07:37, J Pai a écrit : >> >> One other thing about this issue - this is reproducible (as shown in the >> test case) with static revisions too and isn’t specific to any dynamic >> revision resolution. >> >> -Jaikiran >> On 22-May-2017, at 11:02 AM, J Pai wrote: >> >> I have had a look at that issue, this last week and I have been able to >> reproduce it in a simple test case[1]. I kind of understand what the issue >> is in there, but given my lack of knowledge of the Ivy codebase, I haven’t >> been able to figure how to fix this correctly. In fact, this issue is what >> prompted me to ask this question [2] in the dev list a day or so back, since >> basically comes down to those files. Here’s my understanding of the problem >> (backed by that test case[1] which reproduces it). >> >> Imagine you have a module org:hello-world and imagine it has 2 >> configurations conf1 and conf2. Now consider the case where this hello-world >> module depends on org:module1:1.0 in conf1 (a direct dependency) and on >> org:module2:1.0 in conf2 (a direct dependency). That translates to a module >> descriptor like: >> >> >> >module="hello-world" >>revision="1.2.3" >> >> /> >> >> >> >> >> >> >> >> >> >> >> Now take this one step further and consider that org:module2:1.0 (that >> hello-world depends on, in conf2) has a dependency of its own on >> org:module1:2.0. So module2’s module descriptor looks like: >> >> >> > module="module2" >> revision="1.0" >> /> >> >> >> >> >> >> >> >> >> So ultimately, when you resolve the hello-world module, you expect it to >> have org:module1:1.0 as an dependency in conf1 and org:module1:2.0 as an >> dependency in conf2 (transitively via org:module2:1.0). >> >> Does the resolve work as expected for this use case? Yes it does and the >> resolution pulls in the right set of dependencies in the right >> configurations. Internally it creates resolution report (as an xml) plus a >> resolution properties file for this resolution. No (obvious/apparent) issues >> at this point. >> >> Now, let’s say a “deliver” is triggered agai