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  with  does not spot bad symlin|
|15149|New|Enh|2002-12-06|Replace task  |
|15244|New|Enh|2002-12-10|tar task should be able to store symbolic links as|
|15430|New|Enh|2002-12-17|Enhancement to ReplaceRegExp.java |
|15596|New|Enh|2002-12-21|Identity mapper in uptodate task. |
|15747|New|Enh|2003-01-01|change tasks (e.g. Ant) to take urls as well as fi|
|15853|New|Enh|2003-01-07|Allow to plug-in different XML Catalog resolver in|
|15949|Opn|Enh|2003-01-10|please provide links to docs.xml and jakarta-site2|
|16131|New|Enh|2003-01-15|not possible to suppress "BUILD SUCCESSFUL" messag|
|16427|New|Enh|2003-01-26|Output return value of setLastModified/document be|
|16469|New|Enh|2003-01-27|Apply task should allow parallel execution on diff|
|16494|New|Enh|2003-01-28|[PATCH] accessibility of Ant documentation|
|16562|New|Enh|2003-01-29|Can not accept characters  from keyboard in a thre|
|16860|New|Enh|2003-02-06|Silent or Debug a single target   |
|16896|New|Enh|2003-02-07|Support in ProjectHelper / ProjectHelperImpl to op|
|17074|New|Enh|2003-02-14|Contribution for WLSTOP   |
|17181|New|Nor|2003-02-18|Build fails while trying to get VSS files by label|
|17372|New|Enh|2003-02-25|Enhancement of replace Task   |
|17742|New|Maj|2003-03-06|PVCS task generates GET with promotion group incor|
|17781|New|Enh|2003-03-07|name attribute of record task is not relative to b|
|17829|New|Enh|2003-03-10|Allow ejbjar task to accept nested manifest   |
|17850|New|Nor|2003-03-10|PVCS task dont work with promotion group  |

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

2017-05-21 Thread jaikiran
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



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

2017-05-21 Thread jaikiran
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



Ivy - Goals for the upcoming release?

2017-05-21 Thread J Pai
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 - Goals for the upcoming release?

2017-05-21 Thread 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



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

2017-05-21 Thread jaikiran
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



[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 issue #20: Fix IVY-1522

2017-05-21 Thread jaikiran
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



Re: Ivy - Buildjobs/PreCommit

2017-05-21 Thread Nicolas Lalevée

> 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



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
>
>


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

2017-05-21 Thread asfgit
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 Nicolas Lalevée

> 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?

2017-05-21 Thread Nicolas Lalevée

> 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?

2017-05-21 Thread Nicolas Lalevée
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
> 



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

2017-05-21 Thread asfgit
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



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

2017-05-21 Thread asfgit
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 #23: Use the specified timeout for connections in Basic...

2017-05-21 Thread asfgit
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 #3: Lets ssh-based resolvers use an ~/.ssh/config file ...

2017-05-21 Thread asfgit
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...

2017-05-21 Thread asfgit
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 #5: The default subject is `bintray`, not 'jcenter`

2017-05-21 Thread asfgit
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 #6: Add feature for PomModuleDescriptorParser disabled ...

2017-05-21 Thread asfgit
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 #4: Optimization: limit the revision numbers scanned if...

2017-05-21 Thread asfgit
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



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


Re: Ivy - Goals for the upcoming release?

2017-05-21 Thread J Pai
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 and 
>> plan to send a couple more for similar upgrades. My intention is to use the 

Re: Ivy - Goals for the upcoming release?

2017-05-21 Thread J Pai
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 issues that we probably should look into (doesn’t 
>> necessarily mean fix all of them, but just to check if a

AW: Ivy - Buildjobs/PreCommit

2017-05-21 Thread jhm
I'll try setting up the PreCommit-Job as Matrix job with Linux/Window.

Jan



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



AW: Ivy - Buildjobs/PreCommit

2017-05-21 Thread jhm
> > On a related note, while we are at this - does Apache infra allow the
> jobs to be run against Windows OS Jenkins agents as well? There are a
> few issues specifically reported against Windows OS and having the job
> run against linux and Windows OS should give a decent coverage for the
> upstream code.
> 
> In Jenkins there is the concept of « Matrix » job.
> Here is the ones for Ant:
> https://builds.apache.org/view/A/view/Ant/job/Ant-Build-Matrix-1.9.x-
> Windows/  Matrix-1.9.x-Windows/>
> https://builds.apache.org/view/A/view/Ant/job/Ant-Build-Matrix-1.9.x-
> Linux/  1.9.x-Linux/>
> AFAIR, it used to be able to do on several different OS. I don’t know
> why they are split.
> 
> And I don’t know if it is possible to do it while pulling a PR from
> github.


New buildjob "Ivy-GithubPR-Matrix". I deactivated the old (so we could easily 
switch back).
https://builds.apache.org/view/A/view/Ant/job/Ivy-GithubPR-Matrix/
Basically a copy of the old job:
* discard old build jobs (keep 10)
* git merge support: fail the build if push fails
* github project: git://github.com/apache/ant-ivy.git
* git
  -- repository: git://github.com/apache/ant-ivy.git
  -- branches: */master (= default)
  -- clean before checkout
  -- recursively update submodules
  -- build commits submitted for validated merge (= PR support)
* start build: build pull request to the repository (= PR support)
* configuration matrix
  -- JDK: JDK 1.7 (latest), JDK 1.8 (latest), JDK 9 b156 with jigsaw
  -- os: label expression = ["ubuntu", "Windows"]
* abort the build if it's stuck: absolute 20 minutes
* Lock: Ant
* build
  -- ant(standard): clean coverage-report
* publish junit: build/test-report/**


Jan


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