Community
Participate
Working Groups
Please update commons net dependency to 3.0 this will ease the work for downstreams that ship with more recent dependencies. Updating to Commons Net 3.0 should not be an issue at all as according to upstream it should be pretty straight forward http://commons.apache.org/net/migration.html.
At Eclipse, we can typically release newer libraries only with the yearly release train - and this request was too late for Indigo 2011 since updating the lib also requires the lib to undergo an IP/Legal review. I'm wondering what's the concrete reason for asking to get the lib into Orbit? Any concrete bugfixes you need? If it's just to ease the life of downstream and 3.0 is binary compatible with 2.2, would it help if we just made the Require-bundle version range broader in TM so we can accept a 3.0 lib as well even if we don't ship it from Eclipse? That could be done in an Indigo SR I guess, but each project using commons net would have to do it separately. Or is there any concrete bugfixes you need? For Juno 2012, updating the lib can be considered, but I'd also like to try and avoid updating the lib multiple times since that's work each time. I just got notice that Commons Net 3.0.1 was released for instance, so I'm glad I didn't import 3.0 right away: ------snip from the dev@commons.apache.org mailing list------------------ *** This is a bug-fix release which corrects a regression in 3.0 *** * NET-409: FTPClient truncates file (storeFile method). All users are encouraged to upgrade to 3.0.1. This release is binary compatible with 2.2 (and 3.0), but there are some minor changes to source compatibility, please read the release notes for full details: http://www.apache.org/dist/commons/net/RELEASE-NOTES.txt http://commons.apache.org/net/changes-report.html
Commons Net 3.1 has been added to Orbit : http://dev.eclipse.org/ipzilla/show_bug.cgi?id=6219 TM should be able to ship Commons Net 3.1 with Juno (3.4).
An initial downloadable bundle is available for testing: http://build.eclipse.org/orbit/committers/orbit-I/20120507174954/I20120507174954/
Integrated in TM 3.4RC1. That release of Commons Net is binary compatible, but there are few minor changes in source compatibility (some methods throw IOException now). For details see the Commons Net Release Notes [1]. Adopters which directly call Commons Net may need to update their version ranges in MANIFEST.MF and potentially make minor adaptions to their source code. [1] http://commons.apache.org/net/changes-report.html
As per bug 194473 comment 11 it turned out that Commons Net has a severe limitation that telnetInputStream.available() can block: https://issues.apache.org/jira/browse/NET-466 Reopening since we cannot adopt Commons Net 3.1 in TM until that issue is resolved by upstream.
Note TM builds fine against Commons Net 3.x and adopters who do not need telnet can get 3.x from Orbit at their own risk if they want - but in TM we cannot ship it just yet.
Commons Net 3.2 was released on 3-Dec-2012 and NET-466 has been fixed. Looks like we should take another stab adopting this into Orbit...
I've created a new CQ for Commons Net 3.2: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=7026
The CQ, and add-to-orbit CQ have been approved: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=7043 Will checkin to Orbit soon.
Commons.net 3.2 is now available from Orbit: http://build.eclipse.org/orbit/committers/orbit-I/20130514212025/I20130514212025/repository/plugins/org.apache.commons.net_3.2.0.v201305141515.jar http://build.eclipse.org/orbit/committers/orbit-I/20130514212025/I20130514212025/repository/plugins/org.apache.commons.net.source_3.2.0.v201305141515.jar http://build.eclipse.org/orbit/committers/orbit-I/20130514212025/I20130514212025/
I've pushed the change to org.eclipse.tm.releng/maps/tmcore.map to master: https://git.eclipse.org/c/tm/org.eclipse.tm.git/commit/?id=ef1de17e105b023cfc4699b26490460aa79b911e I'm not sure if anything else needs to be done for Tycho (Anna?). Note that the reference to the Orbit build will need to be updated again for the release, as soon as Orbit has "promoted" the build. For now, we're pulling in the new commons net from an interim build. I'll keep the bug open until the update is done. I did a brief smoke test of FTP and telnet, and found two bugs: https://bugs.eclipse.org/bugs/show_bug.cgi?id=408090 https://bugs.eclipse.org/bugs/show_bug.cgi?id=408092 I personally don't think that these are related to the new commons net library. Perhaps others could have a look without the new commons net to check. At any rate, people should give the new library some good deal of testing ... especially passive mode, connection timeouts ... it should never "hang" eclipse.
Additional change updating the root-pom.xml : https://git.eclipse.org/c/tm/org.eclipse.tm.git/commit/?id=59c94aceacca1b15138aa990855624a53fa87381
I'm going to mark this FIXED since the change is in git for TM 3.5 RC1. The task of updating to the Orbit R-Build will be tracked in bug 408240 .
Commons Net 3.2 Release Notes, listing changes: http://commons.apache.org/proper/commons-net/changes-report.html In my practical testing, I've seen the Commons Net 3.2 release to be stable, and provide more exact list parsing (trailing spaces, embedded quotes, non-English language servers, date parsing, time zone management etc). Since we only use FTP and Telnet in TM / RSE, we don't use many of the features in Commons Net, yet it is good that we redistribute them. It turned out that Commons Net 3.2 has one regression: https://issues.apache.org/jira/browse/NET-492 But that was very easy to work around on our side: https://bugs.eclipse.org/bugs/show_bug.cgi?id=408092#c5 Adopters who need FTPClient#printWorkingDirectory() should use a similar workaround - the bugzilla comment above has a link to git with the code.
