[GitHub] [ant-ivyde] twogee opened a new pull request #9: Ivy 2.5.0 is available

2020-02-02 Thread GitBox 
twogee opened a new pull request #9: Ivy 2.5.0 is available
URL: https://github.com/apache/ant-ivyde/pull/9
 
 
   Let's start building IvyDE again


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

Re: AW: AW: [VOTE] Release Ivy 2.5.0 based on RC1

2019-10-25 Thread Jaikiran Pai 


On 25/10/19 12:13 PM, Jan Matèrne (jhm) wrote:
>>> Just a question: there is a file fr\jayasoft\ivy\ant\antlib.xml which
>> seems to be a copy of org\apache\ivy\ant\antlib.xml. Is it for BWC?
>> Yes, looks like it.
>> https://github.com/apache/ant-ivy/blob/master/build.xml#L263. It was
>> done way back in 2007 and I don't think anyone uses that reference
>> anymore. After this release, maybe we can stop copying and releasing
>> that file.
>
> Done

Thank you Jan.


>
>>> Hello-Ivy-Example:
>>> - run with "ant -lib ..\..\..\ivy-2.5.0.jar run"
>>> --> Ivy starts
>>> --> Ivy vesion 2.5.0
>>> --> Problems with downloading the dependencies:
>>>
>>> [ivy:retrieve]  found commons-lang#commons-lang;2.6 in public
>>> [ivy:retrieve] You probably access the destination server through a proxy 
>>> server that is not well configured.
>>> Another try:
>>>   ant -lib ..\..\..\ivy-2.5.0.jar -autoproxy run and that worked.
>> I gave this example a try with this released version and it went fine
>> without those warnings or errors. I suspect your Ivy cache probably had
>> already downloaded the metadata/resources previously using some other
>> "resolver"?
> Deleted %userprofile%/.ivy2 and it worked without the -autoproxy.
>
Happy to hear that.

-Jaikiran


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

AW: AW: [VOTE] Release Ivy 2.5.0 based on RC1

2019-10-25 Thread jhm 
> > Just a question: there is a file fr\jayasoft\ivy\ant\antlib.xml which
> seems to be a copy of org\apache\ivy\ant\antlib.xml. Is it for BWC?
> Yes, looks like it.
> https://github.com/apache/ant-ivy/blob/master/build.xml#L263. It was
> done way back in 2007 and I don't think anyone uses that reference
> anymore. After this release, maybe we can stop copying and releasing
> that file.


Done


> >
> > Hello-Ivy-Example:
> > - run with "ant -lib ..\..\..\ivy-2.5.0.jar run"
> > --> Ivy starts
> > --> Ivy vesion 2.5.0
> > --> Problems with downloading the dependencies:
> >
> > [ivy:retrieve]  found commons-lang#commons-lang;2.6 in public
> > [ivy:retrieve] You probably access the destination server through a proxy 
> > server that is not well configured.
> > Another try:
> >   ant -lib ..\..\..\ivy-2.5.0.jar -autoproxy run and that worked.
> 
> I gave this example a try with this released version and it went fine
> without those warnings or errors. I suspect your Ivy cache probably had
> already downloaded the metadata/resources previously using some other
> "resolver"?

Deleted %userprofile%/.ivy2 and it worked without the -autoproxy.


Jan



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

[ANNOUNCE] Apache Ivy 2.5.0 released

2019-10-24 Thread Jaikiran Pai 
The Apache Ivy project is pleased to announce its 2.5.0 release.

Apache Ivy is a tool for managing (recording, tracking, resolving and
reporting) project dependencies, characterized by flexibility,
configurability, and tight integration with Apache Ant.

Key features of this 2.5.0 release are:

    - The minimum runtime Java version required is now Java 7

    - Ivy now uses BouncyCastle OpenPGP API 1.59. Due to the non
backward compatibility of that library, earlier versions are not supported.

    - Ivy now uses HttpComponents HttpClient 4.5.x version with HTTP
backed resolvers. Users are expected to have this version of the library
(and its dependencies) in their runtime classpath if they want to use
such resolvers. The previous (similarly named but not the same)
commons-httpclient library is no longer used or supported.
(https://issues.apache.org/jira/browse/IVY-1563)


Other than this, there have been numerous issues that have been fixed
(since 2.4.0) and some enhancements too. The complete set of changes is
available in release notes here
https://ant.apache.org/ivy/history/2.5.0/release-notes.html

Migration note:

Users moving from 2.5.0-rc1 are highly recommend to use a fresh/new
local Ivy cache directory for this release, to avoid certain issues with
metadata files that might have been cached in the local directory, from
previous version of Ivy.

Issues should be reported to:
https://issues.apache.org/jira/browse/IVY

Download the release at:
https://ant.apache.org/ivy/download.cgi

More information can be found on the Ivy website:
https://ant.apache.org/ivy/

- Jaikiran, on behalf of Apache Ivy team




signature.asc
Description: OpenPGP digital signature

[RESULT] Release Ivy 2.5.0 based on RC1

2019-10-24 Thread Jaikiran Pai 
With +1s from:

Jaikiran Pai

Stefan Bodewig

Jan Matèrne

and no vetos, this vote now passes. I'll initiate the rest of the
process to complete this release process.

Thank you all for voting.

-Jaikiran

On 24/10/19 9:45 AM, Stefan Bodewig wrote:
> +1
>
> Stefan
>
> -
> 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: AW: [VOTE] Release Ivy 2.5.0 based on RC1

2019-10-24 Thread Jaikiran Pai 
Hello Jan,

On 24/10/19 1:31 AM, Jan Matèrne (jhm) wrote:
> Checked the bin.zip.
> Seems to be ok.
>
> Just a question: there is a file fr\jayasoft\ivy\ant\antlib.xml which seems 
> to be a copy of org\apache\ivy\ant\antlib.xml. Is it for BWC?
Yes, looks like it.
https://github.com/apache/ant-ivy/blob/master/build.xml#L263. It was
done way back in 2007 and I don't think anyone uses that reference
anymore. After this release, maybe we can stop copying and releasing
that file.
>
> Hello-Ivy-Example:
> - run with "ant -lib ..\..\..\ivy-2.5.0.jar run"
> --> Ivy starts
> --> Ivy vesion 2.5.0
> --> Problems with downloading the dependencies:
>
> [ivy:retrieve]  found commons-lang#commons-lang;2.6 in public
> [ivy:retrieve] You probably access the destination server through a proxy 
> server that is not well configured.
>
> [ivy:retrieve] :: problems summary ::
> [ivy:retrieve]  WARNINGS
> [ivy:retrieve]  Host repo1.maven.org not found. 
> url=https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.pom
> [ivy:retrieve]  Host repo1.maven.org not found. 
> url=https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.jar
> [ivy:retrieve]  module not found: commons-cli#commons-cli;1.4
> [ivy:retrieve]   local: tried
> [ivy:retrieve]
> C:\Users\Jan\.ivy2\local\commons-cli\commons-cli\1.4\ivys\ivy.xml
> [ivy:retrieve]-- artifact commons-cli#commons-cli;1.4!commons-cli.jar:
> [ivy:retrieve]
> C:\Users\Jan\.ivy2\local\commons-cli\commons-cli\1.4\jars\commons-cli.jar
> [ivy:retrieve]   shared: tried
> [ivy:retrieve]
> C:\Users\Jan\.ivy2\shared\commons-cli\commons-cli\1.4\ivys\ivy.xml
> [ivy:retrieve]-- artifact commons-cli#commons-cli;1.4!commons-cli.jar:
> [ivy:retrieve]
> C:\Users\Jan\.ivy2\shared\commons-cli\commons-cli\1.4\jars\commons-cli.jar
> [ivy:retrieve]   public: tried
> [ivy:retrieve]
> https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.pom
> [ivy:retrieve]-- artifact commons-cli#commons-cli;1.4!commons-cli.jar:
> [ivy:retrieve]
> https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.jar
>
> I dont have a proxy server I am aware of.
> I could access the url 
> https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.jar
>  via browser.
>
> Added a 'get' target which works:
> 
>  src="https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.jar;
>  dest="."/>
> 
>
> Another try:
>   ant -lib ..\..\..\ivy-2.5.0.jar -autoproxy run
> and that worked.

I gave this example a try with this released version and it went fine
without those warnings or errors. I suspect your Ivy cache probably had
already downloaded the metadata/resources previously using some other
"resolver"?


> So a +1 from me.
Thank you.
> Thanks for getting the release done.

This was on my TODO list for a very long time now. Glad that this is now
happening.

-Jaikiran



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

Re: [VOTE] Release Ivy 2.5.0 based on RC1

2019-10-23 Thread Stefan Bodewig 
+1

Stefan

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

AW: [VOTE] Release Ivy 2.5.0 based on RC1

2019-10-23 Thread jhm 
Checked the bin.zip.
Seems to be ok.

Just a question: there is a file fr\jayasoft\ivy\ant\antlib.xml which seems to 
be a copy of org\apache\ivy\ant\antlib.xml. Is it for BWC?

Hello-Ivy-Example:
- run with "ant -lib ..\..\..\ivy-2.5.0.jar run"
--> Ivy starts
--> Ivy vesion 2.5.0
--> Problems with downloading the dependencies:

[ivy:retrieve]  found commons-lang#commons-lang;2.6 in public
[ivy:retrieve] You probably access the destination server through a proxy 
server that is not well configured.

[ivy:retrieve] :: problems summary ::
[ivy:retrieve]  WARNINGS
[ivy:retrieve]  Host repo1.maven.org not found. 
url=https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.pom
[ivy:retrieve]  Host repo1.maven.org not found. 
url=https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.jar
[ivy:retrieve]  module not found: commons-cli#commons-cli;1.4
[ivy:retrieve]   local: tried
[ivy:retrieve]
C:\Users\Jan\.ivy2\local\commons-cli\commons-cli\1.4\ivys\ivy.xml
[ivy:retrieve]-- artifact commons-cli#commons-cli;1.4!commons-cli.jar:
[ivy:retrieve]
C:\Users\Jan\.ivy2\local\commons-cli\commons-cli\1.4\jars\commons-cli.jar
[ivy:retrieve]   shared: tried
[ivy:retrieve]
C:\Users\Jan\.ivy2\shared\commons-cli\commons-cli\1.4\ivys\ivy.xml
[ivy:retrieve]-- artifact commons-cli#commons-cli;1.4!commons-cli.jar:
[ivy:retrieve]
C:\Users\Jan\.ivy2\shared\commons-cli\commons-cli\1.4\jars\commons-cli.jar
[ivy:retrieve]   public: tried
[ivy:retrieve]
https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.pom
[ivy:retrieve]-- artifact commons-cli#commons-cli;1.4!commons-cli.jar:
[ivy:retrieve]
https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.jar

I dont have a proxy server I am aware of.
I could access the url 
https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.jar 
via browser.

Added a 'get' target which works:

https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.jar;
 dest="."/>


Another try:
  ant -lib ..\..\..\ivy-2.5.0.jar -autoproxy run
and that worked.


So a +1 from me.
Thanks for getting the release done.



Jan


> -Ursprüngliche Nachricht-
> Von: Jaikiran Pai [mailto:jaiki...@apache.org]
> Gesendet: Sonntag, 20. Oktober 2019 13:13
> An: Ant Developers List; ivy-u...@ant.apache.org; u...@ant.apache.org
> Betreff: [VOTE] Release Ivy 2.5.0 based on RC1
> 
> Hello everyone,
> 
> I have built a candidate release for Ivy 2.5.0.
> 
> It's been a long time since we have done a release of Ivy. 2.4.0 was
> released on December 26, 2014 after which it took a while to release
> the next version. We revived the project a few years later and many bug
> fixes and some enhancements were done. Thanks to Nicolas, 2.5.0-rc1 was
> released on Apr 19, 2018. We intentionally called it 2.5.0-rc1 because
> of the long delay we had between these releases and also the amount of
> changes that went it. We wanted to quickly release 2.5.0 after that,
> but various different reasons (some of them being newly reported bugs),
> it got delayed. However, its now time to officially release 2.5.0. This
> is my first release of Ivy project, so please do check out the release
> artifacts and vote accordingly and if you find anything amiss, please
> report. The complete set of changes that are part of this release
> (since
> 2.4.0) is listed here
> https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-site-docs/release-
> notes.html.
> 
> The git tag for this release is:
> 
> https://gitbox.apache.org/repos/asf?p=ant-
> ivy.git;a=tag;h=refs/tags/2.5.0_Vote_RC1
> with SHA for this tag being 48234fc5ede85a865eb874a96c08472ce1751fd1
> 
> The artifacts has been published to:
> https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0/ at SVN
> revision 36396
> 
> The staging Maven repository is available at:
> 
> https://repository.apache.org/content/repositories/orgapacheant-
> 1043/org/apache/ivy/ivy/2.5.0/
> 
> The Eclipse updatesite is available here:
> 
> https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-
> 2.5.0.final_20191020104435/
> 
> 
> This vote will be open for at least 72 hours and will not close before
> 23rd October 2019 12:00 UTC.
> 
> - Jaikiran, Ivy 2.5.0 release manager, on behalf of Ivy team



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

Re: [VOTE] Release Ivy 2.5.0 based on RC1

2019-10-21 Thread Jaikiran Pai 
+1.

- Downloaded the .tar.gz and installed locally.

- Checked the NOTICE file.

- Checked some random documentation files.

- Ran some examples that are shipped.

- Built an internal project with this version.

All went fine.

-Jaikiran

On 20/10/19 4:43 PM, Jaikiran Pai wrote:
> Hello everyone,
>
> I have built a candidate release for Ivy 2.5.0.
>
> It's been a long time since we have done a release of Ivy. 2.4.0 was
> released on December 26, 2014 after which it took a while to release the
> next version. We revived the project a few years later and many bug
> fixes and some enhancements were done. Thanks to Nicolas, 2.5.0-rc1 was
> released on Apr 19, 2018. We intentionally called it 2.5.0-rc1 because
> of the long delay we had between these releases and also the amount of
> changes that went it. We wanted to quickly release 2.5.0 after that, but
> various different reasons (some of them being newly reported bugs), it
> got delayed. However, its now time to officially release 2.5.0. This is
> my first release of Ivy project, so please do check out the release
> artifacts and vote accordingly and if you find anything amiss, please
> report. The complete set of changes that are part of this release (since
> 2.4.0) is listed here
> https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-site-docs/release-notes.html.
>
> The git tag for this release is:
>    
> https://gitbox.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0_Vote_RC1
> with SHA for this tag being 48234fc5ede85a865eb874a96c08472ce1751fd1
>
> The artifacts has been published to:
>     https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0/ at SVN
> revision 36396
>
> The staging Maven repository is available at:
>    
> https://repository.apache.org/content/repositories/orgapacheant-1043/org/apache/ivy/ivy/2.5.0/
>
> The Eclipse updatesite is available here:
>    
> https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.final_20191020104435/
>
>
> This vote will be open for at least 72 hours and will not close before
> 23rd October 2019 12:00 UTC.
>
> - Jaikiran, Ivy 2.5.0 release manager, on behalf of Ivy team
>
>
> -
> 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

[VOTE] Release Ivy 2.5.0 based on RC1

2019-10-20 Thread Jaikiran Pai 
Hello everyone,

I have built a candidate release for Ivy 2.5.0.

It's been a long time since we have done a release of Ivy. 2.4.0 was
released on December 26, 2014 after which it took a while to release the
next version. We revived the project a few years later and many bug
fixes and some enhancements were done. Thanks to Nicolas, 2.5.0-rc1 was
released on Apr 19, 2018. We intentionally called it 2.5.0-rc1 because
of the long delay we had between these releases and also the amount of
changes that went it. We wanted to quickly release 2.5.0 after that, but
various different reasons (some of them being newly reported bugs), it
got delayed. However, its now time to officially release 2.5.0. This is
my first release of Ivy project, so please do check out the release
artifacts and vote accordingly and if you find anything amiss, please
report. The complete set of changes that are part of this release (since
2.4.0) is listed here
https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-site-docs/release-notes.html.

The git tag for this release is:
   
https://gitbox.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0_Vote_RC1
with SHA for this tag being 48234fc5ede85a865eb874a96c08472ce1751fd1

The artifacts has been published to:
    https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0/ at SVN
revision 36396

The staging Maven repository is available at:
   
https://repository.apache.org/content/repositories/orgapacheant-1043/org/apache/ivy/ivy/2.5.0/

The Eclipse updatesite is available here:
   
https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.final_20191020104435/


This vote will be open for at least 72 hours and will not close before
23rd October 2019 12:00 UTC.

- Jaikiran, Ivy 2.5.0 release manager, on behalf of Ivy team


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

Re: issue ivy 2.5.0 rc1

2019-10-10 Thread Jaikiran Pai 
Adding to what Maarten noted - the nightly builds are available for
testing here
https://builds.apache.org/job/Ivy/lastSuccessfulBuild/artifact/build/

The plan is to release a newer version of Ivy 2.5.0 soon (one other user
has reported a different issue which I want to review first before
deciding whether or not a fix is needed for that before releasing).

-Jaikiran

On 11/10/19 12:12 AM, Maarten Coene wrote:
> Thanks for the report Patrick,
>
> it seems this issue has already been fixed in git some time ago.
> It should be available in an upcoming release or in a recent nightly build.
>
>
> Maarten
>
>
>
> Op donderdag 10 oktober 2019 20:24:50 CEST schreef ENJOLRAS Patrick 
> : 
>
>
>
>
>
>   
>
>
> Hello,
>
>  
>
> Using Ivy 2.5.0 rc1 and  2.4.0, I had very often encountered a retrieve issue 
> with the exception:  java.lang.UnsupportedOperationException…
>
>  
>
> I had debug it, it comes from 
>
> org.apache.ivy.util.FileUtil.java
>
>  
>
> 184 existingChild.remove(childDest);
>
>  
>
> To fix it
>
> Line 174 existingChild = new 
> java.util.LinkedList(Arrays.asList(children));
>
>  
>
> Encapsulate arraysList as linkedList to be able to apply remove(File) 
> function.(ArrayList fixed size cannot apply remove(File ) on it 
> =>unsupportedOperationException)
>
>  
>
>     If someone could do the modification or tell me how to submit 
> it, it will be great.
>
>  
>
> Thanks.
>
>  
>
> Regards
>
>  
>
>   
>   
>
>   
>   
> Patrick Enjolras
> DIS BPS R Engineer 
> Tel.: 01 55 01 59 61
>
> Gemalto is now part of the Thales Group.
> Please note that my new email address is patrick.enjol...@thalesgroup.com
>   
>  
>   
>   
>
> THALES
>
>   
> 6, rue de la Verrerie 92190 Meudon
>
>
>   
>   
> www.thalesgroup.com
>   
>   
>   
>
> 
>
> 
>
> 
>
>   
>
>   
>
>   
>
>
>  
>
>  
>
>  
>
>
>
>
> -
> 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: issue ivy 2.5.0 rc1

2019-10-10 Thread Maarten Coene 
Thanks for the report Patrick,

it seems this issue has already been fixed in git some time ago.
It should be available in an upcoming release or in a recent nightly build.


Maarten



Op donderdag 10 oktober 2019 20:24:50 CEST schreef ENJOLRAS Patrick 
: 





  


Hello,

 

Using Ivy 2.5.0 rc1 and  2.4.0, I had very often encountered a retrieve issue 
with the exception:  java.lang.UnsupportedOperationException…

 

I had debug it, it comes from 

org.apache.ivy.util.FileUtil.java

 

184 existingChild.remove(childDest);

 

To fix it

Line 174 existingChild = new 
java.util.LinkedList(Arrays.asList(children));

 

Encapsulate arraysList as linkedList to be able to apply remove(File) 
function.(ArrayList fixed size cannot apply remove(File ) on it 
=>unsupportedOperationException)

 

    If someone could do the modification or tell me how to submit 
it, it will be great.

 

Thanks.

 

Regards

 

  
  

  
  
Patrick Enjolras
DIS BPS R Engineer 
Tel.: 01 55 01 59 61

Gemalto is now part of the Thales Group.
Please note that my new email address is patrick.enjol...@thalesgroup.com
  
 
  
  

THALES

  
6, rue de la Verrerie 92190 Meudon


  
  
www.thalesgroup.com
  
  
  







  

  

  


 

 

 




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

issue ivy 2.5.0 rc1

2019-10-10 Thread ENJOLRAS Patrick 
Hello,

Using Ivy 2.5.0 rc1 and  2.4.0, I had very often encountered a retrieve issue 
with the exception:  java.lang.UnsupportedOperationException...

I had debug it, it comes from
org.apache.ivy.util.FileUtil.java

184 existingChild.remove(childDest);

To fix it

Line 174 existingChild = new 
java.util.LinkedList(Arrays.asList(children));



Encapsulate arraysList as linkedList to be able to apply remove(File) 
function.(ArrayList fixed size cannot apply remove(File ) on it 
=>unsupportedOperationException)

If someone could do the modification or tell me how to submit 
it, it will be great.

Thanks.

Regards

[Thales]
Patrick Enjolras
DIS BPS R Engineer
Tel.: 01 55 01 59 61

Gemalto is now part of the Thales Group.
Please note that my new email address is 
patrick.enjol...@thalesgroup.com<mailto:patrick.enjol...@thalesgroup.com>

THALES
6, rue de la Verrerie 92190 Meudon

www.thalesgroup.com<http://www.thalesgroup.com/>
[http://intranet.peopleonline.corp.thales/portal/outlook/signature/ico_linkedin.png]<http://www.linkedin.com/company/thales>
[http://intranet.peopleonline.corp.thales/portal/outlook/signature/ico_twitter.png]<https://twitter.com/thalesgroup>
[http://intranet.peopleonline.corp.thales/portal/outlook/signature/ico_fb.png]<https://www.facebook.com/thalesgroup>
[http://intranet.peopleonline.corp.thales/portal/outlook/signature/ico_youtube.png]<https://www.youtube.com/user/thethalesgroup>

[Announce] Release of Apache Ivy 2.5.0-rc1

2018-04-22 Thread Nicolas Lalevée 
The Apache Ivy project is pleased to announce its 2.5.0-rc1 release.

Apache Ivy is a tool for managing (recording, tracking, resolving and
reporting) project dependencies, characterized by flexibility,
configurability, and tight integration with Apache Ant.

Key features of this 2.5.0-rc1 release are
* The minimum runtime Java version required is now Java 7
* Ivy now uses BouncyCastle OpenPGP API 1.59. Due to the non backward 
compatibility of that library, earlier versions are not supported.
* Ivy now uses HttpComponents HttpClient 4.5.x version with HTTP backed 
resolvers. Users are expected to have this version of the library (and its 
dependencies) in their runtime classpath if they want to use such resolvers. 
The previous (similarly named but not the same) commons-httpclient library is 
no longer used or supported. (IVY-1563)

As a release candidate version, we strongly encourage the use of this version 
for 
testing and validation.

Issues should be reported to:
https://issues.apache.org/jira/browse/IVY 


Download the 2.5.0-rc1 release at:
http://ant.apache.org/ivy/download.cgi 

More information can be found on the Ivy website:
http://ant.apache.org/ivy/ 

Regards,
Nicolas Lalevée

Re: [RESULT][VOTE] Ivy 2.5.0-rc1 Release

2018-04-19 Thread Nicolas Lalevée 
Binaries have been pushed, but the process to update the site still reference 
the old way, with a documentation managed with xooki. So I’ll need some time to 
create a process for asciidoc based documentation and run it.

Nicolas

> Le 19 avr. 2018 à 20:13, Nicolas Lalevée <nicolas.lale...@hibnet.org> a écrit 
> :
> 
> The release got 4 binding +1. The release is thus accepted.
> 
> I’ll get it published then.
> 
> Nicolas
> 
>> Le 12 avr. 2018 à 18:29, Nicolas Lalevée <nicolas.lale...@hibnet.org> a 
>> écrit :
>> 
>> I have built a release candidate for Ivy 2.5.0-rc1.
>> 
>> The git tag of this release is: 
>> https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1
>>  
>> <https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1>
>>  with the sha1 887fd46f3e90016e313f7724ca259b936d30a03e
>> 
>> The artifacts has been published to: 
>> https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1 
>> <https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1> at revision 26310
>> 
>> The staging Maven repository is available there: 
>> https://repository.apache.org/content/repositories/orgapacheant-1026 
>> <https://repository.apache.org/content/repositories/orgapacheant-1026>
>> 
>> The Eclipse updatesite has been build there: 
>> https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.cr1_20180412005306
>>  
>> <https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.cr1_20180412005306>
>> 
>> Do you vote for the release of these binaries?
>> 
>> Regards,
>> Nicolas
>> 
> 
> 
> -
> 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

[RESULT][VOTE] Ivy 2.5.0-rc1 Release

2018-04-19 Thread Nicolas Lalevée 
The release got 4 binding +1. The release is thus accepted.

I’ll get it published then.

Nicolas

> Le 12 avr. 2018 à 18:29, Nicolas Lalevée <nicolas.lale...@hibnet.org> a écrit 
> :
> 
> I have built a release candidate for Ivy 2.5.0-rc1.
> 
> The git tag of this release is: 
> https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1
>  
> <https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1>
>  with the sha1 887fd46f3e90016e313f7724ca259b936d30a03e
> 
> The artifacts has been published to: 
> https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1 
> <https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1> at revision 26310
> 
> The staging Maven repository is available there: 
> https://repository.apache.org/content/repositories/orgapacheant-1026 
> <https://repository.apache.org/content/repositories/orgapacheant-1026>
> 
> The Eclipse updatesite has been build there: 
> https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.cr1_20180412005306
>  
> <https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.cr1_20180412005306>
> 
> Do you vote for the release of these binaries?
> 
> Regards,
> Nicolas
> 


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

Re: [VOTE] Ivy 2.5.0-rc1 Release

2018-04-18 Thread Maarten Coene 
+1
I couldn't test the Ant tasks though as we still run Ant with Java 6.


Maarten
  Van: Nicolas Lalevée <nicolas.lale...@hibnet.org>
 Aan: Ant Developers List <dev@ant.apache.org> 
 Verzonden: donderdag 12 april 18:29 2018
 Onderwerp: [VOTE] Ivy 2.5.0-rc1 Release
   
I have built a release candidate for Ivy 2.5.0-rc1.

The git tag of this release is: 
https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1
 
<https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1>
 with the sha1 887fd46f3e90016e313f7724ca259b936d30a03e

The artifacts has been published to: 
https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1 
<https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1> at revision 26310

The staging Maven repository is available there: 
https://repository.apache.org/content/repositories/orgapacheant-1026 
<https://repository.apache.org/content/repositories/orgapacheant-1026>

The Eclipse updatesite has been build there: 
https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.cr1_20180412005306
 
<https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.cr1_20180412005306>

Do you vote for the release of these binaries?

Regards,
Nicolas

Re: [VOTE] Ivy 2.5.0-rc1 Release

2018-04-15 Thread Stefan Bodewig 
On 2018-04-15, Nicolas Lalevée wrote:

>> Le 14 avr. 2018 à 19:02, Stefan Bodewig  a écrit :

>>> Do you vote for the release of these binaries?

>> +1

>> If you want to call them 2.5.0-rc1. If you want the release to be 2.5.0
>> then the names of the archives and the jars are all wrong and you'll
>> have to rebuild everything (and call for another vote).

> We should probably have discussed it, or I should have been more clear
> in my proposal for this release. The last release we did of Ivy was a
> long time ago, so a lot has been included in this release. Then yes,
> that was intentional, a 2.5.0-rc1 will be for public consumption, with
> that rc marker showing the release may be not as stable as expected.

Understood. So my +1 stands :-)

>> It would be good if you could sign the tag as well.

> I think I did. I remember using 'git tag -s’ and being asked the
> password of my private key.

You did, I just didn't look close enough. Everything is fine.

Stefan

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

Re: [VOTE] Ivy 2.5.0-rc1 Release

2018-04-15 Thread Nicolas Lalevée 


> Le 14 avr. 2018 à 19:02, Stefan Bodewig <bode...@apache.org> a écrit :
> 
> On 2018-04-12, Nicolas Lalevée wrote:
> 
>> I have built a release candidate for Ivy 2.5.0-rc1.
> 
>> The git tag of this release is: 
>> https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1
>>  
>> <https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1>
>>  with the sha1 887fd46f3e90016e313f7724ca259b936d30a03e
> 
>> The artifacts has been published to: 
>> https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1 
>> <https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1> at revision 26310
> 
> As usual I haven't tested anything, just looked at the legal stuff,
> i.e. NOTICE and LICENSE are where they should be an look OK, checksums
> are fine, tag and source archive match and RAT is reasonably happy.
> 
>> Do you vote for the release of these binaries?
> 
> +1
> 
> If you want to call them 2.5.0-rc1. If you want the release to be 2.5.0
> then the names of the archives and the jars are all wrong and you'll
> have to rebuild everything (and call for another vote).

We should probably have discussed it, or I should have been more clear in my 
proposal for this release. The last release we did of Ivy was a long time ago, 
so a lot has been included in this release. Then yes, that was intentional, a 
2.5.0-rc1 will be for public consumption, with that rc marker showing the 
release may be not as stable as expected.

> It would be good if you could sign the tag as well.

I think I did. I remember using 'git tag -s’ and being asked the password of my 
private key.

I can see a PGP signature in SourceTree.
Github states it is verified: 
https://github.com/apache/ant-ivy/releases/tag/2.5.0-rc1 
<https://github.com/apache/ant-ivy/releases/tag/2.5.0-rc1>
'git verify-tag 2.5.0-rc1’ states it has a 'Good signature’

I am not fluent with git. I may have missed something.

> A minor nit, the .gitignore and .gitattributes files are mssing from the
> source archives. I don't consider this important but it would be nice if
> this could be fixed after the release.

Nice catch. I’ll fix that.

Thank you for your time Stefan.

Nicolas

Re: [VOTE] Ivy 2.5.0-rc1 Release

2018-04-14 Thread Stefan Bodewig 
On 2018-04-12, Nicolas Lalevée wrote:

> I have built a release candidate for Ivy 2.5.0-rc1.

> The git tag of this release is: 
> https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1
>  
> <https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1>
>  with the sha1 887fd46f3e90016e313f7724ca259b936d30a03e

> The artifacts has been published to: 
> https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1 
> <https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1> at revision 26310

As usual I haven't tested anything, just looked at the legal stuff,
i.e. NOTICE and LICENSE are where they should be an look OK, checksums
are fine, tag and source archive match and RAT is reasonably happy.

> Do you vote for the release of these binaries?

+1

If you want to call them 2.5.0-rc1. If you want the release to be 2.5.0
then the names of the archives and the jars are all wrong and you'll
have to rebuild everything (and call for another vote).

It would be good if you could sign the tag as well.

A minor nit, the .gitignore and .gitattributes files are mssing from the
source archives. I don't consider this important but it would be nice if
this could be fixed after the release.

Stefan

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

Re: [VOTE] Ivy 2.5.0-rc1 Release

2018-04-12 Thread Jaikiran Pai 

+1.

Thank you Nicolas for running this release.

Tested the following:

- Downloaded the .tar.gz binary

- Checked some random docs, that are part of the download. Looks fine.

- Built some random internal projects using this downloaded version of 
Ivy, using Java 8. All went well.


- Verified bug fixes for some random fixes that were part of this 
release (IVY-1540 and IVY-1577). Worked fine.


- Built some internal projects using the downloaded version of Ivy, 
using Java 9. All went fine.



-Jaikiran


On 12/04/18 9:59 PM, Nicolas Lalevée wrote:

I have built a release candidate for Ivy 2.5.0-rc1.

The git tag of this release is: 
https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1 
<https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1>
 with the sha1 887fd46f3e90016e313f7724ca259b936d30a03e

The artifacts has been published to: 
https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1 
<https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1> at revision 26310

The staging Maven repository is available there: 
https://repository.apache.org/content/repositories/orgapacheant-1026 
<https://repository.apache.org/content/repositories/orgapacheant-1026>

The Eclipse updatesite has been build there: 
https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.cr1_20180412005306
 
<https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.cr1_20180412005306>

Do you vote for the release of these binaries?

Regards,
Nicolas





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

Re: [VOTE] Ivy 2.5.0-rc1 Release

2018-04-12 Thread Nicolas Lalevée 

> Le 12 avr. 2018 à 18:29, Nicolas Lalevée <nicolas.lale...@hibnet.org> a écrit 
> :
> 
> I have built a release candidate for Ivy 2.5.0-rc1.
> 
> The git tag of this release is: 
> https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1
>  
> <https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1>
>  with the sha1 887fd46f3e90016e313f7724ca259b936d30a03e
> 
> The artifacts has been published to: 
> https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1 
> <https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1> at revision 26310
> 
> The staging Maven repository is available there: 
> https://repository.apache.org/content/repositories/orgapacheant-1026 
> <https://repository.apache.org/content/repositories/orgapacheant-1026>
> 
> The Eclipse updatesite has been build there: 
> https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.cr1_20180412005306
>  
> <https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.cr1_20180412005306>
> 
> Do you vote for the release of these binaries?

I have a very poor internet connection, I had to do the build on a remote 
server, so I have only done the basic checks, but it seems to works properly. 
Well, I have at least loaded in an Eclipse and it resolves properly.
I have only missed to set the date in the release notes in the packaged zip and 
tgz distributions, it still looks like this: 
http://ant.apache.org/ivy/history/master/release-notes.html 
<http://ant.apache.org/ivy/history/master/release-notes.html>. I think this is 
OK. I’ll just fix the version on the site once actually published.

So +1 for me.

Nicolas

Re: Ivy-2.5.0

2018-02-08 Thread Jaikiran Pai 
I think it's time to start moving this release process further. My work 
on IVY-1485 isn't complete nor is it in a state where I'm confident that 
it won't break/regress other things. So I think it's safe to move it out 
of this release and try and get it into some next release. We have a 
good amount of bug fixes that have been done since 2.4.0 and I think we 
should start looking at what it takes to do the release formalities.


-Jaikiran


On 09/01/18 12:29 PM, Jaikiran Pai wrote:

Hi Jan,

My efforts to resolve IVY-1485 have taken longer than I expected, 
mainly due to not finding enough time to sort it out. A few weekends I 
tried to focus on this, with my local WIP changes, I ran into merge 
issues with the latest upstream changes. I resolved them then and 
continued with the WIP changes. But a few weeks down the line I ran 
into the merge conflicts again. I haven't yet been able to find time 
to resolve them locally and spend time on the real fix (I do admit 
that I lost a bit of focus/interest with the merges).


I'll try again this weekend and see how far I can get this working. 
Either way, I don't want to block the release anymore. If I can't get 
IVY-1485 solved by this weekend, I propose to have it marked as a 
known issue for this release and I will try and get it out in the next 
release after that.


As you note, we do have good number of fixes in this release and it's 
time that we have them available to the general public.


-Jaikiran


On 08/01/18 8:18 PM, Jan Matèrne (jhm) wrote:

I took my old TODO list for Ivy-2.5.0.

Most of them are still open, how to deal with that?

In my opinion we should try to get a release out and postpone these to a
2.5.1 (means reducing stopper->later).

We have lots of changes we could deliver in this way. We also show a 
sign of

life in that way.



Jan




- https://issues.apache.org/jira/browse/IVY-1485

   Incorrect revision of dependencies put in to delivered Ivy files

   Status:

 11.09.2017: Jaikiran wanted to focus on that

   prio: stopper ("but it was IVY-1485 which reanimated the community")


- SVG-graphics

   Status:

 08.01.2018: unknown

   prio: should be included, as it seems to be nearly finished (for me)


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

   use Unicode glyphs or SVG data URLs instead of bitmaps

   Status:

 11.09.2017: review required

 08.01.2018: not sure what to do or what impact this have

   prio: should be included (as part of the "svg-bulk")


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

   fix the last inconsistencies in generics

   Status:

 11.09.2017: This includes a change which breaks BC

 08.01.2018: no consense on the API change

   prio: solve that or delay (this PR should not delay the new 
version in my

opinion)


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

   use the vectorised logo

   Status:

 11.09.2017: nearly finished (missing header)

 08.01.2018: no changes (license header missing)

   prio: include that as is nearly finished


- https://issues.apache.org/jira/browse/IVY-1420

   defaultconfmapping on  element is not written to
delivered ivy file

   Status:

 11.09.2017: "I need about a week"

 08.01.2018: done (27.09.2017)

   prio: should be included


- upgrading BouncyCastle

   Status: done


- IVY-1420/IVY-1437, defaultconf/defaultconfmapping/confmappingoverride
attributes

   "according to ivy.xsd, all three attributes can be used on both
dependencies and configurations.

   So, it's the documentation that must be adjusted accordingly"

   Status:

 11.09.2017: open

 08.01.2018: done

   prio: maybe delay (and open a Jira ticket)









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

Re: Ivy-2.5.0

2018-02-07 Thread Jaikiran Pai 
Maarten, I just pushed a change to Ivy upstream to not force existing 
implementations of this URLHandler to understand timeout constraints and 
yet have the feature available for other implementations. When you get a 
chance, can you please try the IvyIdea plugin build/test with the latest 
Ivy and see if it solves the issue?


-Jaikiran


On 09/01/18 5:53 PM, Maarten Coene wrote:

The change to the URLHandler class (TimoutConstraint) is also backwards 
incompatible.The IvyIdea plugin (IntelliJ) breaks on this which contains an 
extension of AbstractURLHandler.
I didn't look into it yet, maybe it can be changed to be more backwards 
compatible?

kind regards,Maarten

   Van: Gintautas Grigelionis <g.grigelio...@gmail.com>
  Aan: Ant Developers List <dev@ant.apache.org>
  Verzonden: dinsdag 9 januari 9:45 2018
  Onderwerp: Re: Ivy-2.5.0

2018-01-09 7:12 GMT+00:00 Jan Matèrne (jhm) <apa...@materne.de>:



What must be done to complete the work on SVG (IVY-922/IVY-450 or resp
PR-55/PR-60)? If you fine with merging (eventually adjusting the
contents of SVG), let's do it.

I added a comment on the PR.
For short:
- license header is missed on two files
- improve two JavaDocs
- test: does the fresh built Ivy use the SVG graphics?


I hope I addressed all points now.



Changes to alleviate IVY-1315/IVY-1419/IVY-1420/IVY-1437 should be
evaluated by reporters, but nobody responded because the issues are so
old.
I would rather close the issues and a open a new issue if needed. I

No. It's just a matter of prioritization by us.




added test cases for every issue highlighting the specific parts of the
problem and I can write up separately on the design problem with
permitting the same attributes on different elements with recursive
inheritance or using the same attribute name with different semantics
depending on the element (perhaps in Confluence? or Github wiki?).

Can't understand the problem (haven't that knowledge of Ivy).
IVY-1315 "is related to" IVY-1420, which is resolved.
Is IVY-1315 also resolved? Then just close that issue.


The problem is that the same set of attributes is allowed on both
configurations and dependencies. However, it is the attrubte values for
last element (dependencies) that are definitive -- unless they're absent.

Both configurations and dependencies can be inherited ("extended"); on top
of that, configurations allow for includes, which I guess predates
extension, and includes can have the attributes, too.

So the problem is: while ivy.xml is updated, the values of attributes may
change. Because ivy.xml is written in chunks, configurations (processed
early) may end up with different attribute values than dependencies (which
are definitive). That makes no difference when processed ivy.xml is
resolved, but might mess up subsequent extends.

Because the whole mechanism is underspecified, I tend to leave it as is
(put the final values of attributes on dependencies) rather than cache
configurations and publications until attributes on dependencies are
processed in order to guarantee that attributes have identical values for
both configurations and dependencies (or that configurations get the final
values if no attributes were present on dependencies).

I will close all issues pertaining to the attributes. When we agree on
specification, we can open a new one if needed.



My opinion on PR-57 is that it addresses another design problem in a
similarly good-enough fashion. We can handle this like Ant and have a
Java
7 branch (2.5.x) and a Java 8+ branch with further API changes (2.6.x).
The question is, whether that makes 2.5.x more interesting and is worth
the extra work?

I wouldn't create an extra branch just for that.
I am more a fan of moving to a newer Java version after that release.

I recap the PR-57:
- multiple changes array->collection
- all are fine expect one
- one central public interface added one new method
   -- no changes in semantics, but only in method declaration
(array->collection, generics)
   -- technically one new method and deprecating the old
- this means breaking backwards compatibility
- proposal is adding a 2nd interface extending the original interface and
adding that new method
   (could be 'inlined' in later Ivy version).

I followed the mail thread https://www.mail-archive.com/
dev@ant.apache.org/msg46002.html and found another problem
- ModuleRules breaks BWC due the same reason (as you pointed it out).

Maybe we should not include this PR into an Ivy-2.5.0 release but instead
move Ivy-2.6.0 to Java8 and change these parts in a (IMO) right but
backwards incompatible way.


PR-57 is narrowed down specificaly to the method addition in
DependencyResolver. That affects every resolver implementation; however, a
default method implementation is provided in AbstractResolver and all known
third party implementations use it.

We can kick the can down the road, but the important point is that Java
permits no arra

Re: Ivy-2.5.0

2018-02-03 Thread Gintautas Grigelionis 
Interesting, japicmp does not mark URLHandler as backwards incompatible,
even though it has a bunch of new methods :-S

On the other hand, IvyDEA has some old components: Commons VFS 1.0, JSch
0.1.31... BTW, JSch is a part of IntelliJ distribution?

Gintas

2018-01-09 15:40 GMT+01:00 Gintautas Grigelionis <g.grigelio...@gmail.com>:

> You can use PR-61 for that 
>
> Gintas
>
>
> Den 9 jan. 2018 14:53 skrev "Jaikiran Pai" <jai.forums2...@gmail.com>:
>
> Thanks Maarten, I'll look this.
>
> -Jaikiran
>
>
>
> On 09/01/18 5:53 PM, Maarten Coene wrote:
>
>> The change to the URLHandler class (TimoutConstraint) is also backwards
>> incompatible.The IvyIdea plugin (IntelliJ) breaks on this which contains an
>> extension of AbstractURLHandler.
>> I didn't look into it yet, maybe it can be changed to be more backwards
>> compatible?
>>
>> kind regards,Maarten
>>
>>Van: Gintautas Grigelionis <g.grigelio...@gmail.com>
>>   Aan: Ant Developers List <dev@ant.apache.org>
>>   Verzonden: dinsdag 9 januari 9:45 2018
>>   Onderwerp: Re: Ivy-2.5.0
>> 2018-01-09 7:12 GMT+00:00 Jan Matèrne (jhm) <apa...@materne.de>:
>>
>> What must be done to complete the work on SVG (IVY-922/IVY-450 or resp
>>>> PR-55/PR-60)? If you fine with merging (eventually adjusting the
>>>> contents of SVG), let's do it.
>>>>
>>> I added a comment on the PR.
>>> For short:
>>> - license header is missed on two files
>>> - improve two JavaDocs
>>> - test: does the fresh built Ivy use the SVG graphics?
>>>
>>> I hope I addressed all points now.
>>
>>
>> Changes to alleviate IVY-1315/IVY-1419/IVY-1420/IVY-1437 should be
>>>> evaluated by reporters, but nobody responded because the issues are so
>>>> old.
>>>> I would rather close the issues and a open a new issue if needed. I
>>>>
>>> No. It's just a matter of prioritization by us.
>>>
>>>
>>>
>>> added test cases for every issue highlighting the specific parts of the
>>>> problem and I can write up separately on the design problem with
>>>> permitting the same attributes on different elements with recursive
>>>> inheritance or using the same attribute name with different semantics
>>>> depending on the element (perhaps in Confluence? or Github wiki?).
>>>>
>>> Can't understand the problem (haven't that knowledge of Ivy).
>>> IVY-1315 "is related to" IVY-1420, which is resolved.
>>> Is IVY-1315 also resolved? Then just close that issue.
>>>
>>> The problem is that the same set of attributes is allowed on both
>> configurations and dependencies. However, it is the attrubte values for
>> last element (dependencies) that are definitive -- unless they're absent.
>>
>> Both configurations and dependencies can be inherited ("extended"); on top
>> of that, configurations allow for includes, which I guess predates
>> extension, and includes can have the attributes, too.
>>
>> So the problem is: while ivy.xml is updated, the values of attributes may
>> change. Because ivy.xml is written in chunks, configurations (processed
>> early) may end up with different attribute values than dependencies (which
>> are definitive). That makes no difference when processed ivy.xml is
>> resolved, but might mess up subsequent extends.
>>
>> Because the whole mechanism is underspecified, I tend to leave it as is
>> (put the final values of attributes on dependencies) rather than cache
>> configurations and publications until attributes on dependencies are
>> processed in order to guarantee that attributes have identical values for
>> both configurations and dependencies (or that configurations get the final
>> values if no attributes were present on dependencies).
>>
>> I will close all issues pertaining to the attributes. When we agree on
>> specification, we can open a new one if needed.
>>
>>
>> My opinion on PR-57 is that it addresses another design problem in a
>>>> similarly good-enough fashion. We can handle this like Ant and have a
>>>> Java
>>>> 7 branch (2.5.x) and a Java 8+ branch with further API changes (2.6.x).
>>>> The question is, whether that makes 2.5.x more interesting and is worth
>>>> the extra work?
>>>>
>>> I wouldn't create an extra branch just for that.
>>> I am more a fan of moving to a newer Java version after that release.
>>>
>>> I

Re: Ivy-2.5.0

2018-01-09 Thread Gintautas Grigelionis 
You can use PR-61 for that 

Gintas

Den 9 jan. 2018 14:53 skrev "Jaikiran Pai" <jai.forums2...@gmail.com>:

Thanks Maarten, I'll look this.

-Jaikiran



On 09/01/18 5:53 PM, Maarten Coene wrote:

> The change to the URLHandler class (TimoutConstraint) is also backwards
> incompatible.The IvyIdea plugin (IntelliJ) breaks on this which contains an
> extension of AbstractURLHandler.
> I didn't look into it yet, maybe it can be changed to be more backwards
> compatible?
>
> kind regards,Maarten
>
>Van: Gintautas Grigelionis <g.grigelio...@gmail.com>
>   Aan: Ant Developers List <dev@ant.apache.org>
>   Verzonden: dinsdag 9 januari 9:45 2018
>   Onderwerp: Re: Ivy-2.5.0
> 2018-01-09 7:12 GMT+00:00 Jan Matèrne (jhm) <apa...@materne.de>:
>
> What must be done to complete the work on SVG (IVY-922/IVY-450 or resp
>>> PR-55/PR-60)? If you fine with merging (eventually adjusting the
>>> contents of SVG), let's do it.
>>>
>> I added a comment on the PR.
>> For short:
>> - license header is missed on two files
>> - improve two JavaDocs
>> - test: does the fresh built Ivy use the SVG graphics?
>>
>> I hope I addressed all points now.
>
>
> Changes to alleviate IVY-1315/IVY-1419/IVY-1420/IVY-1437 should be
>>> evaluated by reporters, but nobody responded because the issues are so
>>> old.
>>> I would rather close the issues and a open a new issue if needed. I
>>>
>> No. It's just a matter of prioritization by us.
>>
>>
>>
>> added test cases for every issue highlighting the specific parts of the
>>> problem and I can write up separately on the design problem with
>>> permitting the same attributes on different elements with recursive
>>> inheritance or using the same attribute name with different semantics
>>> depending on the element (perhaps in Confluence? or Github wiki?).
>>>
>> Can't understand the problem (haven't that knowledge of Ivy).
>> IVY-1315 "is related to" IVY-1420, which is resolved.
>> Is IVY-1315 also resolved? Then just close that issue.
>>
>> The problem is that the same set of attributes is allowed on both
> configurations and dependencies. However, it is the attrubte values for
> last element (dependencies) that are definitive -- unless they're absent.
>
> Both configurations and dependencies can be inherited ("extended"); on top
> of that, configurations allow for includes, which I guess predates
> extension, and includes can have the attributes, too.
>
> So the problem is: while ivy.xml is updated, the values of attributes may
> change. Because ivy.xml is written in chunks, configurations (processed
> early) may end up with different attribute values than dependencies (which
> are definitive). That makes no difference when processed ivy.xml is
> resolved, but might mess up subsequent extends.
>
> Because the whole mechanism is underspecified, I tend to leave it as is
> (put the final values of attributes on dependencies) rather than cache
> configurations and publications until attributes on dependencies are
> processed in order to guarantee that attributes have identical values for
> both configurations and dependencies (or that configurations get the final
> values if no attributes were present on dependencies).
>
> I will close all issues pertaining to the attributes. When we agree on
> specification, we can open a new one if needed.
>
>
> My opinion on PR-57 is that it addresses another design problem in a
>>> similarly good-enough fashion. We can handle this like Ant and have a
>>> Java
>>> 7 branch (2.5.x) and a Java 8+ branch with further API changes (2.6.x).
>>> The question is, whether that makes 2.5.x more interesting and is worth
>>> the extra work?
>>>
>> I wouldn't create an extra branch just for that.
>> I am more a fan of moving to a newer Java version after that release.
>>
>> I recap the PR-57:
>> - multiple changes array->collection
>> - all are fine expect one
>> - one central public interface added one new method
>>-- no changes in semantics, but only in method declaration
>> (array->collection, generics)
>>    -- technically one new method and deprecating the old
>> - this means breaking backwards compatibility
>> - proposal is adding a 2nd interface extending the original interface and
>> adding that new method
>>(could be 'inlined' in later Ivy version).
>>
>> I followed the mail thread https://www.mail-archive.com/
>> dev@ant.apache.org/msg46002.html and found another problem
>> - ModuleRules

Re: Ivy-2.5.0

2018-01-09 Thread Jaikiran Pai 

Thanks Maarten, I'll look this.

-Jaikiran


On 09/01/18 5:53 PM, Maarten Coene wrote:

The change to the URLHandler class (TimoutConstraint) is also backwards 
incompatible.The IvyIdea plugin (IntelliJ) breaks on this which contains an 
extension of AbstractURLHandler.
I didn't look into it yet, maybe it can be changed to be more backwards 
compatible?

kind regards,Maarten

   Van: Gintautas Grigelionis <g.grigelio...@gmail.com>
  Aan: Ant Developers List <dev@ant.apache.org>
  Verzonden: dinsdag 9 januari 9:45 2018
  Onderwerp: Re: Ivy-2.5.0

2018-01-09 7:12 GMT+00:00 Jan Matèrne (jhm) <apa...@materne.de>:



What must be done to complete the work on SVG (IVY-922/IVY-450 or resp
PR-55/PR-60)? If you fine with merging (eventually adjusting the
contents of SVG), let's do it.

I added a comment on the PR.
For short:
- license header is missed on two files
- improve two JavaDocs
- test: does the fresh built Ivy use the SVG graphics?


I hope I addressed all points now.



Changes to alleviate IVY-1315/IVY-1419/IVY-1420/IVY-1437 should be
evaluated by reporters, but nobody responded because the issues are so
old.
I would rather close the issues and a open a new issue if needed. I

No. It's just a matter of prioritization by us.




added test cases for every issue highlighting the specific parts of the
problem and I can write up separately on the design problem with
permitting the same attributes on different elements with recursive
inheritance or using the same attribute name with different semantics
depending on the element (perhaps in Confluence? or Github wiki?).

Can't understand the problem (haven't that knowledge of Ivy).
IVY-1315 "is related to" IVY-1420, which is resolved.
Is IVY-1315 also resolved? Then just close that issue.


The problem is that the same set of attributes is allowed on both
configurations and dependencies. However, it is the attrubte values for
last element (dependencies) that are definitive -- unless they're absent.

Both configurations and dependencies can be inherited ("extended"); on top
of that, configurations allow for includes, which I guess predates
extension, and includes can have the attributes, too.

So the problem is: while ivy.xml is updated, the values of attributes may
change. Because ivy.xml is written in chunks, configurations (processed
early) may end up with different attribute values than dependencies (which
are definitive). That makes no difference when processed ivy.xml is
resolved, but might mess up subsequent extends.

Because the whole mechanism is underspecified, I tend to leave it as is
(put the final values of attributes on dependencies) rather than cache
configurations and publications until attributes on dependencies are
processed in order to guarantee that attributes have identical values for
both configurations and dependencies (or that configurations get the final
values if no attributes were present on dependencies).

I will close all issues pertaining to the attributes. When we agree on
specification, we can open a new one if needed.



My opinion on PR-57 is that it addresses another design problem in a
similarly good-enough fashion. We can handle this like Ant and have a
Java
7 branch (2.5.x) and a Java 8+ branch with further API changes (2.6.x).
The question is, whether that makes 2.5.x more interesting and is worth
the extra work?

I wouldn't create an extra branch just for that.
I am more a fan of moving to a newer Java version after that release.

I recap the PR-57:
- multiple changes array->collection
- all are fine expect one
- one central public interface added one new method
   -- no changes in semantics, but only in method declaration
(array->collection, generics)
   -- technically one new method and deprecating the old
- this means breaking backwards compatibility
- proposal is adding a 2nd interface extending the original interface and
adding that new method
   (could be 'inlined' in later Ivy version).

I followed the mail thread https://www.mail-archive.com/
dev@ant.apache.org/msg46002.html and found another problem
- ModuleRules breaks BWC due the same reason (as you pointed it out).

Maybe we should not include this PR into an Ivy-2.5.0 release but instead
move Ivy-2.6.0 to Java8 and change these parts in a (IMO) right but
backwards incompatible way.


PR-57 is narrowed down specificaly to the method addition in
DependencyResolver. That affects every resolver implementation; however, a
default method implementation is provided in AbstractResolver and all known
third party implementations use it.

We can kick the can down the road, but the important point is that Java
permits no arrays of generics and we must fix that.

Gintas





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

Re: Ivy-2.5.0

2018-01-09 Thread Maarten Coene 
The change to the URLHandler class (TimoutConstraint) is also backwards 
incompatible.The IvyIdea plugin (IntelliJ) breaks on this which contains an 
extension of AbstractURLHandler.
I didn't look into it yet, maybe it can be changed to be more backwards 
compatible?

kind regards,Maarten 

  Van: Gintautas Grigelionis <g.grigelio...@gmail.com>
 Aan: Ant Developers List <dev@ant.apache.org> 
 Verzonden: dinsdag 9 januari 9:45 2018
 Onderwerp: Re: Ivy-2.5.0
   
2018-01-09 7:12 GMT+00:00 Jan Matèrne (jhm) <apa...@materne.de>:

> > What must be done to complete the work on SVG (IVY-922/IVY-450 or resp
> > PR-55/PR-60)? If you fine with merging (eventually adjusting the
> > contents of SVG), let's do it.
>
> I added a comment on the PR.
> For short:
> - license header is missed on two files
> - improve two JavaDocs
> - test: does the fresh built Ivy use the SVG graphics?
>

I hope I addressed all points now.


>
> > Changes to alleviate IVY-1315/IVY-1419/IVY-1420/IVY-1437 should be
> > evaluated by reporters, but nobody responded because the issues are so
> > old.
> > I would rather close the issues and a open a new issue if needed. I
>
> No. It's just a matter of prioritization by us.
>
>
>
> > added test cases for every issue highlighting the specific parts of the
> > problem and I can write up separately on the design problem with
> > permitting the same attributes on different elements with recursive
> > inheritance or using the same attribute name with different semantics
> > depending on the element (perhaps in Confluence? or Github wiki?).
>
> Can't understand the problem (haven't that knowledge of Ivy).
> IVY-1315 "is related to" IVY-1420, which is resolved.
> Is IVY-1315 also resolved? Then just close that issue.
>

The problem is that the same set of attributes is allowed on both
configurations and dependencies. However, it is the attrubte values for
last element (dependencies) that are definitive -- unless they're absent.

Both configurations and dependencies can be inherited ("extended"); on top
of that, configurations allow for includes, which I guess predates
extension, and includes can have the attributes, too.

So the problem is: while ivy.xml is updated, the values of attributes may
change. Because ivy.xml is written in chunks, configurations (processed
early) may end up with different attribute values than dependencies (which
are definitive). That makes no difference when processed ivy.xml is
resolved, but might mess up subsequent extends.

Because the whole mechanism is underspecified, I tend to leave it as is
(put the final values of attributes on dependencies) rather than cache
configurations and publications until attributes on dependencies are
processed in order to guarantee that attributes have identical values for
both configurations and dependencies (or that configurations get the final
values if no attributes were present on dependencies).

I will close all issues pertaining to the attributes. When we agree on
specification, we can open a new one if needed.


> > My opinion on PR-57 is that it addresses another design problem in a
> > similarly good-enough fashion. We can handle this like Ant and have a
> > Java
> > 7 branch (2.5.x) and a Java 8+ branch with further API changes (2.6.x).
> > The question is, whether that makes 2.5.x more interesting and is worth
> > the extra work?
>
> I wouldn't create an extra branch just for that.
> I am more a fan of moving to a newer Java version after that release.
>
> I recap the PR-57:
> - multiple changes array->collection
> - all are fine expect one
> - one central public interface added one new method
>  -- no changes in semantics, but only in method declaration
> (array->collection, generics)
>  -- technically one new method and deprecating the old
> - this means breaking backwards compatibility
> - proposal is adding a 2nd interface extending the original interface and
> adding that new method
>  (could be 'inlined' in later Ivy version).
>
> I followed the mail thread https://www.mail-archive.com/
> dev@ant.apache.org/msg46002.html and found another problem
> - ModuleRules breaks BWC due the same reason (as you pointed it out).
>
> Maybe we should not include this PR into an Ivy-2.5.0 release but instead
> move Ivy-2.6.0 to Java8 and change these parts in a (IMO) right but
> backwards incompatible way.
>

PR-57 is narrowed down specificaly to the method addition in
DependencyResolver. That affects every resolver implementation; however, a
default method implementation is provided in AbstractResolver and all known
third party implementations use it.

We can kick the can down the road, but the important point is that Java
permits no arrays of generics and we must fix that.

Gintas

Re: Ivy-2.5.0

2018-01-09 Thread Gintautas Grigelionis 
2018-01-09 7:12 GMT+00:00 Jan Matèrne (jhm) <apa...@materne.de>:

> > What must be done to complete the work on SVG (IVY-922/IVY-450 or resp
> > PR-55/PR-60)? If you fine with merging (eventually adjusting the
> > contents of SVG), let's do it.
>
> I added a comment on the PR.
> For short:
> - license header is missed on two files
> - improve two JavaDocs
> - test: does the fresh built Ivy use the SVG graphics?
>

I hope I addressed all points now.


>
> > Changes to alleviate IVY-1315/IVY-1419/IVY-1420/IVY-1437 should be
> > evaluated by reporters, but nobody responded because the issues are so
> > old.
> > I would rather close the issues and a open a new issue if needed. I
>
> No. It's just a matter of prioritization by us.
>
>
>
> > added test cases for every issue highlighting the specific parts of the
> > problem and I can write up separately on the design problem with
> > permitting the same attributes on different elements with recursive
> > inheritance or using the same attribute name with different semantics
> > depending on the element (perhaps in Confluence? or Github wiki?).
>
> Can't understand the problem (haven't that knowledge of Ivy).
> IVY-1315 "is related to" IVY-1420, which is resolved.
> Is IVY-1315 also resolved? Then just close that issue.
>

The problem is that the same set of attributes is allowed on both
configurations and dependencies. However, it is the attrubte values for
last element (dependencies) that are definitive -- unless they're absent.

Both configurations and dependencies can be inherited ("extended"); on top
of that, configurations allow for includes, which I guess predates
extension, and includes can have the attributes, too.

So the problem is: while ivy.xml is updated, the values of attributes may
change. Because ivy.xml is written in chunks, configurations (processed
early) may end up with different attribute values than dependencies (which
are definitive). That makes no difference when processed ivy.xml is
resolved, but might mess up subsequent extends.

Because the whole mechanism is underspecified, I tend to leave it as is
(put the final values of attributes on dependencies) rather than cache
configurations and publications until attributes on dependencies are
processed in order to guarantee that attributes have identical values for
both configurations and dependencies (or that configurations get the final
values if no attributes were present on dependencies).

I will close all issues pertaining to the attributes. When we agree on
specification, we can open a new one if needed.


> > My opinion on PR-57 is that it addresses another design problem in a
> > similarly good-enough fashion. We can handle this like Ant and have a
> > Java
> > 7 branch (2.5.x) and a Java 8+ branch with further API changes (2.6.x).
> > The question is, whether that makes 2.5.x more interesting and is worth
> > the extra work?
>
> I wouldn't create an extra branch just for that.
> I am more a fan of moving to a newer Java version after that release.
>
> I recap the PR-57:
> - multiple changes array->collection
> - all are fine expect one
> - one central public interface added one new method
>   -- no changes in semantics, but only in method declaration
> (array->collection, generics)
>   -- technically one new method and deprecating the old
> - this means breaking backwards compatibility
> - proposal is adding a 2nd interface extending the original interface and
> adding that new method
>   (could be 'inlined' in later Ivy version).
>
> I followed the mail thread https://www.mail-archive.com/
> dev@ant.apache.org/msg46002.html and found another problem
> - ModuleRules breaks BWC due the same reason (as you pointed it out).
>
> Maybe we should not include this PR into an Ivy-2.5.0 release but instead
> move Ivy-2.6.0 to Java8 and change these parts in a (IMO) right but
> backwards incompatible way.
>

PR-57 is narrowed down specificaly to the method addition in
DependencyResolver. That affects every resolver implementation; however, a
default method implementation is provided in AbstractResolver and all known
third party implementations use it.

We can kick the can down the road, but the important point is that Java
permits no arrays of generics and we must fix that.

Gintas

AW: Ivy-2.5.0

2018-01-08 Thread jhm 
> What must be done to complete the work on SVG (IVY-922/IVY-450 or resp
> PR-55/PR-60)? If you fine with merging (eventually adjusting the
> contents of SVG), let's do it.

I added a comment on the PR.
For short:
- license header is missed on two files
- improve two JavaDocs
- test: does the fresh built Ivy use the SVG graphics?



> Changes to alleviate IVY-1315/IVY-1419/IVY-1420/IVY-1437 should be
> evaluated by reporters, but nobody responded because the issues are so
> old.
> I would rather close the issues and a open a new issue if needed. I

No. It's just a matter of prioritization by us.



> added test cases for every issue highlighting the specific parts of the
> problem and I can write up separately on the design problem with
> permitting the same attributes on different elements with recursive
> inheritance or using the same attribute name with different semantics
> depending on the element (perhaps in Confluence? or Github wiki?).

Can't understand the problem (haven't that knowledge of Ivy).
IVY-1315 "is related to" IVY-1420, which is resolved.
Is IVY-1315 also resolved? Then just close that issue.



> My opinion on PR-57 is that it addresses another design problem in a
> similarly good-enough fashion. We can handle this like Ant and have a
> Java
> 7 branch (2.5.x) and a Java 8+ branch with further API changes (2.6.x).
> The question is, whether that makes 2.5.x more interesting and is worth
> the extra work?

I wouldn't create an extra branch just for that.
I am more a fan of moving to a newer Java version after that release.

I recap the PR-57:
- multiple changes array->collection
- all are fine expect one
- one central public interface added one new method 
  -- no changes in semantics, but only in method declaration 
(array->collection, generics)
  -- technically one new method and deprecating the old
- this means breaking backwards compatibility
- proposal is adding a 2nd interface extending the original interface and 
adding that new method
  (could be 'inlined' in later Ivy version).

I followed the mail thread 
https://www.mail-archive.com/dev@ant.apache.org/msg46002.html and found another 
problem
- ModuleRules breaks BWC due the same reason (as you pointed it out).

Maybe we should not include this PR into an Ivy-2.5.0 release but instead move 
Ivy-2.6.0 to Java8 and change these parts in a (IMO) right but backwards 
incompatible way.



Jan


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

Re: Ivy-2.5.0

2018-01-08 Thread Gintautas Grigelionis 
What must be done to complete the work on SVG (IVY-922/IVY-450 or resp
PR-55/PR-60)? If you fine with merging (eventually adjusting the contents
of SVG), let's do it.

Changes to alleviate IVY-1315/IVY-1419/IVY-1420/IVY-1437 should be
evaluated by reporters, but nobody responded because the issues are so old.
I would rather close the issues and a open a new issue if needed. I added
test cases for every issue highlighting the specific parts of the problem
and I can write up separately on the design problem with permitting the
same attributes on different elements with recursive inheritance or using
the same attribute name with different semantics depending on the element
(perhaps in Confluence? or Github wiki?).

My opinion on PR-57 is that it addresses another design problem in a
similarly good-enough fashion. We can handle this like Ant and have a Java
7 branch (2.5.x) and a Java 8+ branch with further API changes (2.6.x). The
question is, whether that makes 2.5.x more interesting and is worth the
extra work?

Gintas


2018-01-08 14:48 GMT+00:00 Jan Matèrne (jhm) <apa...@materne.de>:

> I took my old TODO list for Ivy-2.5.0.
>
> Most of them are still open, how to deal with that?
>
> In my opinion we should try to get a release out and postpone these to a
> 2.5.1 (means reducing stopper->later).
>
> We have lots of changes we could deliver in this way. We also show a sign
> of
> life in that way.
>
>
>
>
>
> Jan
>
>
>
>
>
>
>
> - https://issues.apache.org/jira/browse/IVY-1485
>
>   Incorrect revision of dependencies put in to delivered Ivy files
>
>   Status:
>
> 11.09.2017: Jaikiran wanted to focus on that
>
>   prio: stopper ("but it was IVY-1485 which reanimated the community")
>
>
>
> - SVG-graphics
>
>   Status:
>
> 08.01.2018: unknown
>
>   prio: should be included, as it seems to be nearly finished (for me)
>
>
>
> - https://github.com/apache/ant-ivy/pull/60
>
>   use Unicode glyphs or SVG data URLs instead of bitmaps
>
>   Status:
>
> 11.09.2017: review required
>
> 08.01.2018: not sure what to do or what impact this have
>
>   prio: should be included (as part of the "svg-bulk")
>
>
>
> - https://github.com/apache/ant-ivy/pull/57
>
>   fix the last inconsistencies in generics
>
>   Status:
>
> 11.09.2017: This includes a change which breaks BC
>
> 08.01.2018: no consense on the API change
>
>   prio: solve that or delay (this PR should not delay the new version in my
> opinion)
>
>
>
> - https://github.com/apache/ant-ivy/pull/55
>
>   use the vectorised logo
>
>   Status:
>
> 11.09.2017: nearly finished (missing header)
>
> 08.01.2018: no changes (license header missing)
>
>   prio: include that as is nearly finished
>
>
>
> - https://issues.apache.org/jira/browse/IVY-1420
>
>   defaultconfmapping on  element is not written to
> delivered ivy file
>
>   Status:
>
> 11.09.2017: "I need about a week"
>
> 08.01.2018: done (27.09.2017)
>
>   prio: should be included
>
>
>
> - upgrading BouncyCastle
>
>   Status: done
>
>
>
> - IVY-1420/IVY-1437, defaultconf/defaultconfmapping/confmappingoverride
> attributes
>
>   "according to ivy.xsd, all three attributes can be used on both
> dependencies and configurations.
>
>   So, it's the documentation that must be adjusted accordingly"
>
>   Status:
>
> 11.09.2017: open
>
> 08.01.2018: done
>
>   prio: maybe delay (and open a Jira ticket)
>
>
>
>
>
>

Ivy-2.5.0

2018-01-08 Thread jhm 
I took my old TODO list for Ivy-2.5.0.

Most of them are still open, how to deal with that?

In my opinion we should try to get a release out and postpone these to a
2.5.1 (means reducing stopper->later).

We have lots of changes we could deliver in this way. We also show a sign of
life in that way.

 

 

Jan

 

 

 

- https://issues.apache.org/jira/browse/IVY-1485

  Incorrect revision of dependencies put in to delivered Ivy files

  Status:

11.09.2017: Jaikiran wanted to focus on that

  prio: stopper ("but it was IVY-1485 which reanimated the community")

 

- SVG-graphics

  Status:

08.01.2018: unknown

  prio: should be included, as it seems to be nearly finished (for me)

 

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

  use Unicode glyphs or SVG data URLs instead of bitmaps

  Status: 

11.09.2017: review required

08.01.2018: not sure what to do or what impact this have

  prio: should be included (as part of the "svg-bulk")

 

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

  fix the last inconsistencies in generics

  Status: 

11.09.2017: This includes a change which breaks BC

08.01.2018: no consense on the API change

  prio: solve that or delay (this PR should not delay the new version in my
opinion)

 

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

  use the vectorised logo

  Status: 

11.09.2017: nearly finished (missing header)

08.01.2018: no changes (license header missing)

  prio: include that as is nearly finished

 

- https://issues.apache.org/jira/browse/IVY-1420

  defaultconfmapping on  element is not written to
delivered ivy file

  Status: 

11.09.2017: "I need about a week"

08.01.2018: done (27.09.2017)

  prio: should be included

 

- upgrading BouncyCastle

  Status: done

 

- IVY-1420/IVY-1437, defaultconf/defaultconfmapping/confmappingoverride
attributes

  "according to ivy.xsd, all three attributes can be used on both
dependencies and configurations. 

  So, it's the documentation that must be adjusted accordingly"

  Status: 

11.09.2017: open

08.01.2018: done

  prio: maybe delay (and open a Jira ticket)