date:20170521

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:

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:

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 against this resolution, for conf1. 
What I would expect is, that it would deliver a file for hello-world which then 
has a dependency on org:module1:1.0 in conf1 (because that’s what it was 
correctly resolved to previously). However, the delivered file instead has a 
dependency on org:module1:2.0 in conf1 and I believe that’s the issue being 
reported in that JIRA.

So is this a bug in the deliver task itself? I don’t think so. So far what I 
have narrowed it down to is that the resolve task that happened previously 
creates more than one representation of that resolution (one a resolution 
report xml and one a resolution properties file). The resolution report XML has 
all the necessary and correct information about which dependency (either direct 
or transitive) belongs to which configuration. However, the resolution 
properties file contains the “wrong” dependency for module1 - it stores the 
dependency as org:module1:2.0. I am not even sure if the properties file is 
capable enough of supporting/understanding dependencies per configuration. The 
deliver task then uses this properties file (instead of the resolution report 
XML) to decide what dependencies to write out. I’m guessing some other 
(post-resolve) tasks too use this properties file for their decision making, so 
this really boils down to a potential bug in what gets written out to this 
resolution properties file, during resolve.

Unfortunately, my reading of the code so far hasn’t given me answers on what 
role this file plays and why can’t it be just skipped and the resolution report 
XML instead be considered the single source of truth. Hence that question [2] 
in the dev list. I can’t really think of a solution/fix for this issue, without 
reading more of the current Ivy code to understand what role these files play.

[1] 
https://github.com/jaikiran/ant-ivy/commit/529a3fa05ed5dd115bdf8046d0cf0ffe034905e0#diff-6ed8218b6bb9460014cf3558ff227172R571
[2] https://www.mail-archive.com/dev@ant.apache.org/msg45402.html

-Jaikiran

On 21-May-2017, at 10:49 PM, Nicolas Lalevée  wrote:

One thing though.

This revival of the community has been triggered by the comments on this issue:
https://issues.apache.org/jira/browse/IVY-1485 

It would be a shame if it is not fixed within the next release.

The issue and the fix are not easy to understand. Any review will be welcomed.

Nicolas

> Le 21 mai 2017 à 18:46, Nicolas Lalevée  a écrit :
> 
> 
>> Le 21 mai 2017 à 16:28, J Pai  a écrit :
>> 
>> The past few days I’ve sent some PRs for bug fixes and some enhancements in 
>> preparation for the proposed release of Ivy. Thanks Nicolas for reviewing 
>> them and merging those that were good enough. 
>> 
>> I’ve been using this JIRA filter [1] to narrow down on the issues to look 
>> into. That filter essentially is of “open issues that affect 2.1.0, 2.2.0, 
>> 2.3.0 or 2.4.0 and have been updated/created since Jan 1st 2014”. So it 
>> should cover most of the

Re: Ivy - Goals for the upcoming release?

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:

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:

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 against this resolution, for conf1. 
What I would expect is, that it would deliver a file for hello-world which then 
has a dependency on org:module1:1.0 in conf1 (because that’s what it was 
correctly resolved to previously). However, the delivered file instead has a 
dependency on org:module1:2.0 in conf1 and I believe that’s the issue being 
reported in that JIRA.

So is this a bug in the deliver task itself? I don’t think so. So far what I 
have narrowed it down to is that the resolve task that happened previously 
creates more than one representation of that resolution (one a resolution 
report xml and one a resolution properties file). The resolution report XML has 
all the necessary and correct information about which dependency (either direct 
or transitive) belongs to which configuration. However, the resolution 
properties file contains the “wrong” dependency for module1 - it stores the 
dependency as org:module1:2.0. I am not even sure if the properties file is 
capable enough of supporting/understanding dependencies per configuration. The 
deliver task then uses this properties file (instead of the resolution report 
XML) to decide what dependencies to write out. I’m guessing some other 
(post-resolve) tasks too use this properties file for their decision making, so 
this really boils down to a potential bug in what gets written out to this 
resolution properties file, during resolve.

Unfortunately, my reading of the code so far hasn’t given me answers on what 
role this file plays and why can’t it be just skipped and the resolution report 
XML instead be considered the single source of truth. Hence that question [2] 
in the dev list. I can’t really think of a solution/fix for this issue, without 
reading more of the current Ivy code to understand what role these files play.

[1] 
https://github.com/jaikiran/ant-ivy/commit/529a3fa05ed5dd115bdf8046d0cf0ffe034905e0#diff-6ed8218b6bb9460014cf3558ff227172R571
[2] https://www.mail-archive.com/dev@ant.apache.org/msg45402.html

-Jaikiran

On 21-May-2017, at 10:49 PM, Nicolas Lalevée  wrote:

One thing though.

This revival of the community has been triggered by the comments on this issue:
https://issues.apache.org/jira/browse/IVY-1485 

It would be a shame if it is not fixed within the next release.

The issue and the fix are not easy to understand. Any review will be welcomed.

Nicolas

> Le 21 mai 2017 à 18:46, Nicolas Lalevée  a écrit :
> 
> 
>> Le 21 mai 2017 à 16:28, J Pai  a écrit :
>> 
>> The past few days I’ve sent some PRs for bug fixes and some enhancements in 
>> preparation for the proposed release of Ivy. Thanks Nicolas for reviewing 
>> them and merging those that were good enough. 
>> 
>> I’ve been using this JIRA filter [1] to narrow down on the issues to look 
>> into. That filter essentially is of “open issues that affect 2.1.0, 2.2.0, 
>> 2.3.0 or 2.4.0 and have been updated/created since Jan 1st 2014”. So it 
>> should cover most of the issues that we probably should look into (doesn’t 
>> necessarily mean fix all of them, but just to check if any of them are big 
>> enough to focus on).
>> 
>> I’ve also sent one PR for upgrading our internal library dependencies

Re: Ivy - Goals for the upcoming release?

2017-05-21 Thread Gintautas Grigelionis

2017-05-21 19:00 GMT+02:00 Nicolas Lalevée :

>
> I don’t want to break your enthusiasm, but we should try to keep the API
> as stable as possible. I know the API is very wide, a lot is exposed, but
> we should be really careful at not breaking downside projects
>

I think generics in IvyDE is not a big deal. I dived into Ivy because of
some inconsistencies (Map vs Properties), and I'm not very enthusiastic
about it... no ETA at this point. Maybe a branch after 2.5.0...


> > As for IvyDE, I was looking into getting rid of any deprecations and
> fixing
> > the build.xml so that the dependencies can be retrieved by Ivy from
> Eclipse
> > update sites. However, the honour of getting the current builds to work
> > goes to Nicolas.
>
> Any contribution to upgrade the dependencies of IvyDE is welcomed. For
> instance, I don’t even know if a PDE build can still be done with Eclipse 4.
>
> Also, if some dependencies are too hard to get, like the GEF and Zest, we
> could get rid of them by stopping to support the « resolve visualizer ».
> And it could be decided that it is not abandoned but just temporarily
> disabled until someone find a way to correctly build it.
>
> PDE is available, the drops are not, but the dependencies are not a
problem by themselves. I almost made Equinox to do the job, but the
incantations look pretty terrifying on the command line already and then
they must be wrapped in Ant exec... While researching it I saw discussions
about using Maven with Eclipse components, but updatesite resolver looks
like the cleanest approach.

Gintas

[GitHub] ant-ivy pull request #4: Optimization: limit the revision numbers scanned if...

Github user asfgit closed the pull request at:

https://github.com/apache/ant-ivy/pull/4


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[GitHub] ant-ivy pull request #6: Add feature for PomModuleDescriptorParser disabled ...

Github user asfgit closed the pull request at:

https://github.com/apache/ant-ivy/pull/6


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[GitHub] ant-ivy pull request #5: The default subject is `bintray`, not 'jcenter`

Github user asfgit closed the pull request at:

https://github.com/apache/ant-ivy/pull/5


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[GitHub] ant-ivy pull request #3: Lets ssh-based resolvers use an ~/.ssh/config file ...

Github user asfgit closed the pull request at:

https://github.com/apache/ant-ivy/pull/3


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[GitHub] ant-ivy pull request #2: IVY-1491 create POM with /xsd/maven-4.0.0.xsd schem...

Github user asfgit closed the pull request at:

https://github.com/apache/ant-ivy/pull/2


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[GitHub] ant-ivy pull request #23: Use the specified timeout for connections in Basic...

Github user asfgit closed the pull request at:

https://github.com/apache/ant-ivy/pull/23


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[GitHub] ant-ivy pull request #19: IVY-1554 - Add (conditional) support for SHA-256 S...

Github user asfgit closed the pull request at:

https://github.com/apache/ant-ivy/pull/19


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[GitHub] ant-ivy pull request #25: Upgrade to latest Ant release (non-Java 8 one)

Github user asfgit closed the pull request at:

https://github.com/apache/ant-ivy/pull/25


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ivy - Goals for the upcoming release?

One thing though.

This revival of the community has been triggered by the comments on this issue:
https://issues.apache.org/jira/browse/IVY-1485 

It would be a shame if it is not fixed within the next release.

The issue and the fix are not easy to understand. Any review will be welcomed.

Nicolas

> Le 21 mai 2017 à 18:46, Nicolas Lalevée  a écrit :
> 
> 
>> Le 21 mai 2017 à 16:28, J Pai  a écrit :
>> 
>> The past few days I’ve sent some PRs for bug fixes and some enhancements in 
>> preparation for the proposed release of Ivy. Thanks Nicolas for reviewing 
>> them and merging those that were good enough. 
>> 
>> I’ve been using this JIRA filter [1] to narrow down on the issues to look 
>> into. That filter essentially is of “open issues that affect 2.1.0, 2.2.0, 
>> 2.3.0 or 2.4.0 and have been updated/created since Jan 1st 2014”. So it 
>> should cover most of the issues that we probably should look into (doesn’t 
>> necessarily mean fix all of them, but just to check if any of them are big 
>> enough to focus on).
>> 
>> I’ve also sent one PR for upgrading our internal library dependencies and 
>> plan to send a couple more for similar upgrades. My intention is to use the 
>> latest released versions of these dependencies instead of sticking with 
>> dependencies that are years old. My intention _isn’t_ to upgrade to a 
>> version that isn’t API backward compatible, so these upgrades are mostly bug 
>> fixes and should be “drop-in upgrades”. 
>> 
>> I would be really glad to hear any thoughts about these changes or any 
>> other/different plans, that can get us to a releasable state in the near 
>> future, especially from members/users who have been involved with Ant/Ivy 
>> project in the past or present. Ultimately, I think if we can agree on a 
>> goal for the upcoming release, it will help release something that will set 
>> the right expectation with the end users when it comes to using it. My 
>> opinion is that we consider this release to push out some bug fixes and 
>> internal upgrades and _not_ introduce any major features unless those are 
>> reasonably quick to implement. Once this release is done and (hopefully some 
>> of the) community gets back behind the Ivy project, we can always introduce 
>> major features in subsequent releases.
> 
> Sounds like a good plan.
> 
> Nicolas
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>

Re: Ivy - Goals for the upcoming release?


> Le 21 mai 2017 à 18:34, Gintautas Grigelionis  a 
> écrit :
> 
> Now that Ant is upgraded, I suggest converting tests to JUnit 4 (which
> requires at least Ant 1.9.5, if I'm not mistaken). I can submit a patch
> pretty soon.
> 
> Introducing generics throughout (hey, that's a Java 5 feature!) would make
> the code easier to read (I've seen incorrect comments of what goes into a
> Map somewhere in the code). Unfortunately, in Ivy's case that requires even
> some changes in the API (can't have arrays of generics) and a few other
> design problems.

I don’t want to break your enthusiasm, but we should try to keep the API as 
stable as possible. I know the API is very wide, a lot is exposed, but we 
should be really careful at not breaking downside projects.

Also, PR are starting to pill up thanks to the good work of Jaikiran, so if 
there is big code change like adding a lot of generic in the code, it would be 
nice to wait a little bit so that merges will be easier.

> As for IvyDE, I was looking into getting rid of any deprecations and fixing
> the build.xml so that the dependencies can be retrieved by Ivy from Eclipse
> update sites. However, the honour of getting the current builds to work
> goes to Nicolas.

Any contribution to upgrade the dependencies of IvyDE is welcomed. For 
instance, I don’t even know if a PDE build can still be done with Eclipse 4.

Also, if some dependencies are too hard to get, like the GEF and Zest, we could 
get rid of them by stopping to support the « resolve visualizer ». And it could 
be decided that it is not abandoned but just temporarily disabled until someone 
find a way to correctly build it.

Nicolas

> 
> Gintas
> 
> 2017-05-21 16:41 GMT+02:00 J Pai :
> 
>> One thing I forgot to note is that we need to do a similar thing for
>> IvyDE. I haven’t looked at the JIRA issues for that project [1] and am not
>> familiar with Eclipse in general. So someone more familiar with it would
>> have to look into those. Having said that, Gintas has helped with getting
>> the IvyDE project itself come to life recently, so I guess we can target to
>> do something similar in terms of release goals, for that project too.
>> 
>> -Jaikiran
>> 
>> 
>> [1] https://issues.apache.org/jira/browse/IVYDE
>> On 21-May-2017, at 7:58 PM, J Pai  wrote:
>> 
>> The past few days I’ve sent some PRs for bug fixes and some enhancements
>> in preparation for the proposed release of Ivy. Thanks Nicolas for
>> reviewing them and merging those that were good enough.
>> 
>> I’ve been using this JIRA filter [1] to narrow down on the issues to look
>> into. That filter essentially is of “open issues that affect 2.1.0, 2.2.0,
>> 2.3.0 or 2.4.0 and have been updated/created since Jan 1st 2014”. So it
>> should cover most of the issues that we probably should look into (doesn’t
>> necessarily mean fix all of them, but just to check if any of them are big
>> enough to focus on).
>> 
>> I’ve also sent one PR for upgrading our internal library dependencies and
>> plan to send a couple more for similar upgrades. My intention is to use the
>> latest released versions of these dependencies instead of sticking with
>> dependencies that are years old. My intention _isn’t_ to upgrade to a
>> version that isn’t API backward compatible, so these upgrades are mostly
>> bug fixes and should be “drop-in upgrades”.
>> 
>> I would be really glad to hear any thoughts about these changes or any
>> other/different plans, that can get us to a releasable state in the near
>> future, especially from members/users who have been involved with Ant/Ivy
>> project in the past or present. Ultimately, I think if we can agree on a
>> goal for the upcoming release, it will help release something that will set
>> the right expectation with the end users when it comes to using it. My
>> opinion is that we consider this release to push out some bug fixes and
>> internal upgrades and _not_ introduce any major features unless those are
>> reasonably quick to implement. Once this release is done and (hopefully
>> some of the) community gets back behind the Ivy project, we can always
>> introduce major features in subsequent releases.
>> 
>> 
>> [1] https://issues.apache.org/jira/issues/?jql=project%20%3D%
>> 20IVY%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%
>> 2C%20Reopened)%20AND%20affectedVersion%20in%20(2.1.0%2C%202.
>> 2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%20AND%20updated%
>> 20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC
>> 
>> -Jaikiran
>> 
>> 
>> -
>> 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: Ivy - Goals for the upcoming release?


> Le 21 mai 2017 à 16:28, J Pai  a écrit :
> 
> The past few days I’ve sent some PRs for bug fixes and some enhancements in 
> preparation for the proposed release of Ivy. Thanks Nicolas for reviewing 
> them and merging those that were good enough. 
> 
> I’ve been using this JIRA filter [1] to narrow down on the issues to look 
> into. That filter essentially is of “open issues that affect 2.1.0, 2.2.0, 
> 2.3.0 or 2.4.0 and have been updated/created since Jan 1st 2014”. So it 
> should cover most of the issues that we probably should look into (doesn’t 
> necessarily mean fix all of them, but just to check if any of them are big 
> enough to focus on).
> 
> I’ve also sent one PR for upgrading our internal library dependencies and 
> plan to send a couple more for similar upgrades. My intention is to use the 
> latest released versions of these dependencies instead of sticking with 
> dependencies that are years old. My intention _isn’t_ to upgrade to a version 
> that isn’t API backward compatible, so these upgrades are mostly bug fixes 
> and should be “drop-in upgrades”. 
> 
> I would be really glad to hear any thoughts about these changes or any 
> other/different plans, that can get us to a releasable state in the near 
> future, especially from members/users who have been involved with Ant/Ivy 
> project in the past or present. Ultimately, I think if we can agree on a goal 
> for the upcoming release, it will help release something that will set the 
> right expectation with the end users when it comes to using it. My opinion is 
> that we consider this release to push out some bug fixes and internal 
> upgrades and _not_ introduce any major features unless those are reasonably 
> quick to implement. Once this release is done and (hopefully some of the) 
> community gets back behind the Ivy project, we can always introduce major 
> features in subsequent releases.

Sounds like a good plan.

Nicolas


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[GitHub] ant-ivy pull request #26: Upgrade to latest JSCH versions

Github user asfgit closed the pull request at:

https://github.com/apache/ant-ivy/pull/26


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ivy - Goals for the upcoming release?

2017-05-21 Thread Gintautas Grigelionis

Now that Ant is upgraded, I suggest converting tests to JUnit 4 (which
requires at least Ant 1.9.5, if I'm not mistaken). I can submit a patch
pretty soon.

Introducing generics throughout (hey, that's a Java 5 feature!) would make
the code easier to read (I've seen incorrect comments of what goes into a
Map somewhere in the code). Unfortunately, in Ivy's case that requires even
some changes in the API (can't have arrays of generics) and a few other
design problems.

As for IvyDE, I was looking into getting rid of any deprecations and fixing
the build.xml so that the dependencies can be retrieved by Ivy from Eclipse
update sites. However, the honour of getting the current builds to work
goes to Nicolas.

Gintas

2017-05-21 16:41 GMT+02:00 J Pai :

> One thing I forgot to note is that we need to do a similar thing for
> IvyDE. I haven’t looked at the JIRA issues for that project [1] and am not
> familiar with Eclipse in general. So someone more familiar with it would
> have to look into those. Having said that, Gintas has helped with getting
> the IvyDE project itself come to life recently, so I guess we can target to
> do something similar in terms of release goals, for that project too.
>
> -Jaikiran
>
>
> [1] https://issues.apache.org/jira/browse/IVYDE
> On 21-May-2017, at 7:58 PM, J Pai  wrote:
>
> The past few days I’ve sent some PRs for bug fixes and some enhancements
> in preparation for the proposed release of Ivy. Thanks Nicolas for
> reviewing them and merging those that were good enough.
>
> I’ve been using this JIRA filter [1] to narrow down on the issues to look
> into. That filter essentially is of “open issues that affect 2.1.0, 2.2.0,
> 2.3.0 or 2.4.0 and have been updated/created since Jan 1st 2014”. So it
> should cover most of the issues that we probably should look into (doesn’t
> necessarily mean fix all of them, but just to check if any of them are big
> enough to focus on).
>
> I’ve also sent one PR for upgrading our internal library dependencies and
> plan to send a couple more for similar upgrades. My intention is to use the
> latest released versions of these dependencies instead of sticking with
> dependencies that are years old. My intention _isn’t_ to upgrade to a
> version that isn’t API backward compatible, so these upgrades are mostly
> bug fixes and should be “drop-in upgrades”.
>
> I would be really glad to hear any thoughts about these changes or any
> other/different plans, that can get us to a releasable state in the near
> future, especially from members/users who have been involved with Ant/Ivy
> project in the past or present. Ultimately, I think if we can agree on a
> goal for the upcoming release, it will help release something that will set
> the right expectation with the end users when it comes to using it. My
> opinion is that we consider this release to push out some bug fixes and
> internal upgrades and _not_ introduce any major features unless those are
> reasonably quick to implement. Once this release is done and (hopefully
> some of the) community gets back behind the Ivy project, we can always
> introduce major features in subsequent releases.
>
>
> [1] https://issues.apache.org/jira/issues/?jql=project%20%3D%
> 20IVY%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%
> 2C%20Reopened)%20AND%20affectedVersion%20in%20(2.1.0%2C%202.
> 2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%20AND%20updated%
> 20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC
>
> -Jaikiran
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Ivy - Buildjobs/PreCommit


> Le 20 mai 2017 à 11:18, Nicolas Lalevée  a écrit :
> 
> 
>> Le 20 mai 2017 à 04:45, J Pai  a écrit :
>> 
>> This pre-commit job is now almost functional. It gets triggered whenever 
>> there’s a PR and runs the build and tests and reports back if there are any 
>> failures.
>> 
>> However, the only thing that’s pending or seems to be an issue is it 
>> sometimes doesn’t report back with the status. In these 2 PRs 
>> https://github.com/apache/ant-ivy/pull/19 
>> https://github.com/apache/ant-ivy/pull/20 the status was never reported back 
>> to github (one of the jobs succeeded and the other failed, so there isn’t a 
>> clear hint of when this happens).
> 
> I have seen that. In the config I didn’t see any obvious option that fix that.

Seems to be working now. At least for that PR:
https://github.com/apache/ant-ivy/pull/26 


That’s awesome!

Nicolas

[GitHub] ant-ivy issue #20: Fix IVY-1522

Github user jaikiran commented on the issue:

https://github.com/apache/ant-ivy/pull/20
  
>> So @jaikiran, would you consider rewrite the unit test to just test 
FileUtil.dissect ?

Yes, certainly. I will update this PR with the testcase tomorrow.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[GitHub] ant-ivy issue #20: Fix IVY-1522

2017-05-21 Thread nlalevee

Github user nlalevee commented on the issue:

https://github.com/apache/ant-ivy/pull/20
  
So let's get out of scope of this PR the support of weird characters in 
version, organisation or module name. Especially since the set of supported 
characters depends on the filesystem, which is usually tied to an OS but is not 
a strictly good indicator.

So @jaikiran, would you consider rewrite the unit test to just test 
FileUtil.dissect ?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[GitHub] ant-ivy pull request #26: Upgrade to latest JSCH versions

GitHub user jaikiran opened a pull request:

https://github.com/apache/ant-ivy/pull/26

Upgrade to latest JSCH versions

The commit here upgrades the `jsch` library dependencies to the latest 
released versions.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jaikiran/ant-ivy jsch-upgrade

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ant-ivy/pull/26.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 #26


commit f31c00d8e7c95468540270f2e03e435987bb81d2
Author: Jaikiran Pai 
Date:   2017-05-21T10:37:03Z

Upgrade to latest JSCH versions




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ivy - Goals for the upcoming release?

One thing I forgot to note is that we need to do a similar thing for IvyDE. I
haven’t looked at the JIRA issues for that project [1] and am not familiar with
Eclipse in general. So someone more familiar with it would have to look into
those. Having said that, Gintas has helped with getting the IvyDE project
itself come to life recently, so I guess we can target to do something similar
in terms of release goals, for that project too.

-Jaikiran

[1] https://issues.apache.org/jira/browse/IVYDE
On 21-May-2017, at 7:58 PM, J Pai wrote:

The past few days I’ve sent some PRs for bug fixes and some enhancements in
preparation for the proposed release of Ivy. Thanks Nicolas for reviewing them
and merging those that were good enough.

I’ve been using this JIRA filter [1] to narrow down on the issues to look into.
That filter essentially is of “open issues that affect 2.1.0, 2.2.0, 2.3.0 or
2.4.0 and have been updated/created since Jan 1st 2014”. So it should cover
most of the issues that we probably should look into (doesn’t necessarily mean
fix all of them, but just to check if any of them are big enough to focus on).

I’ve also sent one PR for upgrading our internal library dependencies and plan
to send a couple more for similar upgrades. My intention is to use the latest
released versions of these dependencies instead of sticking with dependencies
that are years old. My intention _isn’t_ to upgrade to a version that isn’t API
backward compatible, so these upgrades are mostly bug fixes and should be
“drop-in upgrades”.

I would be really glad to hear any thoughts about these changes or any
other/different plans, that can get us to a releasable state in the near
future, especially from members/users who have been involved with Ant/Ivy
project in the past or present. Ultimately, I think if we can agree on a goal
for the upcoming release, it will help release something that will set the
right expectation with the end users when it comes to using it. My opinion is
that we consider this release to push out some bug fixes and internal upgrades
and _not_ introduce any major features unless those are reasonably quick to
implement. Once this release is done and (hopefully some of the) community gets
back behind the Ivy project, we can always introduce major features in
subsequent releases.

[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20IVY%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in%20(2.1.0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%20AND%20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC

-Jaikiran

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Ivy - Goals for the upcoming release?

The past few days I’ve sent some PRs for bug fixes and some enhancements in
preparation for the proposed release of Ivy. Thanks Nicolas for reviewing them
and merging those that were good enough.

-Jaikiran
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[GitHub] ant-ivy pull request #25: Upgrade to latest Ant release (non-Java 8 one)

GitHub user jaikiran opened a pull request:

https://github.com/apache/ant-ivy/pull/25

Upgrade to latest Ant release (non-Java 8 one)

The commit here upgrades the Ant dependencies to the latest released ones.

A few notes about the dependencies:

- `org.apache.ant:ant-trax` dependency has been removed since it's no 
longer relevant as per the Ant release notes here[1]
>> ant-trax.jar is no longer produced since TrAX is included in JDK 1.4+.

- `org.apache.ant:ant-nodeps` dependency has been removed since that 
artifact is no longer relevant and is available as part of the core Ant 
dependency as per the release notes here[2]
>> Removed ant-nodeps.jar; it is now merged into ant.jar.

- Co-ordinates of `ant:ant-launcher` have now changed to 
`org.apache.ant:ant-launcher`

[1] https://archive.apache.org/dist/ant/RELEASE-NOTES-apache-ant-1.8.1.html
[2] https://archive.apache.org/dist/ant/RELEASE-NOTES-apache-ant-1.8.2.html

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jaikiran/ant-ivy ant-upgrade

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ant-ivy/pull/25.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 #25


commit 4cd96fd67c9c6063d9a95aad43415ea794ec7a3e
Author: Jaikiran Pai 
Date:   2017-05-21T13:47:15Z

Upgrade to latest Ant release (non-Java 8 one)




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[GitHub] ant-ivy pull request #24: Fix IVY-1555

GitHub user jaikiran opened a pull request:

https://github.com/apache/ant-ivy/pull/24

Fix IVY-1555

The commit here includes a fix and test case for the issue reported in 
https://issues.apache.org/jira/browse/IVY-1555 where the absence of a 
`optional` settings file included in another file, errors out the build.

The commit in this PR, takes into account the `optional` attribute value 
before deciding whether or not to cause the `IOException` to error out or be 
ignored (with a verbose log message).


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jaikiran/ant-ivy ivy-1555

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ant-ivy/pull/24.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 #24


commit ce551f6e92679fca04ef4c3f66950e0959426228
Author: Jaikiran Pai 
Date:   2017-05-21T12:01:47Z

IVY-1555 Don't error out if an "optional" file included in ivy settings xml 
isn't available




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Bug report for Ant [2017/05/21]

2017-05-21 Thread bugzilla

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
| 5003|Opn|Blk|2001-11-21|exec task does not return after executed command f|
| 6606|Opn|Enh|2002-02-21|META-BUG problems with delegating classloaders|
| 7552|Opn|Cri|2002-03-28|Invalid task cache in targets |
| 7712|New|Enh|2002-04-03|Provide patternset support for VSSGET task?   |
| 8294|New|Enh|2002-04-19|: Allow  and  to app|
| 8866|New|Enh|2002-05-07|Signal handling in java task  |
| 8895|New|Enh|2002-05-08|ant and/or antcall should support forking |
| 8972|New|Enh|2002-05-10|allow property expansion in  property v|
| 8981|New|Enh|2002-05-10|Tar task command additional features  |
| 9294|New|Enh|2002-05-21|[PATCH] optional/j2ee/ServerDeploy OC4J Support   |
| 9995|Ass|Enh|2002-06-19|MKS Source Integrity tasks|
|10020|New|Enh|2002-06-19|'s dependency behaviour should be more con|
|10231|New|Enh|2002-06-25|Need access to current file in SQLExec|
|10283|New|Enh|2002-06-27|Add a destfile to the uptodate task   |
|10402|New|Enh|2002-07-02|adding the ability of html like whitespace preserv|
|3|New|Enh|2002-07-24|keytool task  |
|11560|Opn|Enh|2002-08-08|Taskdef does not apply reverseLoader policy on sta|
|12267|New|Enh|2002-09-03|Add ability to unzip into separate folders|
|12292|New|Enh|2002-09-04|[PATCH] enable  tag inside tar|
|12334|New|Enh|2002-09-05|REQUEST: Ant task doesn't allow attachment of a bu|
|12518|New|Enh|2002-09-11|Gunzip & BUnZip2 add filesets, patternsets, and ov|
|12765|New|Enh|2002-09-18|"rmdir" and "deltree" patches for ftp task enhance|
|12964|New|Enh|2002-09-24|ANTLR only takes one input file at a time |
|13047|Inf|Enh|2002-09-26|Support for  and  on O|
|13371|New|Enh|2002-10-07|[PATCH] Contributed new CvsExportDiff task|
|13847|New|Nor|2002-10-22|pvcs task: wrong option (-r) specified for get (sh|
|13934|New|Enh|2002-10-24|Translate task shouldn't load default locale prope|
|13939|New|Enh|2002-10-24|Translate task should have better key matching cap|
|14320|New|Enh|2002-11-06|copy fileset followsymlinks="false" does not copy |
|14393|New|Enh|2002-11-08|Support use of jndi within ant|
|14512|New|Enh|2002-11-13|Allow creating database connection similar to

[GitHub] ant-ivy issue #20: Fix IVY-1522

2017-05-21 Thread twogee

Github user twogee commented on the issue:

https://github.com/apache/ant-ivy/pull/20
  
On the second thought, if PR changes the way to identify the system root, 
then the test cases should be specifically for that, not for parsing of 
versions with reserved/unsafe URL characters.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[GitHub] ant-ivy issue #20: Fix IVY-1522

2017-05-21 Thread twogee

Github user twogee commented on the issue:

https://github.com/apache/ant-ivy/pull/20
  
"Making something that worked previously on a specific platform in specific 
circumstances work again" is not a good argument, especially when the coverage 
of the test case is incomplete. Unless this worka on Linux, Windows and macOS, 
it deserves Jira status "Won't fix".


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ivy - BasicURLHandler ignoring timeout during connection?