[GitHub] ant-ivy pull request #65: IVY-1485 Ensure dependency is applicable to all co...

2018-02-06 Thread twogee
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...

2018-02-06 Thread jaikiran
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...

2018-02-01 Thread twogee
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...

2018-02-01 Thread twogee
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 <g.grigelionis@...>
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

2017-08-08 Thread Gintautas Grigelionis
Great! Should I look into documentation-related issues in more detail?

Gintas

2017-08-08 6:06 GMT+02:00 Jaikiran Pai <jai.forums2...@gmail.com>:

> 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

2017-08-07 Thread 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, resolve report and resolved versions

2017-05-26 Thread Nicolas Lalevée

> Le 26 mai 2017 à 13:23, J Pai <jai.forums2...@gmail.com> 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 <nicolas.lale...@hibnet.org> 
> 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 <nicolas.lale...@hibnet.org> 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 <jai.forums2...@gmail.com> 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 <jai.forums2...@gmail.com> 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 conf

Re: IVY-1485, resolve report and resolved versions

2017-05-26 Thread J Pai
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 <nicolas.lale...@hibnet.org> 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 <nicolas.lale...@hibnet.org> 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 <jai.forums2...@gmail.com> 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 <jai.forums2...@gmail.com> 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 (th

IVY-1485, resolve report and resolved versions

2017-05-26 Thread Nicolas Lalevée
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 <nicolas.lale...@hibnet.org> 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 <jai.forums2...@gmail.com> 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 <jai.forums2...@gmail.com> 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/apparen