Re: deprecations
Just had a quick look at Project. There are a lot of deprecated methods. However I do not think that most of them are deprecated correctly. Users of the api should not have to know about implementation details and changes to implementation - for example the FileUtils.getFileUtils(). I downloaded the latest svn trunk version of ant-contrib and compiled it with -Xlint:deprecation. It uses a fair number of ant deprecated methods. Most of the issues could be removed. But... it would mean a new version of ant-contrib that would not work with old versions of ant (a very common occurrence). I would suspect that most 3rd party task collections would have similar issues. A major problem with the ant api is that is it not well specified and so it is too big - it included nearly all the ant implementation, but it is probably too late to fix that now. So, yes I guess I would be opposed. However for deprecated methods that need to be removed because it would be impossible to implement with newer and better implementations, I would have no problem with (perhaps using an implementation that throws an UnsupportedOperationException(dead api). Peter On Wed, Aug 22, 2012 at 12:19 AM, Matt Benson gudnabr...@gmail.com wrote: Hi Peter, So does that mean you would be opposed to removing these deprecated items? Matt On Tue, Aug 21, 2012 at 6:07 PM, Peter Reilly peter.kitt.rei...@gmail.com wrote: The only problem is the there are a lot of tasks out there in the wild that have not been compiled in a very long time. (I know I have uses a number), These will most likely use the deprecated methods, especially in regard to handling of properties and references. Peter 2012/8/20 Martin Gainty mgai...@hotmail.com: Hi Matt as long as there is a new method (or new class) to replace the deprecated method (or deprectaed class) Many Thanks for your diligence! Martin __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Mon, 20 Aug 2012 12:52:19 -0500 Subject: deprecations From: gudnabr...@gmail.com To: dev@ant.apache.org Hi gang, There are lots of methods in Ant's source that have been deprecated since e.g. v1.6. Does anyone object to removing deprecated methods for Ant 1.9? Matt - 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 - 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 2.3.x tested on Jenkins
The Ivy-tests job now run on both Ubuntu and Windows: https://builds.apache.org/pview/job/Ivy-tests/ Nicolas Le 20 août 2012 à 23:23, Maarten Coene a écrit : Thanks Nicolas :-) I also think a build matrix for Ivy would be a good idea... Maarten From: Nicolas Lalevée nicolas.lale...@hibnet.org To: Ant Developers List dev@ant.apache.org Sent: Monday, August 20, 2012 5:20 PM Subject: Ivy 2.3.x tested on Jenkins Since the trunk is moving a little from the 2.3.x branch, I have setup a build of the Ivy test suite of the 2.3.x branch: https://builds.apache.org/job/Ivy-2.3-tests/ Also, I have seen Maarten struggle with Unix path just like I do with Windows paths :) I think it will be interesting to do a build matrix for Ivy, like for Ant. At least to test on both ubuntu and Windows. Not sure it will be interesting to test for every jvm. 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
Re: File.toURL() and org.apache.tools.ant.launch.Locator.fileToURL(File)
Le 22 août 2012 à 00:04, Jesse Glick a écrit : On 08/21/2012 03:13 PM, Nicolas Lalevée wrote: Or is there some code which rely on the broken behavior? Not that I know of. See the various commented-out code blocks and XXX comments in this class; it has a long and messy history. I do not know whether the current code successfully works around all of File.toURL's failures. Just beware that File.toUri is also broken for UNC paths. For a hint, [1] shows some analogous code in NetBeans which uses the better Path.toUri on JDK 7+, simplifying file:///path to file:/path; falling back to File.toUri with a manual file:server/share/path - file://server/share/path correction. It seems to me that FileUtils.getFileURL is doing the job correctly. I have then deprecated Locator.fileToURL and replace it by FileUtils.getFileURL You may also need to be wary of non-ASCII characters in pathnames on operating systems not using UTF-8 consistently. The explanation I got from the author of Path.toUri ([2] p.c.) is that file:///some/path as produced by Path.toUri is expected to retain the original octet sequence used to construct the pathname, whereas file:/some/path may lack this information. The issue might affect interactions with forked processes. I do not understand this very well (on Linux you never have to worry about this kind of nonsense) but it may make sense to you. Don't understand the encoding issue there, since we are manipulating Strings. Since FileUtils.getFileURL is generating a String with only ASCII characters, it seems safe. [1] http://hg.netbeans.org/main/file/release72_base/openide.util/src/org/openide/util/Utilities.java#l3025 For the UNC files, something seems off, probably because I just discovered what UNC paths are. :) As far I understand, such path reference some file on a remote computer. But then why the host part of the URI being build is left to null ? [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7176702 It seems we cannot become watchers of jvm bugs, can we ? Nicolas - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: File.toURL() and org.apache.tools.ant.launch.Locator.fileToURL(File)
On 08/22/2012 08:50 AM, Nicolas Lalevée wrote: Don't understand the encoding issue there, since we are manipulating Strings. But String's which represent pathnames on an OS which might natively represent pathnames as octet sequences in some encoding. Again I am not sure what the defining example of this problem would be - my former attempts to make Windows deal sanely with non-ASCII filenames from Java failed miserably no matter what I tried, whereas everything just works on Linux. Not sure about Macs. As far I understand, such path reference some file on a remote computer. But then why the host part of the URI being build is left to null? Line #3059 (JDK 7) would not be executed for a UNC path because you would have file://server/share/path. Line #3072 (JDK 6) does pass null for host but the path starts with // so the constructor produces the proper URI in the end. You can check the unit tests if you are interested. It seems we cannot become watchers of jvm bugs, can we? Not sure. You used to be able to, but I have not managed to do this on bugs.sun.com for years. There has been talk of setting up a public JIRA/Bugzilla/etc. instance for the JDK it keeps on getting delayed, and anyway it is unclear if existing bugs would get migrated automatically. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: File.toURL() and org.apache.tools.ant.launch.Locator.fileToURL(File)
Le 22 août 2012 à 20:07, Jesse Glick a écrit : As far I understand, such path reference some file on a remote computer. But then why the host part of the URI being build is left to null? Line #3059 (JDK 7) would not be executed for a UNC path because you would have file://server/share/path. Line #3072 (JDK 6) does pass null for host but the path starts with // so the constructor produces the proper URI in the end. You can check the unit tests if you are interested. interesting indeed, I could not think we can put 4 slashes :) http://hg.netbeans.org/main/file/36bb0f394df1/openide.util/test/unit/src/org/openide/util/UtilitiesTest.java#l384 Nicolas - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: File.toURL() and org.apache.tools.ant.launch.Locator.fileToURL(File)
On 08/22/2012 02:30 PM, Nicolas Lalevée wrote: I could not think we can put 4 slashes file:server/share/path is the broken result of new File(server\\share\\path).toURI(). While new File(URI) works to round-trip it (IIRC), if you call URI.normalize() or otherwise do any kind of interesting manipulation at the URI level, you wind up with C:\server\share\path which is dead wrong. Path.toUri fixes this problem using the host field. The test is just checking that URI - File conversion is forgiving enough to accept the undesirable URI format if you happened to use File.toURI initially. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
jarsigner 1.5 and Ant zip
Hi, Our test suite seems to fail quite consistently on jar signing, but only with the jvm 1.5, Windows or Ubuntu. I have tested locally on my Mac, it fails too. With verbose turned on, here is what I see: [au:antunit] Signing JAR: /Users/hibou/dev/ant/svn/core/trunk/build/antunit/tmp/testoutput/signtest.jar to /Users/hibou/dev/ant/svn/core/trunk/build/antunit/tmp/testoutput/signtest.jar as testonly [au:antunit] Current OS is Mac OS X [au:antunit] Using input string [au:antunit] Executing '/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/jarsigner' with arguments: [au:antunit] '-keystore' [au:antunit] '/Users/hibou/dev/ant/svn/core/trunk/src/etc/testcases/testkeystore' [au:antunit] '/Users/hibou/dev/ant/svn/core/trunk/build/antunit/tmp/testoutput/signtest.jar' [au:antunit] 'testonly' [au:antunit] [au:antunit] The ' characters around the executable and arguments are [au:antunit] not part of the command. [au:antunit] Got IOException reading file /Users/hibou/dev/ant/svn/core/trunk/build/antunit/tmp/testoutput/signtest.jarjava.util.zip.ZipException: central directory zip64 extended information extra field's length doesn't match central directory data. Expected length 0 but is 16 [au:antunit] Build sequence for target(s) `tearDown' is [tearDown] As far I can tell, the jar signing goes well. But them it is the 'issigned' task which fail to read the jar properly. I have tested to unzip the jar with several tools, no issue. Just Ant fails. An expert in zip file compression format should probably have a look into it :) By the way, here is the jar: http://people.apache.org/~hibou/signtest.jar Nicolas - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r1376019 - in /ant/core/trunk/src/main/org/apache/tools/ant/launch: Launcher.java Locator.java
On 2012-08-22, hi...@apache.org wrote: Make Locator.fileToURL and replace its use by FileUtils.getFileUtils().getFileURL() Doesn't this cause a dependency cycle between ant.jar and ant-launcher.jar? Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
