[jira] Commented: (NET-61) [net] FTPClient.listFiles() hangs on Red Hat Linux
[ http://issues.apache.org/jira/browse/NET-61?page=comments#action_12460625
]
Steve Cohen commented on NET-61:
Rory, sorry I've been too busy to be involved here, but could you briefly sum
up what the change was? I banged my head on this one for quite awhile when it
was first logged.
[net] FTPClient.listFiles() hangs on Red Hat Linux
--
Key: NET-61
URL: http://issues.apache.org/jira/browse/NET-61
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4 Final
Environment: Operating System: Linux
Platform: PC
Reporter: George Van Treeck
Priority: Blocker
Fix For: 2.0
A Java app that uses FTPClient to download a file from a website to Windows
XP
works properly. But, when the same app runs on Linux to download the same
file
from the same website, it hangs at listFiles().
Using Java 1.5.0_03 on both the Windows XP and Linux. The version of Linux
used is Fedor Red Hat Linux Core 3 with all the latest updates. The following
segment of code from the program demonstrates the problem:
FTPClient ftp = new FTPClient();
ftp.connect(host);
reply = ftp.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
final String ftpStatus = ftp.getReplyString();
ftp.disconnect();
throw new IOException(
FTP server refused connection. Status: +
ftpStatus);
}
ftp.login(user, password);
reply = ftp.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
final String ftpStatus = ftp.getReplyString();
ftp.disconnect();
throw new IOException(
FTP server refused username/password. Status: +
ftpStatus);
}
String[] list = ftp.listNames();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (NET-114) [net] Unix parser not handling filenames beginning with whitespace
David Kocher (JIRA) wrote: [ http://issues.apache.org/jira/browse/NET-114?page=comments#action_12442207 ] David Kocher commented on NET-114: -- [[ Old comment, sent by email on Sun, 27 Aug 2006 16:53:31 +0200 (CEST) ]] (This is an automated response you will receive only once.) I am currently travelling and emails are replied to with a considerable time lag only. If you are having trouble with Cyberduck, please have a look at the help pages [1] and discuss your problem on the forum [2]. If you discovered a bug or would like to request a feature, please open a ticket [3] for it, so I don't forget about. If you are curious about my journey, have a look at my blog [4] which might reveal some tidbits ;) Thanks for your patience! ~David Kocher [1] http://help.cyberduck.ch/ [2] http://forum.cyberduck.ch/ [3] http://trac.cyberduck.ch/newticket/ [4] http://sudo.ch/~dkocher/ [net] Unix parser not handling filenames beginning with whitespace -- Key: NET-114 URL: http://issues.apache.org/jira/browse/NET-114 Project: Commons Net Issue Type: Bug Environment: Operating System: Mac OS X 10.3 Platform: All Reporter: David Kocher Priority: Minor Filenames beginning with whitespace (such as filename) are not parsed correctly. Currently any whitespace between the date and filename is ignored. However one can probably assume there is only one whitespace character between the date and the filename and any additional whitespace is part of the filename. (This is an assumption made from my experience with different ftp server implementations) === --- UnixFTPEntryParser.java (revision 208907) +++ UnixFTPEntryParser.java (working copy) @@ -101,9 +101,9 @@ year (for non-recent standard format) or time (for numeric or recent standard format */ - + (\\d+(?::\\d+)?)\\s+ + + (\\d+(?::\\d+)?)\\s - + (\\S*)(\\s*.*); + + (\\s*\\S*)(\\s*.*); /** I can see your point, and yet part of me insists on asking what possible justification is there for naming a file with one or more spaces at the beginning? This seems to me as remote, if not more remote, than the possibility that somewhere, some FTP server is coded so as to allow the use of more than one space between the different pieces of information in an FTP listing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release [net] version 2.0
Thank you, Rory. I'm now officially +1 Rory Winston wrote: Steve Sorry, I should have been more specific 1) Yes, there will be two separate branches of development. At the moment, the trunk is the 1.x branch, whereas there is a separate branch for JDK 5.0 dev. We can keep this the way it is, or swap the trunk and branch at some stage. 2) We need two sites, for sure. I think an easy way would be to do the separate Maven 1 (1.x codebase) and Maven 2.0 (2.x codebase) builds, and just put a link from one site to the other in the Maven menus. Otherwise, if Maven 2 can handle this kind of situation out of the box, we should move the 1.x build over to Maven 2 as well.What do you think? Hope this helps Rory Steve Cohen wrote: Rory Winston wrote: OK, seeing as we have reached some kind of consensus on how to handle backards-incompatible JDK releases, I'm restarting the vote for a release of Commons::Net 2.0 (the JDK 5.0 branch). As per usual, just respond with +1 +0 -0 -1 Thanks Rory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Sorry, Rory, but I think you need to express the consensus that you think we are voting on. You haven't done that. release of Commons::Net 2.0 (the JDK 5.0 branch) doesn't get to the heart of all the issues. 1: Are there two official branches or is 1.4.x relegated to backward compatibility mode? I would insist that there be two branches until Sun puts 1.4.x into EndOfLife mode. 2. Is the site going to be organized to reflect the two branches? If those two points are part of your motion, I'm +1. Otherwise, I'm -1. Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release [net] version 2.0
Rory Winston wrote: OK, seeing as we have reached some kind of consensus on how to handle backards-incompatible JDK releases, I'm restarting the vote for a release of Commons::Net 2.0 (the JDK 5.0 branch). As per usual, just respond with +1 +0 -0 -1 Thanks Rory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Sorry, Rory, but I think you need to express the consensus that you think we are voting on. You haven't done that. release of Commons::Net 2.0 (the JDK 5.0 branch) doesn't get to the heart of all the issues. 1: Are there two official branches or is 1.4.x relegated to backward compatibility mode? I would insist that there be two branches until Sun puts 1.4.x into EndOfLife mode. 2. Is the site going to be organized to reflect the two branches? If those two points are part of your motion, I'm +1. Otherwise, I'm -1. Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
Yandell wrote: On 9/9/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Steve Cohen wrote: I am not ready to vote yet on this until there is a discussion about what this release means. Will commons-net-2.0 become the official release, with previous versions relegated to backward compatibility support? If so, this may be premature as Sun is still supporting JDK-1.4.2-x. But I don't think we should stand in the way of progress either. Rory, can you comment on what are the specific new features that demand JDK 5.0 support? How have other jakarta-commons projects handled this? Are there any official versions that require 1.5? Are there projects that have two official releases? I see this as a positive step (a JDK 1.5 only release). I also see this as the right jump (from JDK 1.2/1.3 to 1.5). I'm a strong +1 for JDK 1.5 dependence. The way I see it is that while we're supporting 1.2-1.4, new development happens on 1.5 so the only time we need to worry about older JVMs is for critical bugfixes on maintenance systems - not for new development. Trying to focus on old JVMs makes us a maintenance project, not a development project and that's damaging for the project health. Lang 2.2 is in a limbo state because I can't get 1.2 for my Mac, I need to dig into Ubuntu to try and get it to work there and I can't even figure out how to get it to work on Windows at the moment (JDK 1.6 appears to be taking over the JAVA_HOME and PATH, but it's not defined in the user's environment variables). Another reason is that Lang has tests that fail to pass on 1.2 and 1.3; possibly due to bugs in the JVM (time crap). Even once I can make a 1.2/1.3 build, I'm not sure if I should. Plus other reasons, such as being without a happy laptop at home until tonight :) However, I believe that commons holds an almost unique place in Java development being the lowest layer in many many open source projects. As such making an incompatible major version change is a *very* big deal. [PROPOSAL] As such, I would like to propose that projects creating a JDK1.5 only release should use a new package name. Thus, in this case, the release would use the package org.apache.commons.net5.*. -1 for a slew of reasons. * Lots of source code would have to be touched just to upgrade; big pain in the arse for something that is quite likely to not involve any other change to a user's source. * Building v49 class files is going to explode on a v48 JVM, so people are going to be stopped pretty quickly from using the net5 on their old JVM. We don't need to protect them via packages. * Do we do net3 and net4 if we move from 1.2 to 1.3/1.4? Do we do net6? With this change, a user can have both the old and the new commons-net jars in their classpath without any conflicts. Only a JDK 1.5 user (1.6 too I guess). Presuming we make 1.5 targetted builds and not 1.2-1.4. And then it's nothing to do with 1.4/1.5 and just the classic problem of package clash within dependencies. Note that these users may be different OSS projects, which may upgrade at different times. Users wishing to migrate from one version to another can simply do a global search and replace on the package name. We must not underestimate the significance of the low-level position of commons in the Java OSS, and proprietry, communities. A clear and planned migration strategy for all our modules is needed. I accept that by its nature Commons is going to cause problems every time they release. We're going to be a frequent location for classpath clash problems. It's not JVM relevant though, it happens every time we release anything so the version you would need in the package name is the Commons major version, not the jdk version. I think we should declare that new development will be on 1.5 - building 1.5 only jars. Anyone trying to use them on 1.4 and before is going to get a nice error and we can start exploring new JDK features like regular expressions *sarc :) *. Then we can stick with it until 1.8 is in beta or something. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
I think we are in agreement. I would be available to do some of the backporting work if we go down this path. Does anyone have anything to say about making the site a dual site (something like Tomcat does)? How difficult is that? Does Maven 2 aid in such a process, can it build a site from two different SVN branches at once? Or is it really just two sites that link to one another? Rory Winston wrote: I agree with the major points that Steve has made below. I would think that a logical way to go (at least for [net]} would be : * Version 2.0 (JDK 5.0+) becomes the main development branch, and the focal point for new features; * Version 1.x continues to be supported, in that fixes and new features are backported where possible, and code submitted by the community targeted at the 1.x branch can still be applied. I think this is a pretty reasonable way of moving forward, encouraging new development on a codebase free of the shackles of legacy limitations, whilst still being able to service users with more conservative requirements. Rory Steve Cohen wrote: Continuing the discussion: 1. Regex support is in 1.4. It's only because we were trying to stay 1.2/1.3 compatible that we couldn't use it. That's a small point. I doubt we want to have (say) a 1.4.2 branch that requires 1.4 after having supported 1.2/1.3 for all these years, if our soon-to-be target is 1.5. I do agree that the oro dependency has been a very annoying pebble in the shoe. 2. I'm not comfortable with the .net5 package name. I see a cvs nightmare down that road. I guess SVN can handle that but it's still ugly. It makes upgrade for clients of net a maintenance nightmare. 3. JDK 5.0 has been officially released for around two years. In my opinion, there shouldn't even be a debate. It should be taken advantage of, and supported, although not at the expense of existing users on older versions. No, there unfortunately does need to be this debate. Sun has not end-of-lifed 1.4.2. That is important. They continue to release new subreleases of 1.4.2. Why? Important clients are still not ready to use 5.0. My employer, a very large corporation, now mandates the use of 5.0 but is forced immediately to relent on this mandate for some of its most important projects because it also still uses a lot of Websphere which still does not support 5.0 (and won't until WebSphere 7 is released and even then it will be some time before the server teams are ready to make that switch - they dragged their feet on Websphere 6 until recently). So Sun has to support 1.4 (and continues to have to make new subreleases of 1.4.2 for reasons such as the new daylight savings time start/end dates). The world marches on even when corporate java clients do not. Backward compatibility's a bitch, but if Sun has to worry about this, I think we do too. I don't think jakarta-commons has ever downgraded a version of java that Sun considers live. And yet, as Rory says, there are some compelling reasons to do so. I'd love to use JDK 5.0. It hasn't been a possibility for me yet. Even outside of work, for a long time Eclipse did not support 5.0 although I don't think it is anymore. So what is the solution? What does it mean to say not at the expense of existing users on older versions? I think we'd need to modify the site to have full support for two release branches, with some easy switch between them. There should be navigation menu items on the 2.0 site that point back to the 1.4.x site and vice versa as is the case with Tomcat and other projects. We can't just say all new development will be on 2.0, we'll continue to make 1.4.1 available for those who can't make the move. We may want to say that, but I don't think our user base will let us. Until Sun EOL's 1.4.x, I think our policy must be that every change that can be supported on pre-2.0 will be supported there. I also wonder if this should be a jakarta-commons-wide policy and not just something that net does. Rory Winston wrote: Hey guys An interesting discussion here. I'll try to address some of the points raised and give my take on the issue. * As far as [net] specifically is concerned, there are very few things that 1.5 makes possible that you really can't do on 1.3 (One of these is asynchronous I/O and a select()-based thread notification model). However, 1.5 does make a *ton* of things much cleaner. For instance, regex support is now on a par with [oro], so we lose our only external dependency, making [net] a self-contained single jar download. We can also support secure FTP without having to install a separate JSSE jar, as SSL/TLS support is now integral in JCE. Apart from that, there are many, many, smaller enhancements that we can make. See http://people.apache.org/~rwinston/commons-net-2.0/site/changes-report.html#2.0 for a few. * As far as I am concerned, the ideal scenario for a project like [net
Re: [VOTE] Release [net] version 2.0
Rory Winston wrote: Hi all I would like to gauge support for a release of Commons::Net 2.0. The major changes are: * FTPS (SSL/TLS) support has been added * FTPClient doesnt extend TelnetClient any longer * The build now uses Maven 2 * [net] is now standalone - no external dependencies outside the JDK itself * One new FTP parser (Netware) has been added, and the MVS parser has been heavily updated * A mini FTP-only jar (~ 90k) is available for clients who just need FTP functionality * Deprecated classes and methods have been removed A full list of changes can be found here: http://people.apache.org/~rwinston/commons-net-2.0/site/changes-report.html I have made the distribution (*unsigned* as yet) available for inspection: http://people.apache.org/~rwinston/commons-net-2.0/ And the site is available: http://people.apache.org/~rwinston/commons-net-2.0/site/ Thanks Rory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I am not ready to vote yet on this until there is a discussion about what this release means. Will commons-net-2.0 become the official release, with previous versions relegated to backward compatibility support? If so, this may be premature as Sun is still supporting JDK-1.4.2-x. But I don't think we should stand in the way of progress either. Rory, can you comment on what are the specific new features that demand JDK 5.0 support? How have other jakarta-commons projects handled this? Are there any official versions that require 1.5? Are there projects that have two official releases? Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Release Candidate for 2.0
Rory Winston wrote: Hi all I have done some work on a JDK 5.0 branch of Commons::Net. This may form the basis of a 2.0 release. Releases for earlier JDKs can continue along the 1.x branch. The major changes in the 2.0 branch are: * FTPS (SSL/TLS) support has been added * FTPClient doesnt extend TelnetClient any longer * The build now uses Maven 2 * [net] is now standalone - no external dependencies outside the JDK itself * One new FTP parser (Netware) has been added, and the MVS parser has been heavily updated * A mini FTP-only jar (~ 90k) is available for clients who just need FTP functionality A full list of changes can be found here: http://people.apache.org/~rwinston/commons-net-2.0/site/changes-report.html I have made the distribution (*unsigned* as yet) available for inspection: http://people.apache.org/~rwinston/commons-net-2.0/ And the site is available: http://people.apache.org/~rwinston/commons-net-2.0/site/ Some more docs are yet to be added. Any feedback appreciated. Thanks Rory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Rory, for this great contribution. I especially like the idea of the FTP-only jar. I haven't had a chance to look at it yet, but do you have a rough idea of how many of these changes may be possible to backport to the 1.x tree? At my job I'm STILL not able to use jdk 5.0 and I expect that there are many still in this boat. Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Release Candidate for 2.0
Rory Winston wrote: Hi all I have done some work on a JDK 5.0 branch of Commons::Net. This may form the basis of a 2.0 release. Releases for earlier JDKs can continue along the 1.x branch. The major changes in the 2.0 branch are: * FTPS (SSL/TLS) support has been added * FTPClient doesnt extend TelnetClient any longer * The build now uses Maven 2 * [net] is now standalone - no external dependencies outside the JDK itself * One new FTP parser (Netware) has been added, and the MVS parser has been heavily updated * A mini FTP-only jar (~ 90k) is available for clients who just need FTP functionality A full list of changes can be found here: http://people.apache.org/~rwinston/commons-net-2.0/site/changes-report.html I have made the distribution (*unsigned* as yet) available for inspection: http://people.apache.org/~rwinston/commons-net-2.0/ And the site is available: http://people.apache.org/~rwinston/commons-net-2.0/site/ Some more docs are yet to be added. Any feedback appreciated. Thanks Rory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Say, Rory, I notice that there are several classes that were deprecated several years ago, with a notice that they would be removed in 2.0. I think it would be good to keep this promise and remove these before release as their presence only causes confusion. FTPFileListParser FTPFileListParserImpl DefaultFTPFileListParser Additionally there are several deprecated methods in FTPClient, some of which take params of the above classes. These methods should also be removed. Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] FTP ListingFunctionalTest no longer works
We have some functional tests for commons-net, which depend on connecting to ftp sites and putting them through their paces. (These tests are excluded from Gump, for obvious reasons). Some of the tests depend on being able to access a vms ftp server at h71000.www7.hp.com. This ftp server no longer seems to accept connections (or it may just be a temporary glitch tonight). I believe Jeff Brekke wrote this test. Jeff, would you happen to know if this site has moved and if so, update the test? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Thank you for this explanation. It is good to actually look at the code instead of making assumptions, which is what I have been doing. The JSSE's jar does not provide javax.net.ssl versions of the com.sun.net.ssl interfaces And, after doing a little research, I find that there are differences between JSSE 1.0.3 and the packages in JDK 1.4, such that there is no backward compatibility. Basically, JSSE 1.0.x is a prototype, a hack through which Sun worked out the bugs, culminating in the better implementation that they released in 1.4. They did not just move the JSSE.jar code into JDK 1.4. They also improved it. Since these are new classes for us, I think it makes little sense to tie into backward compatibility from the start, when that backward compatibility is already out of date. I don't think there is a clean way to have one code base that will work the way we'd like it for both cases. Therefore, I think the solution for this is for Jakarta Commons Net to take Rory Winston's suggestion and start a new branch of Commons Net for JDK 1.4 only (for this and other reasons) and maintain two branches for awhile, the current HEAD branch for 1.3 compatibility and the new branch for 1.4. The new branch can use the javax.ssl.net classes, the old one can use com.sun.net. Jose Juan Montiel wrote: Hi Steve, What I think you're missing is that if you put jsse.jar on your classpath, you can use javax.net.ssl with java 1.3. maybe i don't explain well, sorry. The three classes of com.sun.net.ssl that are used for implement FTPS (in the way that Paul did and I modified, maybe there is another...) are... com.sun.net.ssl.KeyManagerFactory (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/KeyManagerFactory.html) com.sun.net.ssl.SSLContext (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/SSLContext.html) com.sun.net.ssl.TrustManager (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/TrustManager.html) This classes in JSSE are only in the package com.sun.net.ssl, and although in JSSE 1.0.3 there are a packege javax.net.ssl, it doesn't contain this classes, it contains javax.net.ssl.SSLSocket, a classes soon used, to implement FTPS. And the commons-net team would prefer to go that way because Sun says that com.sun.net may go away with some future release, but not javax.net. Yes, this would be a small inconvenience for java 1.3 users, but the stability is worth it. This three classes in JDK 1.4.2, were move to javax.net.ssl.KeyManagerFactory (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/KeyManagerFactory.html) javax.net.ssl.SSLContext (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLContext.html) javax.net.ssl.TrustManager (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/TrustManager.html) But if you download for example JDK 1.4.2 and look inside of (jre/lib) you'll find jsse.jar, the jar where still are com.sun.net.ssl. Sun, still mantain compatiblity with JDK 1.3. And still in JDK 1.5, you'll find jre/lib/jsse.jar. But when jsse.jar desapear, i offer to modified code... In other way if use javax.net.ssl.KeyManagerFactory , javax.net.ssl.SSLContext, javax.net.ssl.TrustManager, ftps don't work under JDK 1.3. I hope explain better, this time. Then, make that you consider appropiate... Thanks all, for your time. -- The whole purpose of places like Starbucks is for people with no decision-making ability whatsoever to make six decisions just to buy one cup of coffee. Short, tall, light, dark, caf, decaf, low-fat, non-fat, etc. So people who don't know what the hell they're doing or who on earth they are can, for only $2.95, get not just a cup of coffee but an absolutely defining sense of self: Tall. Decaf. Cappuccino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Daniel F. Savarese wrote: I'm living in the timewarp of digest mode subscription, so please forgive me for having made obsoleted comments. In message [EMAIL PROTECTED], Rory Winston writes: I think that's a great suggestion. It moves us forward without necessarily sacrificing backwards compatability. ... Steve Cohen wrote: Thank you for this explanation. It is good to actually look at the code instead of making assumptions, which is what I have been doing. ... Therefore, I think the solution for this is for Jakarta Commons Net to take Rory Winston's suggestion and start a new branch of Commons Net for JDK 1.4 only (for this and other reasons) and maintain two branches for awhile, the current HEAD branch for 1.3 compatibility and the new branch for 1.4. The new branch can use the javax.ssl.net classes, the old one can use com.sun.net. +1 Since we're going to branch anyway and in light of Steve's discoveries about JSSE 1.0.3, this seems like the easiest way to handle the situation. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Daniel, before we vote, I think we need a formal motion to vote on, especially in light of your obsoleted comments in the other thread. I think the proposal on the floor is to do two things A) a commons-net 1.5 containing fixes for any outstanding bugs and incorporating Josejuan Montiel and Paul Ferraro's FTPS code. This code would depend on com.sun.ssl.net classes. It would be the last release supporting JDKs 1.4 B) a commons-net 2.0 (possibly a different project) that would require jdk 1.4 compatibility, including modifying the FTPS code to use javax.ssl.net, the nio extensions, and using java 1.4's regex which would have the one small advantage of reducing dependency on other jars which periodically rears its head as an issue. While I'm generally in favor of this, I still don't think its ready for a vote because of possibly a different project, which is too vague. One more thing, we would need Paul Ferraro to sign a Software Grant which was mentioned about a week ago by Cliff Schmidt. I am trying to get details on this. Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JDK 1.4+ Branch?
Rory Winston wrote: Hi I have been following the email threads re: JSSE and FTPS functionality. I think that this might be a good point to consider introducing a version of Commons-Net that uses JDK 1.4+ as a baseline. My reasoning is as follows: * We could remove the (oro) jar dependency; * FTPS support would not necessitate a separate (JSSE) jar dependency; * It could be a good opportunity to clean up the threading code and socket handling, and make use of NIO; * It also may be easier to incrementally add new functionality, such as Proxy support Of course, JDK-1.3-compatible releases could still continue on HEAD, or we could move the 1.4+ branch to HEAD and the 1.3 code to a maintenance branch. As a simple proof-of-concept, I have set up a sandbox branch and made some minor enhancements, including: * Changing oro-dependant code to use Java regex code instead Any comments? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The only negative I can find is that our contributor of the FTPS stuff badly wants 1.3 compatibility. And I have a feeling that he's not the only one. 1.3 is not yet End of Life according to Sun, although it will be soon. My sense is that we lag Sun by some interval of time on these issues. I don't think we're going to be able to get away with saying no more enhancements for JDK1.3 for awhile. So this will probably mean maintaining two branches for some time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JDK 1.4+ Branch?
Right. That is the question we have to answer. I guess I'm okay with it but I'm not quite a +1 yet until I understand how much work is involved. I notice a couple of the Jakarta Commons projects do separate branches: Collections and HttpClient. There may be others, these were just the ones visible at 1 click from the Downloads page. It would certainly help us solve the FTPS issue. Rory Winston wrote: Steve Agreed that JDK 1.3 (and previous) is still important to support. My question is: is it desirable to put a 1.4+ version on HEAD and relegate JDK 1.3 to a separate branch, or do we not want to get into separate branch maintenance? R Steve Cohen wrote: Rory Winston wrote: Hi I have been following the email threads re: JSSE and FTPS functionality. I think that this might be a good point to consider introducing a version of Commons-Net that uses JDK 1.4+ as a baseline. My reasoning is as follows: * We could remove the (oro) jar dependency; * FTPS support would not necessitate a separate (JSSE) jar dependency; * It could be a good opportunity to clean up the threading code and socket handling, and make use of NIO; * It also may be easier to incrementally add new functionality, such as Proxy support Of course, JDK-1.3-compatible releases could still continue on HEAD, or we could move the 1.4+ branch to HEAD and the 1.3 code to a maintenance branch. As a simple proof-of-concept, I have set up a sandbox branch and made some minor enhancements, including: * Changing oro-dependant code to use Java regex code instead Any comments? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The only negative I can find is that our contributor of the FTPS stuff badly wants 1.3 compatibility. And I have a feeling that he's not the only one. 1.3 is not yet End of Life according to Sun, although it will be soon. My sense is that we lag Sun by some interval of time on these issues. I don't think we're going to be able to get away with saying no more enhancements for JDK1.3 for awhile. So this will probably mean maintaining two branches for some time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Jose Juan Montiel wrote: Hi, first of all, thanks for your attention, and your time to improve Jakarta Commons Net. Then I would like to finish this point. When you had to choose the way to implement FTPS, you propose: 3. Maybe. use the javax.net.ssl classes but document that if used with JDK 1.4, jsse.jar must be on the classpath. And I said: The 3º option it not possible, because, don't work under 1.3, although import jsse.jar... need change the import in source code... And you ask: Well if option 3 won't work, that changes things, but can you tell us how it fails? I said that option don't work under JDK 1.3, because javax.net.ssl its only in JDK 1.4. In those days, the list ask about the JDK that you use... I think that Jakarta support JDK 1.3, its a good idea, because although 1.3 its too old... thera are a lot of servers that run on this In this case i think, that implement FTPS using com.sun its the best option because, it run on 1.3 (importing JSSE) and 1.4 (where you dont need any aditiona jar import) And finally, what will be the choice...? Thanks for all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] What I think you're missing is that if you put jsse.jar on your classpath, you can use javax.net.ssl with java 1.3. And the commons-net team would prefer to go that way because Sun says that com.sun.net may go away with some future release, but not javax.net. Yes, this would be a small inconvenience for java 1.3 users, but the stability is worth it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Jose Juan Montiel wrote: 1. Use the javax.net.ssl classes. (Out of the question because of our mandate to support 1.3) 2. Do what Paul and Josejuan did - use the com.sun classes 3. Maybe. use the javax.net.ssl classes but document that if used with JDK 1.4, jsse.jar must be on the classpath. Hi, i'll use the second option, because if commons-net implements SSL-FTPS under JDK 1.3, its necesary import JSSE, and if use JDK 1.4, the source code, don't need any change. When commons-net, upgrde to JDK 1.4, if want remove JSSE, the modifications in source code will be simples. I'll do it :) The 3º option it not possible, because, don't work under 1.3, although import jsse.jar... need change the import in source code... Its my opinion. Thanks for all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Well if option 3 won't work, that changes things, but can you tell us how it fails? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTPS submission - legal issues
Henri Yandell wrote: Looks like you're in moderation there. Yeah. I realized after I sent it that I have no right to post there. I've tried subscribing, but unlike the other apache lists, approval does not seem to come automatically. I'm still waiting for approval. Looking at the Mail List Archives for that list, we see the following from Cliff Schmidt: -- If Paul Ferraro is the sole copyright owner of all the code of interest, then there shouldn't be a problem. Assumuning this is the case, the next question is whether the code is to be hacked on going forward within the Jakarta Commons community or whether it is just being dropped into some external/third-party directory. If the former, then Paul should sign a Software Grant. If the latter, Paul should simply create a new release of the code explicitly licensed under the Apache License, and the the Jakarta PMC can choose to allow that to be included in the Jakarta Commons distribution. --- Yes, the code is to be hacked on. Already there are suggestions for new features, etc. Cliff - any information on how to sign a Software Grant? I'll send the below when I see the email there: Are Paul and Josejuan the only contributors to the work? Usually you need to have the permission of every committer (contributor?) to the work to allow relicencing. That part is all about copyright law I think. This would seem to be so. Going over the whole Source Forge site for this project, there doesn't seem to be a single file committed there by anyone other than Mr. Ferraro. It looks like he removed the LPGL from every file on Friday, Jan 20. If there's anyone else he needs approval from to remove the LPGL, I didn't find it. The Source Forge site doesn't provide a list of developers for the project. However, in my due diligence, I did discover one item that might require some further comment. A previous version (1.1) of net.sf.ufsc.UserInfo.java contains the following copyright notice: /* * Copyright (c) 2004, Identity Theft 911, LLC. All rights reserved. */ Was this Paul Ferraro's company? If not, did he have permission to take it to LPGL? I don't think this would be a huge impediment anyway, at its worst. This is a very simple class for which a clean-room implementation, if needed, would be very simple to do. Does the com.sun bit mean that a separate jar is needed, or is it part of the JVM? It's apparently part of the JVM. The reason they used this class rather than the javax.net.ssl class of the same name is to preserve jdk 1.3 compatibility. Since that is an issue with commons-net as well, this is a good thing. These classes were originally part of the Java Secure Socket Extension (JSSE), which was incorporated into JDK 1.4. I'm not sure if the best way wouldn't be to require the use of this jar on the classpath for jdks 1.4, but this is now more a technical question than a legal one. In the latter case I think we'll find out that things are legally okay; if the former then the current policy is that that is okay (depends on licence, but we're shipping lots of Sun licenced works), but it's likely to require some hoops in the near future. Hen On 1/22/06, Steve Cohen [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: Steve - While there are multiple people on this list who are probably well-informed enough to answer the questions below definitively, I'd also ping legal-discuss@ which might have a better demographic for these kind of posts. -Rahul On 1/22/06, Steve Cohen [EMAIL PROTECTED] wrote: Josejuan Montiel ([EMAIL PROTECTED]) has submitted some code that would implement an FTPS protocol as an addition to commons-net. This submission takes the form of a patch submitted as a bug via http://issues.apache.org/bugzilla/show_bug.cgi?id=38309. Apparently this code was submitted as part of an existing project under SourceForge ( http://sourceforge.net/projects/ufsc). That project was originally under the LGPL, although its owner, Paul Ferraro has apparently agreed to switch it to the Apache License. Can some of the licensing gurus comment on this, and provide feedback? I would like to see this happen if it's possible. However, Mr. Montiel has more work to do before the team would accept the submission, and I am reluctant to suggest that he do it if some licensing issue that I am not aware of would kill the idea. Additionally. the submission depends on classes in the com.sun.net.ssl package. Are these legal imports for jakarta? Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] thanks, I've cross-posted there now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands
[net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Rory Winston wrote: Ive come across the com.sun.* issue before. They are part of the JVM, just not officially documented for public use. Usually, they are convenience classes written by Sun programmes who develop the JDK. AFAIK, Sun says that you can use them if you wish, but their use is not recommended, purely on the basis that they may disappear from one JDK release to the next. What are the com.sun.* classes being used here for, specifically? It may be possible to use official classes for this functionality. Rory From what I've been able to gather there are official classes as of jdk 1.4. Prior to that these were a separate package, the JSSE. So I guess there are three possibilities: 1. Use the javax.net.ssl classes. (Out of the question because of our mandate to support 1.3) 2. Do what Paul and Josejuan did - use the com.sun classes 3. Maybe. use the javax.net.ssl classes but document that if used with JDK 1.4, jsse.jar must be on the classpath. Has anyone on this list had experience with these type of issues? (technical, not legal). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] FTPS submission - legal issues
Josejuan Montiel ([EMAIL PROTECTED]) has submitted some code that would implement an FTPS protocol as an addition to commons-net. This submission takes the form of a patch submitted as a bug via http://issues.apache.org/bugzilla/show_bug.cgi?id=38309. Apparently this code was submitted as part of an existing project under SourceForge ( http://sourceforge.net/projects/ufsc). That project was originally under the LGPL, although its owner, Paul Ferraro has apparently agreed to switch it to the Apache License. Can some of the licensing gurus comment on this, and provide feedback? I would like to see this happen if it's possible. However, Mr. Montiel has more work to do before the team would accept the submission, and I am reluctant to suggest that he do it if some licensing issue that I am not aware of would kill the idea. Additionally. the submission depends on classes in the com.sun.net.ssl package. Are these legal imports for jakarta? Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTPS submission - legal issues
Rahul Akolkar wrote: Steve - While there are multiple people on this list who are probably well-informed enough to answer the questions below definitively, I'd also ping legal-discuss@ which might have a better demographic for these kind of posts. -Rahul On 1/22/06, Steve Cohen [EMAIL PROTECTED] wrote: Josejuan Montiel ([EMAIL PROTECTED]) has submitted some code that would implement an FTPS protocol as an addition to commons-net. This submission takes the form of a patch submitted as a bug via http://issues.apache.org/bugzilla/show_bug.cgi?id=38309. Apparently this code was submitted as part of an existing project under SourceForge ( http://sourceforge.net/projects/ufsc). That project was originally under the LGPL, although its owner, Paul Ferraro has apparently agreed to switch it to the Apache License. Can some of the licensing gurus comment on this, and provide feedback? I would like to see this happen if it's possible. However, Mr. Montiel has more work to do before the team would accept the submission, and I am reluctant to suggest that he do it if some licensing issue that I am not aware of would kill the idea. Additionally. the submission depends on classes in the com.sun.net.ssl package. Are these legal imports for jakarta? Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] thanks, I've cross-posted there now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] How to implent FTPS extending FTPClient, from a diferente package...
PLease write this up in bugzilla and we will consider it. Do you want to set these variables or only get them? Jose Juan Montiel wrote: Hi everybody, I'm Jose from Spain. I make an implement of FTPS: using http://sourceforge.net/projects/ufsc implementation (which use a new class, created by UFSC, org.apache.commons.net.ftp.FtpsClient that extends org.apache.commons.net.ftp.FTPClient), with some minor modification to adapt Java 1.3 and solve some fix with PASV transfer (modification and fix, that i comunicate to the author). I try to build FtpsClient under diferent packege, then i found that couldn't do it because, in org.apache.commons.net.ftp.FTP the variables BufferedReader _controlInput; BufferedWriter _controlOutput; were declare with packege visibility, and FtpsClient use this, to implement securety connection to SSLSocket. Something like this: this._controlInput = new BufferedReader(new InputStreamReader(socket.getInputStream(), getControlEncoding())); this._controlOutput = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream(), getControlEncoding())); Because of this, FtpsClient, in UFSC, is under org.apache.commons.net.ftp. Then the solution I adopt, was copy (and minor modify) FTPClient and FTP from org.apache.commons.net.ftp in my own package, and extends FtpsClient, from my own FTPClient, to make it in a difetent pakage... And now, my question is: why this variables are declare this way? without a getter? It could be possible, for future version, declare protected, for simplify the extension of api, to implement FTPS, or other future protocol... in diferent package...? Thanks to all, for your time and anwers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Elect Dennis Lundberg As Commons Committer
robert burrell donkin wrote: Dennis Lundberg has been a part of the commons community for a number of years now. he's contributed in a variety of ways to a number of different components especially by answering user questions, contributing documentation and by adding useful comments to discussions about development strategies. i also think that he cares about jakarta commons as a collective institution and seems willing to help us with the improvements we need to make collectively. IMHO we've been too long in recognising these qualities. (things seem to be running a little more smoothly with the processing of the paperwork for new committers now) i'll tally the votes no earlier than 1200 hours GMT on sunday 18th december. here's my +1 - robert --8 --- [x] +1 Elect Dennis as commons committer [ ] +0 Probably yes... [ ] -0 Probably no.. [ ] -1 No - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Maven, help or hinderance?
Torsten Curdt wrote: On 04.12.2005, at 02:17, Stephen Colebourne wrote: Hate to be an old fart here but was ant really all that bad? Oh ...please don't! All I have to say: dependency management plus the reports are just enough for me to never want to switch back to ant again. Even from m1! Worst case I was always able to come up with some non-standard goals-magic to do what I wanted. My 2 cents -- Torsten That wasn't Stephen Colebourne's comment, it was originally mine :-) I just did a release, my first in over a year, and man, was it annoying. But I wasn't completely serious. Maven allows us to produce a much nicer site with more functionality - no doubt about it. However, there are more steps now, more things to keep track of, more things to go wrong. And my comment sparked quite a lot of thread. My real thoughts are that it is now time to tighten up the jakarta-commons standard and documentation for maven use so that there are fewer of these manual extra steps that need to be done for every release. This is how this starts: Someone comes up with a neat idea and adds a manual step to the process to do that. Often, but not always, this gets documented. Better yet would be if it could get automated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Phil Steitz wrote: On 12/4/05, Steve Cohen [EMAIL PROTECTED] wrote: Phil Steitz wrote: On 12/4/05, Steve Cohen [EMAIL PROTECTED] wrote: Martin Cooper wrote: On 12/4/05, Steve Cohen [EMAIL PROTECTED] wrote: Phil Steitz wrote: On 12/4/05, Steve Cohen [EMAIL PROTECTED] wrote: This is another inaccuracy in the instructions. Step 14 says the dependencies are listed in STATUS.html. Net, at least doesn't have a STATUS.html. These seem to be generated from project.xml. Good point. Patch / update welcome. It would be great if you could bundle up any other issues that you ran into into a patch or direct update for the building/releasing docs. Phil I will, Phil. But is the non-existence of STATUS.html common to all of commons? If so, I will make the revisions myself. Incidentally, these items are all handled now prior to cutting the release, not as post release items. The STATUS files are a hold-over from the pre-Maven days. They were required because there was no POM / project.xml file in which the committer list could be maintained. Now that all of the components are using Maven, the STATUS files are pretty much obsolete. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Martin. I'll be happy to update the files myself, but where are they? I see some files that look like old versions of the site in commons-build's xdocs but they don't match what's on the site now. I've glanced all over the repository and haven't found the right place yet. The relevant files are in http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/xdocs/releases/ maven site from /commons-build should generate the site locally for you, then maven site:sshdeploy to publish (assuming you have key set up) Make sure to check changes in before updating the site. Thanks! Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Alas and alack. More maven problems. Couldn't run maven site on commons-build Downloaded maven 1.0.2 Reinstalled the maven xdoc plugin 1.9.2 get this: xdoc:jelly-transform: [echo] en [echo] The current Locale is the default one [echo] Scanning '/home/scohen/commons-build/target/generated-xdocs'... [echo] Generating /home/scohen/commons-build/target/docs/license.html from /home/scohen/commons-build/target/generated-xdocs/license.xml BUILD FAILED File.. /home/scohen/.maven/cache/maven-xdoc-plugin-1.9.2/plugin.jelly Element... j:include Line.. 479 Column 58 file:/home/scohen/.maven/cache/maven-xdoc-plugin-1.9.2/plugin-resources/site.jsl:33:17: jsl:stylesheet file:/home/scohen/.maven/cache/maven-xdoc-plugin-1.9.2/plugin-resources/site.jsl:156:57: jsl:applyTemplates file:/home/scohen/.maven/cache/maven-xdoc-plugin-1.9.2/plugin-resources/site.jsl:240:105: maven:property You must define an attribute called 'defaultValue' for this tag. Total time: 10 seconds Finished at: Sun Dec 04 22:09:51 CST 2005 :-( Are you sure you are executing maven from the the right directory - i.e., not above trunk? Also, you need the top-level directory to be named commons-build The second requirement can probably be removed by changing maven.xdoc.jsl=../commons-build/commons-site.jsl to maven.xdoc.jsl=commons-site.jsl In project.properties. Phil Thanks for all your help. These last suggestions worked. I built the site, tested my changes, then pushed the site. I DON'T have my key set up. where do I do this, it's a pain to keep typing in my password, but doable. Also, fyi, in my pushing of the site, I saw gobs of [exec] chmod: some/file: Operation not permitted Is this something not set up properly in my account or an expected glitch? In any case somebody might want to check the chmod settings of the site now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Phil Steitz wrote: snip Thanks for all your help. These last suggestions worked. I built the site, tested my changes, then pushed the site. I DON'T have my key set up. where do I do this, it's a pain to keep typing in my password, but doable. As indicated on the building page, you should follow the instructions on the bottom of this page: http://www.apache.org/dev/cvs-on-unix.html Right, I'd had this set up before. What I'd forgotten was I'd joined another site that required protocol 2, and my config was set up that way. But I'd only stored my protocol 1 key on apache. Logging on via ssh -1 works. Does apache accept protocol 2 ssh keys? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Maven, help or hinderance?
Henri Yandell wrote: I turn the navigation off on Maven projects. Can't stand the project-reports, project-info roll-ups that make it harder to find javadocs etc. Hear hear! Javadocs are not a project report for anyone who uses these sites. This one we can't blame on Maven, though, can we? I always assumed it was our setup of Maven. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons proper karma for Rahul Akolkar
Phil Steitz wrote: Rahul is an apache committer who already has commons-sandbox karma and is interested in contributing to commons proper as well. Let's give him karma to commons proper. I am not sure if a [vote] is really needed in this case, but in any case, here is my +1. Phil -- [ ] +1, let him commit! [ ] +0 [ ] -0 [ ] -1, no, because - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT] Commons-Net 1.4.1 Released
The Commons Net team announces the release of Commons Net 1.4.1. This small fix release cleans up ONLY the inadvertently introduced dependency on JDK 1.4 in commons-net 1.4.0. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Dion Gillard wrote: If we really do *have to have* a specific release of a plugin, it should be a dependency of the project. Noone should be forced to remember it. Worst case, we should provide a link to suggested upgrades and details about what to expect if you don't. Which brings me to my next question: The only dependency of this sort that NET includes in the dependency list ISN'T a dependency anymore. It's the statcvs module that we've just dropped (see earlier thread). Looks like I removed it from the reports section but not the dependencies section. I guess I can't do anything about that without redoing the release. Which I'm not about to do. This is another inaccuracy in the instructions. Step 14 says the dependencies are listed in STATUS.html. Net, at least doesn't have a STATUS.html. These seem to be generated from project.xml. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Another release documentation question
What is the point of marking defects LATER before the release and then resetting them afterward? I don't see any report on the site that makes use this information! Nor does it appear that there's any way to query bugzilla for the particular version I'm interested in commons-net 1.4.1. Why does the bugzilla query page have a droplist of version numbers rather than a combo-box? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Phil Steitz wrote: On 12/4/05, Steve Cohen [EMAIL PROTECTED] wrote: This is another inaccuracy in the instructions. Step 14 says the dependencies are listed in STATUS.html. Net, at least doesn't have a STATUS.html. These seem to be generated from project.xml. Good point. Patch / update welcome. It would be great if you could bundle up any other issues that you ran into into a patch or direct update for the building/releasing docs. Phil I will, Phil. But is the non-existence of STATUS.html common to all of commons? If so, I will make the revisions myself. Incidentally, these items are all handled now prior to cutting the release, not as post release items. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Maven, help or hinderance?
Phil Steitz wrote: On 12/4/05, Steve Cohen [EMAIL PROTECTED] wrote: Henri Yandell wrote: I turn the navigation off on Maven projects. Can't stand the project-reports, project-info roll-ups that make it harder to find javadocs etc. Hear hear! Javadocs are not a project report for anyone who uses these sites. This one we can't blame on Maven, though, can we? I always assumed it was our setup of Maven. What exactly is broken here? Sites that follow the instructions here http://jakarta.apache.org/commons/building.html or start with the sample nav here http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/navigation.xml.sample will link to current and previous release javadoc from the top level nav. Pretty much all maven-generated commons sites do this now. The real challenge is what Stephen mentioned and Brett responed to, which is how to maintain javadoc for past releases. Now these files have to be manually pushed out and links custom coded in navigation.xml. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] You're missing the point here, Phil. It's working as someone intended, I'm sure, but the location of Javadocs buried under Project Reports is bad from an end-user usability perspective. Granted, consistency is a good thing and frequent users may eventually learn, but it would be better for javadocs to be a top-level menu item. The Javadoc Report is a report and is in the right place but the Javadocs themselves are misplaced. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Martin Cooper wrote: On 12/4/05, Steve Cohen [EMAIL PROTECTED] wrote: Phil Steitz wrote: On 12/4/05, Steve Cohen [EMAIL PROTECTED] wrote: This is another inaccuracy in the instructions. Step 14 says the dependencies are listed in STATUS.html. Net, at least doesn't have a STATUS.html. These seem to be generated from project.xml. Good point. Patch / update welcome. It would be great if you could bundle up any other issues that you ran into into a patch or direct update for the building/releasing docs. Phil I will, Phil. But is the non-existence of STATUS.html common to all of commons? If so, I will make the revisions myself. Incidentally, these items are all handled now prior to cutting the release, not as post release items. The STATUS files are a hold-over from the pre-Maven days. They were required because there was no POM / project.xml file in which the committer list could be maintained. Now that all of the components are using Maven, the STATUS files are pretty much obsolete. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Martin. I'll be happy to update the files myself, but where are they? I see some files that look like old versions of the site in commons-build's xdocs but they don't match what's on the site now. I've glanced all over the repository and haven't found the right place yet. Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Maven, help or hinderance?
Martin Cooper wrote: On 12/4/05, Steve Cohen [EMAIL PROTECTED] wrote: Phil Steitz wrote: On 12/4/05, Steve Cohen [EMAIL PROTECTED] wrote: Henri Yandell wrote: I turn the navigation off on Maven projects. Can't stand the project-reports, project-info roll-ups that make it harder to find javadocs etc. Hear hear! Javadocs are not a project report for anyone who uses these sites. This one we can't blame on Maven, though, can we? I always assumed it was our setup of Maven. What exactly is broken here? Sites that follow the instructions here http://jakarta.apache.org/commons/building.html or start with the sample nav here http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/navigation.xml.sample will link to current and previous release javadoc from the top level nav. Pretty much all maven-generated commons sites do this now. The real challenge is what Stephen mentioned and Brett responed to, which is how to maintain javadoc for past releases. Now these files have to be manually pushed out and links custom coded in navigation.xml. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] You're missing the point here, Phil. It's working as someone intended, I'm sure, but the location of Javadocs buried under Project Reports is bad from an end-user usability perspective. Granted, consistency is a good thing and frequent users may eventually learn, but it would be better for javadocs to be a top-level menu item. The Javadoc Report is a report and is in the right place but the Javadocs themselves are misplaced. It's trivial to just add a link to them in your navigation.xml file. See the FileUpload, IO or Validator sites for examples. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Not quite so trivial. The commons-io site evidently pushes two sets of javadocs, one for SVN latest and another for the last official release. Net only has one and the one it has, although it's location is named analogously to io's SVN latest, actually points to net's last official release. So I suspect there's also some maven magic going on here as well. This is a nice feature, the way you have it in IO. Shouldn't this be part of the standard commons maven process? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another release documentation question
Phil Steitz wrote: On 12/4/05, Martin Cooper [EMAIL PROTECTED] wrote: On 12/4/05, Steve Cohen [EMAIL PROTECTED] wrote: What is the point of marking defects LATER before the release and then resetting them afterward? I will take a stab at the first question. Going through all of the open bug reports and resolving them or making the decision that they are not showstoppers and can wait until a later release is a key part of preparing a release. I think that is why that instruction was put in the docs. its been there for as long as I remember, I am just assuming that was the rationale. Its not so much the marking as later and then changing back that's important; its the item-by-item inspection, marking as later in some cases and giving the comunity the opportunity to complain that is important. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I'll buy that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Phil Steitz wrote: On 12/4/05, Steve Cohen [EMAIL PROTECTED] wrote: Martin Cooper wrote: On 12/4/05, Steve Cohen [EMAIL PROTECTED] wrote: Phil Steitz wrote: On 12/4/05, Steve Cohen [EMAIL PROTECTED] wrote: This is another inaccuracy in the instructions. Step 14 says the dependencies are listed in STATUS.html. Net, at least doesn't have a STATUS.html. These seem to be generated from project.xml. Good point. Patch / update welcome. It would be great if you could bundle up any other issues that you ran into into a patch or direct update for the building/releasing docs. Phil I will, Phil. But is the non-existence of STATUS.html common to all of commons? If so, I will make the revisions myself. Incidentally, these items are all handled now prior to cutting the release, not as post release items. The STATUS files are a hold-over from the pre-Maven days. They were required because there was no POM / project.xml file in which the committer list could be maintained. Now that all of the components are using Maven, the STATUS files are pretty much obsolete. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Martin. I'll be happy to update the files myself, but where are they? I see some files that look like old versions of the site in commons-build's xdocs but they don't match what's on the site now. I've glanced all over the repository and haven't found the right place yet. The relevant files are in http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/xdocs/releases/ maven site from /commons-build should generate the site locally for you, then maven site:sshdeploy to publish (assuming you have key set up) Make sure to check changes in before updating the site. Thanks! Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Alas and alack. More maven problems. Couldn't run maven site on commons-build Downloaded maven 1.0.2 Reinstalled the maven xdoc plugin 1.9.2 get this: xdoc:jelly-transform: [echo] en [echo] The current Locale is the default one [echo] Scanning '/home/scohen/commons-build/target/generated-xdocs'... [echo] Generating /home/scohen/commons-build/target/docs/license.html from /home/scohen/commons-build/target/generated-xdocs/license.xml BUILD FAILED File.. /home/scohen/.maven/cache/maven-xdoc-plugin-1.9.2/plugin.jelly Element... j:include Line.. 479 Column 58 file:/home/scohen/.maven/cache/maven-xdoc-plugin-1.9.2/plugin-resources/site.jsl:33:17: jsl:stylesheet file:/home/scohen/.maven/cache/maven-xdoc-plugin-1.9.2/plugin-resources/site.jsl:156:57: jsl:applyTemplates file:/home/scohen/.maven/cache/maven-xdoc-plugin-1.9.2/plugin-resources/site.jsl:240:105: maven:property You must define an attribute called 'defaultValue' for this tag. Total time: 10 seconds Finished at: Sun Dec 04 22:09:51 CST 2005 :-( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote][net] Release commons-net 1.4.1?
Steve Cohen wrote: Steve Cohen wrote: Mario Ivankovits wrote: Steve Cohen wrote: It has been discovered that 1.4.0 is inadvertently incompatible with jdk 1.3. Please vote on a release of a fixed version. Checked VFS using net svn head and it works. So here is my +1 BTW: maven builds a 1.5.0 version instead of 1.4.1. Do you plan to release svn head or a patched/rebuild 1.4.0? --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Please disregard my earlier reply. I realize that I misunderstood you. You are, I presume, talking about the version number of net that maven currently builds. This will have to be changed of course. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] As I have little time now, I propose the following. 1.4.1 will be just 1.4.0 with whatever changes are needed to reverse the dependency on jdk 1.4.x. No other bug fixes will be included. Re-vote +1 [yes] -1 [no] I vote +1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The following people voted on release commons-net 1.4.1: Steve Cohen +1 Stefan Bodewig +1 Dion Gilliard +1 Mario Ivankovits +1 Henri Yandell +1 (implied - said if code had already been released, +1, otherwise hold off. Code was in fact in 1.4.0 so +1) robert burrell donkin +1 ( on 12/2 after being -1 on 12/1 and being satisfied with Rory Winston's response to copyright question) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Minimum jdk/jvm version for net ( future ) ( was: Re: [vote][net] Release commons-net 1.4.1? )
We need to discuss this further. Mario Ivankovits VFS is a client of Net and he has users still on 1.3 who are complaining that Net 1.4 breaks VFS. Jeffrey D. Brekke wrote: I understand the issues involved with pending release of vfs and compatibility with net, but I thought we discussed during the last release or so of net that we cut a 1.2/1.3 compatible release and from that release forward we were using 1.4 stuff ( nio I believe was the issue ). So projects that wanted to use net, but required older jvm/class compatibility would use the old version. Maybe I am mistaken though, did we just discuss this and never implement it? Just wondering about the future releases. Is there now a min or max jdk version for all commons projects? Steve Cohen wrote: [SNIPPED] Which is just as well. Because I have another issue. I don't understand the maven.compile.target property. Working from the net 1.4.0 tag, I change only project.properties to set maven.compile.target back to 1.2. Since there are a few places in 1.4.0 that depend on jdk 1.4, my expectation was that changing the project properties would cause the compile to break on those places. But it did not. It compiled successfully. The jdk1.4 compiler creates a class file suitable to run under an earlier JVM, this works as long as you do not use any new api. Then you'll get the NoSuchMethod Exception. Of course, we did use new APIs, so for the purpose I had in mind, this property is useless. This is the reason why we should use the least possible compiler and not only the target attribute. You didnt notice if you use any new api call at compile time. I'll have to dig out a 1.3.1 compiler then. I don't even think 1.2.x is available anymore. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Sheesh, the release process has gotten much hairier since I last did it! 5 hours and I'm still not all the way there. And this was supposed to be a simple release. Phooey. I decided that that easiest way to do this simple release fixing ONLY the 1.3 compatibility problem would be to work from a branch cut at 1_4_0. And that is how I built it. Now however, I get to step 10 Publish updated website and maven is failing. Can this even work when deploying from a branch and not the trunk? $ /opt/maven/bin/maven -Dmaven.username=scohen site:deploy __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc2 Attempting to download commons-net-1.1.0.jar. .. . Attempting to download vdoclet-20020711.jar. . . Attempting to download qdox-current.jar. ... . Attempting to download commons-collections-2.1.jar. .. . Attempting to download logkit-1.0.1.jar. ... . Attempting to download statcvs-xml-0.9.4.jar. .. Attempting to download jdom-b10.jar. . . Attempting to download jfreechart-0.9.20.jar. . . Attempting to download jcommon-0.9.5.jar. ... . Attempting to download commons-jexl-1.0-beta-1.jar. ... . Attempting to download jdepend-2.5.jar. ... . Attempting to download checkstyle-3.3.jar. . . Attempting to download checkstyle-optional-3.3.jar. . . Attempting to download regexp-1.3.jar. ... . Attempting to download commons-beanutils-1.6.1.jar. . . Attempting to download simian-1.9.1.jar. . Attempting to download ant-1.6.jar. . build:start: site:deploy: site: xdoc:register-reports: maven-changes-plugin:register: maven-tasklist-plugin:register: statcvs:init: maven-statcvs-plugin:register: maven-junit-report-plugin:register: maven-jdepend-plugin:register: maven-jcoverage-plugin:register: maven-checkstyle-plugin:register: maven-simian-plugin:register: maven-javadoc-plugin:register: maven-jxr-plugin:register: maven-license-plugin:register: site:run-reports: [echo] Generating the Changes... changes:report: [echo] Generating the Task List... xdoc:init: maven-tasklist-plugin:report:
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Rory Winston wrote: statcvs and svn dont work together (yet)... http://www.researchkitchen.co.uk/blog/archives/13 I just turned off the statcvs report last time. where do you do that? Project.xml? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Thanks guys. statcvs gone. Past that hurdle. Now this one: xdoc:jelly-transform: [echo] Generating /home/scohen/commons-net/branches/NET_1_4_1/target/docs/javadoc.html from /home/scohen/commons-net/branches/NET_1_4_1/target/generated-xdocs/javadoc.xml Could not find the class: org.apache.commons.jelly.tags.fmt.FmtTagLibrary java.lang.ClassNotFoundException: org.apache.commons.jelly.tags.fmt.FmtTagLibrary ... What's up with that? Phil Steitz wrote: Yes, remove the reference to the statcvs report from the reports element. You should obviously also check in the change so the project builds correctly from svn sources. You should have no problem building from branches, tags, etc., as long as commons-build is checked out as a peer. Phil On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Rory Winston wrote: statcvs and svn dont work together (yet)... http://www.researchkitchen.co.uk/blog/archives/13 I just turned off the statcvs report last time. where do you do that? Project.xml? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Nope, 1.6. This is sort of what I meant when I said it's harder to do these releases. How is one supposed to KNOW what versions of these 30 or 40 plugins you have to have in order to build a release? Does Jakarta or Jakarta-commons have a page that tells you the minimum maven setup needed to do a site release? If not, it probably should have. I know this is a dynamic process, but this is nuts. And then the other direction. I shudder to think what would have happened if I had tried maven 2.0. Hate to be an old fart here but was ant really all that bad? Anyway, the site is deployed. It's gradually pushing itself out to all the servers. Phil Steitz wrote: You need to make sure you are running version 1.9.2 of the maven xdoc plugin. maven plugin:install maven maven-xdoc-plugin 1.9.2 Phil On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Thanks guys. statcvs gone. Past that hurdle. Now this one: xdoc:jelly-transform: [echo] Generating /home/scohen/commons-net/branches/NET_1_4_1/target/docs/javadoc.html from /home/scohen/commons-net/branches/NET_1_4_1/target/generated-xdocs/javadoc.xml Could not find the class: org.apache.commons.jelly.tags.fmt.FmtTagLibrary java.lang.ClassNotFoundException: org.apache.commons.jelly.tags.fmt.FmtTagLibrary ... What's up with that? Phil Steitz wrote: Yes, remove the reference to the statcvs report from the reports element. You should obviously also check in the change so the project builds correctly from svn sources. You should have no problem building from branches, tags, etc., as long as commons-build is checked out as a peer. Phil On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Rory Winston wrote: statcvs and svn dont work together (yet)... http://www.researchkitchen.co.uk/blog/archives/13 I just turned off the statcvs report last time. where do you do that? Project.xml? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
okay, made it down to step 12 now. * Update Jakarta News Page Add a standard news item announcing the release to the current Jakarta news page. Look for the page whose name covers today's date in the site/xdocs/site/news directory. For example, the news for a release created in July 2004 should go into news-2004-2ndHalf.xml. This should be similar to the announcement you'll post later to email lists. Please remember to include a description of your component. Please also add a reminder about verifying signature. * Jakarta Welcome Page News items on the Jakarta welcome page are now automatically generated when you run ant to build the HTML files. However, there is no such file since 2nd quarter of 2005, and the index.xml mentions that this has now been retired, and the apache site now asks you to subscribe to a mailing list for Apache news. Am I right then in thinking that the second part of section 12 (quoted above) is now null and void? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Pls disregard. I figured it out. Steve Cohen wrote: okay, made it down to step 12 now. * Update Jakarta News Page Add a standard news item announcing the release to the current Jakarta news page. Look for the page whose name covers today's date in the site/xdocs/site/news directory. For example, the news for a release created in July 2004 should go into news-2004-2ndHalf.xml. This should be similar to the announcement you'll post later to email lists. Please remember to include a description of your component. Please also add a reminder about verifying signature. * Jakarta Welcome Page News items on the Jakarta welcome page are now automatically generated when you run ant to build the HTML files. However, there is no such file since 2nd quarter of 2005, and the index.xml mentions that this has now been retired, and the apache site now asks you to subscribe to a mailing list for Apache news. Am I right then in thinking that the second part of section 12 (quoted above) is now null and void? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Phil Steitz wrote: On 12/3/05, Martin Cooper [EMAIL PROTECTED] wrote: On 12/3/05, Phil Steitz [EMAIL PROTECTED] wrote: On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Nope, 1.6. This is sort of what I meant when I said it's harder to do these releases. How is one supposed to KNOW what versions of these 30 or 40 plugins you have to have in order to build a release? Does Jakarta or Jakarta-commons have a page that tells you the minimum maven setup needed to do a site release? If not, it probably should have. I know this is a dynamic process, but this is nuts. Good point. Right now http://jakarta.apache.org/commons/building.html just contains the statement Be sure to follow the instructions for upgrading the plugins to the latest releases. Is it just me going blind, or are those instructions missing? All I see is a link to a page that has a big list of plugins. I don't see instructions on upgrading my plugins. ;-( We could either doc the full set there or check in the output of maven --info as a text file in commons-build, making changes to that as necessary. I would recommend the second option, with a link on the building page. I will do that if no one beats me to it. +1 to the second option. +1000 to a script that will automatically update my Maven installation with those versions of the plugins. ;-) hmmm...I have a bash script ;-) It just consists of a bunch of lines like this: maven plugin:download -DgroupId=maven -DartifactId=maven-ant-plugin -Dversion=1.9 maven plugin:download -DgroupId=maven -DartifactId=maven-artifact-plugin -Dversion=1.5.2 ... Another thing that might work would be to add explicit dependencies to the required versions in commons-build's project.xml. Then executing even the clean target there would make maven download and install them all. I will play with this and if it works, just commit the change there and change the docs to recommend this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] that would be a big help, thank you very much. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Yes, thanks, fixed it now. Rahul Akolkar wrote: On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Pls disregard. I figured it out. snip/ Yup, noticed that as I clicked send to the earlier email. I think you've a typo, the id for the net 1.4.1 news item should be 20051203.1 (instead of 2005203.1) -Rahul Steve Cohen wrote: okay, made it down to step 12 now. snap/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HELP! - WAS: Re: [vote][net] Release commons-net 1.4.1?
Wow, who would have thought the smallest of releases would produce this much email traffic??? Dennis Lundberg wrote: Phil Steitz wrote: On 12/3/05, Martin Cooper [EMAIL PROTECTED] wrote: On 12/3/05, Phil Steitz [EMAIL PROTECTED] wrote: On 12/3/05, Steve Cohen [EMAIL PROTECTED] wrote: Nope, 1.6. This is sort of what I meant when I said it's harder to do these releases. How is one supposed to KNOW what versions of these 30 or 40 plugins you have to have in order to build a release? Does Jakarta or Jakarta-commons have a page that tells you the minimum maven setup needed to do a site release? If not, it probably should have. I know this is a dynamic process, but this is nuts. Good point. Right now http://jakarta.apache.org/commons/building.html just contains the statement Be sure to follow the instructions for upgrading the plugins to the latest releases. Is it just me going blind, or are those instructions missing? All I see is a link to a page that has a big list of plugins. I don't see instructions on upgrading my plugins. ;-( We could either doc the full set there or check in the output of maven --info as a text file in commons-build, making changes to that as necessary. I would recommend the second option, with a link on the building page. I will do that if no one beats me to it. +1 to the second option. +1000 to a script that will automatically update my Maven installation with those versions of the plugins. ;-) hmmm...I have a bash script ;-) It just consists of a bunch of lines like this: maven plugin:download -DgroupId=maven -DartifactId=maven-ant-plugin -Dversion=1.9 maven plugin:download -DgroupId=maven -DartifactId=maven-artifact-plugin -Dversion=1.5.2 ... Another thing that might work would be to add explicit dependencies to the required versions in commons-build's project.xml. Then executing even the clean target there would make maven download and install them all. I will play with this and if it works, just commit the change there and change the docs to recommend this. Not sure if putting a dependency on a plugin works in Maven 1, I know it works in Maven 2. It would be great if it does though. I'm putting together a patch for http://jakarta.apache.org/commons/building.html on how to install plugins manually. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote][net] Release commons-net 1.4.1?
Mario Ivankovits wrote: Steve Cohen wrote: The thread Robert refers to has the subject Re: Does Apache have agreement to use other open source code outside of Apache? Has this something to do with an email from IBM in the last few days asking me if I am really was the creator of my contributions? Not that I made any mistake (I guess this was a mail to all commons-net developers), but I was a little bit irritated. Hmm. Sounds like it. Although I got no such email myself, I only saw it on the PMC Mailing List. Which is just as well. Because I have another issue. I don't understand the maven.compile.target property. Working from the net 1.4.0 tag, I change only project.properties to set maven.compile.target back to 1.2. Since there are a few places in 1.4.0 that depend on jdk 1.4, my expectation was that changing the project properties would cause the compile to break on those places. But it did not. It compiled successfully. The jdk1.4 compiler creates a class file suitable to run under an earlier JVM, this works as long as you do not use any new api. Then you'll get the NoSuchMethod Exception. Of course, we did use new APIs, so for the purpose I had in mind, this property is useless. This is the reason why we should use the least possible compiler and not only the target attribute. You didnt notice if you use any new api call at compile time. I'll have to dig out a 1.3.1 compiler then. I don't even think 1.2.x is available anymore. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote][net] Release commons-net 1.4.1?
Henri Yandell wrote: On 12/2/05, robert burrell donkin [EMAIL PROTECTED] wrote: this culture needs to change: there are still too few people nominating new pmc'ers. IMHO it is an important part of the responsibility that comes with nominating someone as a committer that you will guide them through the first few weeks or months as a committer and (when they are ready) nominate them for the pmc. the progression from committers to pmc'er should be natural and relatively quick. definitely, all release managers should be pmc'ers. anyone who knows enough about apache to manage a release should be on the pmc. It's the wrong list, ie) should be on general@, but I'm thinking that we should just set in stone a date at which point a new committer is listed on the pmc list and asked if they should be on the pmc (to the person nominating them as committers). So let's say Robert becomes a committer today. This would be noted in a file. In 6-9 months time (ie when the chair does the report), any 6 month old committers would involve a question to the person nominating them as committers as to why they shouldn't be nominated. So culture change. One in which people are challenged to exclude, not expected to remember to include. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hen: This is a valuable discussion but perhaps we need a different subject for the thread? To get back to the original subject matter: It looks as though Rory was pretty well able to resolve the questions about the provenance of his code, although, I understand the lawyers may still want to look a little closer. Do you have any idea when this cloudlet might be lifted and we can contemplate a release? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote][net] Release commons-net 1.4.1?
robert burrell donkin wrote: -1 to any commons-net new release. see pmc thread for details (if any committers aren't on the pmc please shout and i'll nominate you) - robert On Thu, 2005-12-01 at 07:47 +0100, Mario Ivankovits wrote: Steve Cohen wrote: As I have little time now, I propose the following. 1.4.1 will be just 1.4.0 with whatever changes are needed to reverse the dependency on jdk 1.4.x. No other bug fixes will be included. Re-vote +1 [yes] -1 [no] +1 --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] OK. Robert is referring to a serious issue here. It's prudent to wait. There are questions about copyright on one of our classes. The thread Robert refers to has the subject Re: Does Apache have agreement to use other open source code outside of Apache? and it's all in the last couple of days. So we have to wait. Which is just as well. Because I have another issue. I don't understand the maven.compile.target property. Working from the net 1.4.0 tag, I change only project.properties to set maven.compile.target back to 1.2. Since there are a few places in 1.4.0 that depend on jdk 1.4, my expectation was that changing the project properties would cause the compile to break on those places. But it did not. It compiled successfully. Why wouldn't it break? Can someone explain how this works? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote][net] Release commons-net 1.4.1?
Steve Cohen wrote: Mario Ivankovits wrote: Steve Cohen wrote: It has been discovered that 1.4.0 is inadvertently incompatible with jdk 1.3. Please vote on a release of a fixed version. Checked VFS using net svn head and it works. So here is my +1 BTW: maven builds a 1.5.0 version instead of 1.4.1. Do you plan to release svn head or a patched/rebuild 1.4.0? --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Please disregard my earlier reply. I realize that I misunderstood you. You are, I presume, talking about the version number of net that maven currently builds. This will have to be changed of course. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] As I have little time now, I propose the following. 1.4.1 will be just 1.4.0 with whatever changes are needed to reverse the dependency on jdk 1.4.x. No other bug fixes will be included. Re-vote +1 [yes] -1 [no] I vote +1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote][net] Release commons-net 1.4.1?
Mario Ivankovits wrote: Steve Cohen wrote: It has been discovered that 1.4.0 is inadvertently incompatible with jdk 1.3. Please vote on a release of a fixed version. Checked VFS using net svn head and it works. So here is my +1 BTW: maven builds a 1.5.0 version instead of 1.4.1. Do you plan to release svn head or a patched/rebuild 1.4.0? --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I suppose a head release. There are a few bugs fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote][net] Release commons-net 1.4.1?
Mario Ivankovits wrote: Steve Cohen wrote: It has been discovered that 1.4.0 is inadvertently incompatible with jdk 1.3. Please vote on a release of a fixed version. Checked VFS using net svn head and it works. So here is my +1 BTW: maven builds a 1.5.0 version instead of 1.4.1. Do you plan to release svn head or a patched/rebuild 1.4.0? --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Please disregard my earlier reply. I realize that I misunderstood you. You are, I presume, talking about the version number of net that maven currently builds. This will have to be changed of course. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] new release to solve target 1.4 problem
Mario Ivankovits wrote: Steve Cohen wrote: Dion Gillard wrote: I'm +1 on either a re-release or a 1.4.1 release. +1 Who will do it? I can, I guess. Is there some progress on this? Is there anything I can do to help? --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I've been busy. Let's take an official vote. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vote][net] Release commons-net 1.4.1?
It has been discovered that 1.4.0 is inadvertently incompatible with jdk 1.3. Please vote on a release of a fixed version. I'll start it off +1 I will also volunteer to do the release but it won't be until next week at the earliest. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] new release to solve target 1.4 problem
Dion Gillard wrote: I'm +1 on either a re-release or a 1.4.1 release. On 11/14/05, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi [NET]! Is it possible to get a new release build with jdk 1.3 out soon? The VFS release 1.0 is blocked due to the incompatible class format (net were build using target 1.4) If possible I dont want to start tempering the bootclasspath (http://jroller.com/page/scolebourne?entry=compiling_for_older_jdks) just to cleanly solve it on my side. Thanks! --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ You are going to let the fear of poverty govern your life and your reward will be that you will eat, but you will not live. - George Bernard Shaw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +1 Who will do it? I can, I guess. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] class file has wrong version 48.0, should be 47.0
Simon Kitching wrote: On Mon, 2005-11-07 at 06:03 -0800, fiji kalathil wrote: Hi, i am using commons-net-1.4.0.jar in my proj i am getting the followinf compilation error src/com/covad/ccbi/operations/InfBillingOps.java:5347: cannot access org.apache.commons.net.ftp.FTPClient [javac] bad class file: /home/fkp/DECEMBER-2005-dev/ccbi/lib/jakarta/commons-net-1.4.0.jar(org/apache/commons/net/ftp/FTPClient.class) [javac] class file has wrong version 48.0, should be 47.0 [javac] Please remove or make sure it appears in the correct subdirectory of the classpath. [javac] FTPClient ftp = new FTPClient(); Looks like the 1.4.0 release of commons-net was compiled using (or targeting) java 1.4 but you're using java 1.3. I suggest you check the release documentation to see whether the project explicitly requires java 1.4. If not, it might be a mistake; it's happened from time to time. You could always try downloading the source and recompiling with java 1.3; most jakarta projects can be built pretty easily. BTW, when posting to this list please put the project name in the subject, eg [net] class file has wrong version. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] You are correct, Simon. There WAS a bug reported in 1.4.0 around this. commons-net is NOT targeted at 1.4 and this somehow slipped through. We have not done a release and maybe we should for this. However, I'm not entirely sure how you are inferring that the problem here is 1.3 vs. 1.4. You may know something I don't. I'm not sure where the version 48.0 vs 47.0 is coming from. I've never seen that before. This user could try getting the nightly build and see if that fixes his problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] ftp and hidden files in directory listing
Mario Ivankovits wrote: Hi! Here is what I got from an VFS user: I have one last quesion that I wanted to ask to one of the Commons Net developpers because it does not appears in the FAQ I read. Here it is : We are using the library to access a FTP server running under Windows and when we list the files in a directory, read only files are not listed ! In fact, is the list method of the FTPClient was issuing an ls -a command then the library would receive all the list. Here it seems that it issues only an ls -l command. Is there a way to say which command should be used when using the list method ? or should we build ourselves the command string, then send it to the server, and parse the results list ? What options do I have to issue a LIST -a instead of LIST? Or are you interesed in an patch which adds a method FTPClient.setListHiddenFiles()? Thanks! Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hmm. This is a new issue and should probably be logged as such. I wasn't aware that FTP under windows behaved that way. Under unix, files are listed without regard to permission. And read-only files are not the same thing as hidden files (although Windows FTP may be treating them as such). Sounds like a bug in Windows FTP. Is there a way to retrieve hidden files separately from read-only? This issue requires further discussion although we would be interested in your patch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] class file has wrong version 48.0, should be 47.0
Mario Ivankovits wrote: Hi! However, I'm not entirely sure how you are inferring that the problem here is 1.3 vs. 1.4. You may know something I don't. I'm not sure where the version 48.0 vs 47.0 is coming from. I've never seen that before. This happens if you compile with javac target=1.4 but running it in an java 1.3 environment. If I remember correctly java 5.0 is version 49.0 To be safe for the future you could use target=1.3 for your javac command. So as long as you do not use a 1.4 api you should be safe. Maven - project.properties: maven.compile.target = 1.3 maven.compile.source = 1.3 --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Good idea! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] class file has wrong version 48.0, should be 47.0
Mario Ivankovits wrote: For details: http://www.javaworld.com/javaqa/2003-05/02-qa-0523-version-p2.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Wow, as long as I'm in this game there's still stuff to learn. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Found and fixed a bug in FTPClient class in Commons Net project.
Daniel F. Savarese wrote: In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes: I downloaded the source code and found the problem. It's in getSystemName method of FTPClient class in Commons Net project. The reason is that for some system, such as HP's NonStop (Tandem) platform, SYST command is not understood, so __systemName will be null thus causing the error above. The proper place to handle this would be in the caller to getSystemName, otherwise you will never be able to know that the system name is unknown. The documentaton for getSystemName() says: * @return The system type name obtained from the server. null if the * information could not be obtained. In other words, it is intended to return null. It is up to the caller to decide what to do with the information. If there's a need for a change, I would suggest making it higher up in the call chain. Steve would know best if there's any need. My guess is that the intent is for API users to catch that ParserInitializationException and select a default parser according their needs instead of having Commons Net make the decision for them. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Correct, Daniel. Suppose there were some other system that didn't answer the SYST command which did not act like a UNIX server? Then we'd be leading the user down the wrong path. Bing Wu does not say which version of commons-net he/she is using. I might suggest that Bugzilla would be appropriate for such issues as this - it will force you to say what version. But the point of the version question is that commons-net 1.4.0 (the latest version) offers a way out of this problem: check out the FTPClientConfig class. By specifying in advance the system type as UNIX, which, in this case you know to be the case, you completely unhook from dependence on the autodetection scheme which requires getSystemName() and simply assume UNIX. This is what you want. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Found and fixed a bug in FTPClient class in Commons Net project.
The latest version of ant - (from CVS or nightly build - will not be released until ant 1.7) has support for this feature. [EMAIL PROTECTED] wrote: It makes sense for your explanation. It didn't work for HP's NonStop (Tandem) platform, which is unfortunately the one I am working on, so I made that quick fix. It's up to you guys to decide what's the best. From what you are saying, it seems to me that API caller, such as Ant for my case, needs to make a fix. Thanks! Bing Daniel F. Savarese [EMAIL PROTECTED] 07/08/2005 01:08 AM Please respond to Jakarta Commons Developers List To: commons-dev@jakarta.apache.org cc: Subject:Re: [net] Found and fixed a bug in FTPClient class in Commons Net project. In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes: I downloaded the source code and found the problem. It's in getSystemName method of FTPClient class in Commons Net project. The reason is that for some system, such as HP's NonStop (Tandem) platform, SYST command is not understood, so __systemName will be null thus causing the error above. The proper place to handle this would be in the caller to getSystemName, otherwise you will never be able to know that the system name is unknown. The documentaton for getSystemName() says: * @return The system type name obtained from the server. null if the * information could not be obtained. In other words, it is intended to return null. It is up to the caller to decide what to do with the information. If there's a need for a change, I would suggest making it higher up in the call chain. Steve would know best if there's any need. My guess is that the intent is for API users to catch that ParserInitializationException and select a default parser according their needs instead of having Commons Net make the decision for them. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- IMPORTANT NOTIFICATION --- The contents of this e-mail and its attachments are confidential and may be privileged. If you are not the intended recipient of this e-mail, please notify IDX immediately (by return e-mail to either the sender or [EMAIL PROTECTED]), destroy all copies of this message along with any attachments and do not disclose, copy and/or distribute the contents. The views expressed in this message are those of the author and not necessarily those of IDX. In the absence of a prior written agreement with you authorizing commitments of IDX via e-mail, the above message shall not bind IDX, unless from a duly authorized officer of the company in a context indicating an intention to bind the company. This e-mail and its attachments are protected by copyright and other laws. (c) IDX Systems Corporation 2005. All rights reserved. IDX is a registered trademark of IDX Investment Corporation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] Commons-Net 1.4.0 Released
Rory Winston wrote: The Commons-Net team are pleased to announce the release of version 1.4.0. This release provides several fixes and enhancements, including: - The addition of a new configuration mechanism that enables the FTPClient component to work with a much larger range of server formats and locales; - The addition of missing NTP unit tests; - The addition of a new FTP parser implementation for MVS; - Various fixes to the TFPClient and NTPClient components A list of changes can be found at http://jakarta.apache.org/commons/net/changes-report.html#1_4_0 _ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Rory, for getting this out! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] Commons-Net 1.4.0 Released [net]
Rory Winston wrote: The Commons-Net team are pleased to announce the release of version 1.4.0. This release provides several fixes and enhancements, including: - The addition of a new configuration mechanism that enables the FTPClient component to work with a much larger range of server formats and locales; - The addition of missing NTP unit tests; - The addition of a new FTP parser implementation for MVS; - Various fixes to the TFPClient and NTPClient components A list of changes can be found at http://jakarta.apache.org/commons/net/changes-report.html#1_4_0 _ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Rory, could we change the release notes slightly for 1.4.0? I think your description of the date format changes doesn't really give the flavor of what's involved here. This bit from the FTPClientConfig javadoc is a fuller description: Use cases: You are trying to access a server that * lists files with timestamps that use month names in languages other than English * lists files with timestamps that use date formats other than the American English standard MM dd * is in different timezone and you need accurate timestamps for dependency checking as in Ant and I would now add a fourth * supports the new all-numeric date formats now being used on the ftp servers distributed with some newer Linux distributions. (That fourth one was really a defect that was never logged as such but communicated on the list about a month ago). Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release Commons-Net 1.4.0
Rory Winston wrote: I have cut a RC of Commons-Net 1.4.0. If anyone has no objections, I would like to cut a release in the next couple of weeks. The main thrust behind this release is the FTPClientConfig infractructure added by Steve. I honestly believe that this addition (plus an extra parser for MVS FTP servers) makes the FTP client one of the very best out there. There are also some miscellanous bug fixes and NTP unit tests added. The RC is here: http://people.apache.org/~rwinston/commons-net-1.4.0-dev.jar Here's my: +1 _ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +1 Sorry not to have voted earlier but this didn't make it to my Net folder and I wasn't paying attention. (No [net], I suppose, in the message subject. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] available() returns 0 in Unit Test
Rory Winston wrote: When I was cutting the RC for Commons::Net, the TelnetClientTest repeatedly failed. I tracked this down to the line: if(is1.available() == 6) The available() method continually returned 0. When I commented out the available() check, the test passed as expected. I compiled with Java 5. The issue is that the test expected the socket's InputStream to return the #bytes queued up (6), whereas it actually returned 0, but it still read the bytes correctly on a read(). Anyone know if this is expected/reasonable behaviour? I havent looked into it yet, but if anyone has any insight, it would be appreciated. Cheers Rory _ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Using J2SDK 1.4.2_07-b05 on Linux both for compiling and running, the test passes. What platform are you using? However, I think the real culprit may turn out to be 1.5. Have you tried a 1.4 JDK? Are there any commons standards about what JDK a binary distribution should have been compiled with? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP client date parsing: new format
Rory Winston wrote: Steve, Well done and good work with the latest changes that you have applied. I think that we're getting to a 1.4 release stage very quickly. Cheers Rory With my latest work in bugzilla, I believe that we have no currently open bugs. There were two. One was a duplicate of a recently fixed bug and the other I marked WONTFIX as I don't believe it is a bug at all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP client date parsing: new format
I'm sorry, you're right again. IWhen you first wrote me about the numeric date I assumed that the new system just happened to handle it, without bothering to look at the regex that decided what the date parser must parse. Then when I hadn't heard from you for awhile, I thought we were over this hump. But yes, this is a problem, and it looks as if Rory's fix is a good one. I will add some junit test cases to verify this. Neeme Praks wrote: AFAIK, the new system uses both: regexp for extracting the timestamp from the entry line and then using DateFormat to parse that. Example: -rw-r--r--1 1000 1000 27 Jan 24 11:31 messages.vsp from this line the regexp extracts the timestamp part (Jan 24 11:31) and then DateFormat is used to parse this to a valid Date object. The issue here is that the failure is already at regexp matching, and the code never reaches the DateFormat parsing part. I'll try to check out Rory's changes during the weekend. Rgds, Neeme Steve Cohen wrote: No, that's not it at all. Remember that the new system does not use Regexes for date parsing, it uses SimpleDateFormats. From Mr. Praks' descriptions, I am assuming he's now running the 1.3 or earlier versions, which do use regexes. This surprises me because I've had several conversations with him over the past month in which the new system was discussed. Perhaps he forgot to specify the date format as /MM/dd in his FTPClientConfig this time? Or perhaps his code is finding an older commons-net.jar than he was expecting? Steve Cohen Rory Winston wrote: Right, the problem with this format is that the date is not composed of three discrete components (from a regex POV), but two. Basically what we will need to do is expand the regex to handle thuis - can you give me details of the FTP server operating system and FTP server software version if you have it please. Cheers Rory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP client date parsing: new format
However, I think if you attempt to take your good example and add it to the JUnit tests, (as I just did) you will see that Rory's fix is not sufficient. Yes, it correctly grabs the date string but it doesn't parse it properly because the default UnixFTPEntryParser is still assuming that a standard date format is being used. This shouldn't bother you if you are using FTPClientConfig, but it does mean that we can't capture this use case in JUnit tests, which, as previous experience shows, is important to do. As for your symbolic links issue, this is a new issue. Can you please write it up in bugzilla? Neeme Praks wrote: ok, now I checked out the recent changes and the fix seems to work, at least in the case of usual files: -rw-r- 1 neeme neeme 346 2005-04-08 11:22 services.vsp is parsed into: typeStr=- hardLinkCount=1 usr=neeme grp=neeme filesize=346 datestr=2005-04-08 11:22 name=services.vsp endtoken= And this is correct. However, it still breaks in the case of symbolic links. So, if the entry is a symbolic link: lrwxrwxrwx 1 neeme neeme23 2005-03-02 18:06 macros - ./../../global/macros/. then it is parsed into these variables: typeStr=l hardLinkCount=1 usr=neeme grp=neeme filesize=23 datestr=2005-03-02 18:06 macros name=- endtoken= ../../../global/macros/ The ending of - ../../../global/macros/ seems to confuse the regexp parser. And to answer Rorys question about the specifics of the FTP server, I'll paste one of my earlier posts here: This format is from the default FTP server daemon configuration that came with Debian: Connected to stf. 220 stf FTP server (Version 6.4/OpenBSD/Linux-ftpd-0.17) ready. Name (stf:neeme): neeme 331 Password required for neeme. Password: 230- Linux stf 2.6.11 #1 SMP Wed Mar 2 14:08:21 CET 2005 i686 GNU/Linux 230- 230- The programs included with the Debian GNU/Linux system are free software; 230- the exact distribution terms for each program are described in the 230- individual files in /usr/share/doc/*/copyright. 230- 230- Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent 230- permitted by applicable law. 230 User neeme logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp Rgds, Neeme Neeme Praks wrote: AFAIK, the new system uses both: regexp for extracting the timestamp from the entry line and then using DateFormat to parse that. Example: -rw-r--r--1 1000 1000 27 Jan 24 11:31 messages.vsp from this line the regexp extracts the timestamp part (Jan 24 11:31) and then DateFormat is used to parse this to a valid Date object. The issue here is that the failure is already at regexp matching, and the code never reaches the DateFormat parsing part. I'll try to check out Rory's changes during the weekend. Rgds, Neeme Steve Cohen wrote: No, that's not it at all. Remember that the new system does not use Regexes for date parsing, it uses SimpleDateFormats. From Mr. Praks' descriptions, I am assuming he's now running the 1.3 or earlier versions, which do use regexes. This surprises me because I've had several conversations with him over the past month in which the new system was discussed. Perhaps he forgot to specify the date format as /MM/dd in his FTPClientConfig this time? Or perhaps his code is finding an older commons-net.jar than he was expecting? Steve Cohen Rory Winston wrote: Right, the problem with this format is that the date is not composed of three discrete components (from a regex POV), but two. Basically what we will need to do is expand the regex to handle thuis - can you give me details of the FTP server operating system and FTP server software version if you have it please. Cheers Rory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP client date parsing: new format
I was incorrect again about the symbolic link thing being separate. It's related to the two-part date. Steve Cohen wrote: However, I think if you attempt to take your good example and add it to the JUnit tests, (as I just did) you will see that Rory's fix is not sufficient. Yes, it correctly grabs the date string but it doesn't parse it properly because the default UnixFTPEntryParser is still assuming that a standard date format is being used. This shouldn't bother you if you are using FTPClientConfig, but it does mean that we can't capture this use case in JUnit tests, which, as previous experience shows, is important to do. As for your symbolic links issue, this is a new issue. Can you please write it up in bugzilla? Neeme Praks wrote: ok, now I checked out the recent changes and the fix seems to work, at least in the case of usual files: -rw-r- 1 neeme neeme 346 2005-04-08 11:22 services.vsp is parsed into: typeStr=- hardLinkCount=1 usr=neeme grp=neeme filesize=346 datestr=2005-04-08 11:22 name=services.vsp endtoken= And this is correct. However, it still breaks in the case of symbolic links. So, if the entry is a symbolic link: lrwxrwxrwx 1 neeme neeme23 2005-03-02 18:06 macros - ./../../global/macros/. then it is parsed into these variables: typeStr=l hardLinkCount=1 usr=neeme grp=neeme filesize=23 datestr=2005-03-02 18:06 macros name=- endtoken= ../../../global/macros/ The ending of - ../../../global/macros/ seems to confuse the regexp parser. And to answer Rorys question about the specifics of the FTP server, I'll paste one of my earlier posts here: This format is from the default FTP server daemon configuration that came with Debian: Connected to stf. 220 stf FTP server (Version 6.4/OpenBSD/Linux-ftpd-0.17) ready. Name (stf:neeme): neeme 331 Password required for neeme. Password: 230- Linux stf 2.6.11 #1 SMP Wed Mar 2 14:08:21 CET 2005 i686 GNU/Linux 230- 230- The programs included with the Debian GNU/Linux system are free software; 230- the exact distribution terms for each program are described in the 230- individual files in /usr/share/doc/*/copyright. 230- 230- Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent 230- permitted by applicable law. 230 User neeme logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp Rgds, Neeme Neeme Praks wrote: AFAIK, the new system uses both: regexp for extracting the timestamp from the entry line and then using DateFormat to parse that. Example: -rw-r--r--1 1000 1000 27 Jan 24 11:31 messages.vsp from this line the regexp extracts the timestamp part (Jan 24 11:31) and then DateFormat is used to parse this to a valid Date object. The issue here is that the failure is already at regexp matching, and the code never reaches the DateFormat parsing part. I'll try to check out Rory's changes during the weekend. Rgds, Neeme Steve Cohen wrote: No, that's not it at all. Remember that the new system does not use Regexes for date parsing, it uses SimpleDateFormats. From Mr. Praks' descriptions, I am assuming he's now running the 1.3 or earlier versions, which do use regexes. This surprises me because I've had several conversations with him over the past month in which the new system was discussed. Perhaps he forgot to specify the date format as /MM/dd in his FTPClientConfig this time? Or perhaps his code is finding an older commons-net.jar than he was expecting? Steve Cohen Rory Winston wrote: Right, the problem with this format is that the date is not composed of three discrete components (from a regex POV), but two. Basically what we will need to do is expand the regex to handle thuis - can you give me details of the FTP server operating system and FTP server software version if you have it please. Cheers Rory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP client date parsing: new format
Sorry for being a bit brusque before but if you check out the latest code I think you will find that with Rory's and my changes, your issues are cared for. Neeme Praks wrote: ok, now I checked out the recent changes and the fix seems to work, at least in the case of usual files: -rw-r- 1 neeme neeme 346 2005-04-08 11:22 services.vsp is parsed into: typeStr=- hardLinkCount=1 usr=neeme grp=neeme filesize=346 datestr=2005-04-08 11:22 name=services.vsp endtoken= And this is correct. However, it still breaks in the case of symbolic links. So, if the entry is a symbolic link: lrwxrwxrwx 1 neeme neeme23 2005-03-02 18:06 macros - ./../../global/macros/. then it is parsed into these variables: typeStr=l hardLinkCount=1 usr=neeme grp=neeme filesize=23 datestr=2005-03-02 18:06 macros name=- endtoken= ../../../global/macros/ The ending of - ../../../global/macros/ seems to confuse the regexp parser. And to answer Rorys question about the specifics of the FTP server, I'll paste one of my earlier posts here: This format is from the default FTP server daemon configuration that came with Debian: Connected to stf. 220 stf FTP server (Version 6.4/OpenBSD/Linux-ftpd-0.17) ready. Name (stf:neeme): neeme 331 Password required for neeme. Password: 230- Linux stf 2.6.11 #1 SMP Wed Mar 2 14:08:21 CET 2005 i686 GNU/Linux 230- 230- The programs included with the Debian GNU/Linux system are free software; 230- the exact distribution terms for each program are described in the 230- individual files in /usr/share/doc/*/copyright. 230- 230- Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent 230- permitted by applicable law. 230 User neeme logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp Rgds, Neeme Neeme Praks wrote: AFAIK, the new system uses both: regexp for extracting the timestamp from the entry line and then using DateFormat to parse that. Example: -rw-r--r--1 1000 1000 27 Jan 24 11:31 messages.vsp from this line the regexp extracts the timestamp part (Jan 24 11:31) and then DateFormat is used to parse this to a valid Date object. The issue here is that the failure is already at regexp matching, and the code never reaches the DateFormat parsing part. I'll try to check out Rory's changes during the weekend. Rgds, Neeme Steve Cohen wrote: No, that's not it at all. Remember that the new system does not use Regexes for date parsing, it uses SimpleDateFormats. From Mr. Praks' descriptions, I am assuming he's now running the 1.3 or earlier versions, which do use regexes. This surprises me because I've had several conversations with him over the past month in which the new system was discussed. Perhaps he forgot to specify the date format as /MM/dd in his FTPClientConfig this time? Or perhaps his code is finding an older commons-net.jar than he was expecting? Steve Cohen Rory Winston wrote: Right, the problem with this format is that the date is not composed of three discrete components (from a regex POV), but two. Basically what we will need to do is expand the regex to handle thuis - can you give me details of the FTP server operating system and FTP server software version if you have it please. Cheers Rory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP client date parsing: new format
Okay, we've solved the immediate issues here but I'm not totally satisfied yet. The problem is that the numeric date format has introduced a new logical possibility. Formerly it was simple and clear - either with the default or recent date formats there were always THREE whitespace-separated components of the date (month day year OR month day time). The newly-introduced numeric date format in unix ftp servers (about time, by the way) adds a new possibility of a timestamp composed of TWO whitespace-separated components. But until this becomes widespread and probably forever, we'll have to maintain backward compatibility with the older non-numeric formats. Making the third token optional is reasonable, but as we have seen, Neeme's find of the symbolic link case defeats this simple attempt at a fix. With the two-or-three token date, it is possible that the regex engine will find an extra token later on and screw up the logic. My current solution relies on the fact that a unix filename is not supposed to start with a hyphen. ([^-\\s]\\S*) So -, the symlink indicator, will not be mistaken for a filename. But that still doesn't feel solid enough. I would feel better if we had a more solid regex that clearly captured what is and what is not a legal unix filename. Googling did not find an immediate answer to this questions, nor did I find one in Jeffrey Friedl's Mastering Regular Expressions book. Does anyone have one? Steve Cohen wrote: Sorry for being a bit brusque before but if you check out the latest code I think you will find that with Rory's and my changes, your issues are cared for. Neeme Praks wrote: ok, now I checked out the recent changes and the fix seems to work, at least in the case of usual files: -rw-r- 1 neeme neeme 346 2005-04-08 11:22 services.vsp is parsed into: typeStr=- hardLinkCount=1 usr=neeme grp=neeme filesize=346 datestr=2005-04-08 11:22 name=services.vsp endtoken= And this is correct. However, it still breaks in the case of symbolic links. So, if the entry is a symbolic link: lrwxrwxrwx 1 neeme neeme23 2005-03-02 18:06 macros - ./../../global/macros/. then it is parsed into these variables: typeStr=l hardLinkCount=1 usr=neeme grp=neeme filesize=23 datestr=2005-03-02 18:06 macros name=- endtoken= ../../../global/macros/ The ending of - ../../../global/macros/ seems to confuse the regexp parser. And to answer Rorys question about the specifics of the FTP server, I'll paste one of my earlier posts here: This format is from the default FTP server daemon configuration that came with Debian: Connected to stf. 220 stf FTP server (Version 6.4/OpenBSD/Linux-ftpd-0.17) ready. Name (stf:neeme): neeme 331 Password required for neeme. Password: 230- Linux stf 2.6.11 #1 SMP Wed Mar 2 14:08:21 CET 2005 i686 GNU/Linux 230- 230- The programs included with the Debian GNU/Linux system are free software; 230- the exact distribution terms for each program are described in the 230- individual files in /usr/share/doc/*/copyright. 230- 230- Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent 230- permitted by applicable law. 230 User neeme logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp Rgds, Neeme Neeme Praks wrote: AFAIK, the new system uses both: regexp for extracting the timestamp from the entry line and then using DateFormat to parse that. Example: -rw-r--r--1 1000 1000 27 Jan 24 11:31 messages.vsp from this line the regexp extracts the timestamp part (Jan 24 11:31) and then DateFormat is used to parse this to a valid Date object. The issue here is that the failure is already at regexp matching, and the code never reaches the DateFormat parsing part. I'll try to check out Rory's changes during the weekend. Rgds, Neeme Steve Cohen wrote: No, that's not it at all. Remember that the new system does not use Regexes for date parsing, it uses SimpleDateFormats. From Mr. Praks' descriptions, I am assuming he's now running the 1.3 or earlier versions, which do use regexes. This surprises me because I've had several conversations with him over the past month in which the new system was discussed. Perhaps he forgot to specify the date format as /MM/dd in his FTPClientConfig this time? Or perhaps his code is finding an older commons-net.jar than he was expecting? Steve Cohen Rory Winston wrote: Right, the problem with this format is that the date is not composed of three discrete components (from a regex POV), but two. Basically what we will need to do is expand the regex to handle thuis - can you give me details of the FTP server operating system and FTP server software version if you have it please. Cheers Rory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: [net] FTP client date parsing: new format
Well, now I AM satisfied. I believe this is about as good as can be done using regular expressions. I tried to do as little date format validation as possible in the regex, but it is inevitable that some must be done. The previous code prior to Neeme Praks' discoveries relied on an assumption that was too good to be true and therefore brittle. That assumption was that the date portion of the regex could ALWAYS be determined by looking for three whitespace-delimited tokens in the right place. The new algorithm is that a date is either a) a single token with three all-numeric portions delimited by - or / OR b) two whitespace-delimited tokens FOLLOWED by whitespace FOLLOWED by a single token that is either all numeric (the year) or two numeric portions delimited by a colon (the time). All existing JUnit tests pass and no length or date-specific assumptions are made anywhere in the regex, leaving all such decisions to the DateFormat objects. Steve Cohen wrote: Okay, we've solved the immediate issues here but I'm not totally satisfied yet. The problem is that the numeric date format has introduced a new logical possibility. Formerly it was simple and clear - either with the default or recent date formats there were always THREE whitespace-separated components of the date (month day year OR month day time). The newly-introduced numeric date format in unix ftp servers (about time, by the way) adds a new possibility of a timestamp composed of TWO whitespace-separated components. But until this becomes widespread and probably forever, we'll have to maintain backward compatibility with the older non-numeric formats. Making the third token optional is reasonable, but as we have seen, Neeme's find of the symbolic link case defeats this simple attempt at a fix. With the two-or-three token date, it is possible that the regex engine will find an extra token later on and screw up the logic. My current solution relies on the fact that a unix filename is not supposed to start with a hyphen. ([^-\\s]\\S*) So -, the symlink indicator, will not be mistaken for a filename. But that still doesn't feel solid enough. I would feel better if we had a more solid regex that clearly captured what is and what is not a legal unix filename. Googling did not find an immediate answer to this questions, nor did I find one in Jeffrey Friedl's Mastering Regular Expressions book. Does anyone have one? Steve Cohen wrote: Sorry for being a bit brusque before but if you check out the latest code I think you will find that with Rory's and my changes, your issues are cared for. Neeme Praks wrote: ok, now I checked out the recent changes and the fix seems to work, at least in the case of usual files: -rw-r- 1 neeme neeme 346 2005-04-08 11:22 services.vsp is parsed into: typeStr=- hardLinkCount=1 usr=neeme grp=neeme filesize=346 datestr=2005-04-08 11:22 name=services.vsp endtoken= And this is correct. However, it still breaks in the case of symbolic links. So, if the entry is a symbolic link: lrwxrwxrwx 1 neeme neeme23 2005-03-02 18:06 macros - ./../../global/macros/. then it is parsed into these variables: typeStr=l hardLinkCount=1 usr=neeme grp=neeme filesize=23 datestr=2005-03-02 18:06 macros name=- endtoken= ../../../global/macros/ The ending of - ../../../global/macros/ seems to confuse the regexp parser. And to answer Rorys question about the specifics of the FTP server, I'll paste one of my earlier posts here: This format is from the default FTP server daemon configuration that came with Debian: Connected to stf. 220 stf FTP server (Version 6.4/OpenBSD/Linux-ftpd-0.17) ready. Name (stf:neeme): neeme 331 Password required for neeme. Password: 230- Linux stf 2.6.11 #1 SMP Wed Mar 2 14:08:21 CET 2005 i686 GNU/Linux 230- 230- The programs included with the Debian GNU/Linux system are free software; 230- the exact distribution terms for each program are described in the 230- individual files in /usr/share/doc/*/copyright. 230- 230- Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent 230- permitted by applicable law. 230 User neeme logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp Rgds, Neeme Neeme Praks wrote: AFAIK, the new system uses both: regexp for extracting the timestamp from the entry line and then using DateFormat to parse that. Example: -rw-r--r--1 1000 1000 27 Jan 24 11:31 messages.vsp from this line the regexp extracts the timestamp part (Jan 24 11:31) and then DateFormat is used to parse this to a valid Date object. The issue here is that the failure is already at regexp matching, and the code never reaches the DateFormat parsing part. I'll try to check out Rory's changes during the weekend. Rgds, Neeme Steve Cohen wrote: No, that's not it at all. Remember that the new system does not use Regexes for date parsing, it uses SimpleDateFormats. From Mr
Re: [net] FTP client date parsing: new format
No, that's not it at all. Remember that the new system does not use Regexes for date parsing, it uses SimpleDateFormats. From Mr. Praks' descriptions, I am assuming he's now running the 1.3 or earlier versions, which do use regexes. This surprises me because I've had several conversations with him over the past month in which the new system was discussed. Perhaps he forgot to specify the date format as /MM/dd in his FTPClientConfig this time? Or perhaps his code is finding an older commons-net.jar than he was expecting? Steve Cohen Rory Winston wrote: Right, the problem with this format is that the date is not composed of three discrete components (from a regex POV), but two. Basically what we will need to do is expand the regex to handle thuis - can you give me details of the FTP server operating system and FTP server software version if you have it please. Cheers Rory Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: --ms000205030904010307020307 Content-Type: text/plain; charset=windows-1257; format=flowed Content-Transfer-Encoding: 7bit Ok, now I've found out what is the issue: the regexp pattern used by UnixFTPEntryParser assumes too much about the format of the date. In particular, it assumes that there are spaces inside the date or something like that. As I'm not much of a regexp expert, I cannot really pinpoint the problem with the pattern. But I can demonstrate the results from applying this pattern below. This is the usual case that is parsed OK. *entry*: -rw-r--r--1 1000 1000 27 Jan 24 11:31 messages.vsp parsed into these variables: typeStr=- hardLinkCount=1 usr=1000 grp=1000 filesize=27 datestr=Jan 24 11:31 name=messages.vsp endtoken= This is the one that has issues. Lucky for me, the parser manages to parse the entries that represent symbolic links, as these entries seem to have enough spaces required by the regexp pattern. Although incorrectly, it nicely demonstrates the issue with the parser. *entry*: lrwxrwxrwx 1 neeme neeme23 2005-03-02 18:06 macros - ../../../global/macros/ parsed into these variables: typeStr=l hardLinkCount=1 usr=neeme grp=neeme filesize=23 datestr=2005-03-02 18:06 macros name=- endtoken= ../../../global/macros/ Note that starting from datestr variable, the parsing is f**ked up... How can we solve this issue? Make regexp pattern also configurable? Better suggestions? Rgds, Neeme Neeme Praks wrote: I cannot give you access as it is inside our corporate firewall. So I guess I'll try to debug it on my own. :-) I'll let you know when I have made some progress with that. --ms000205030904010307020307 Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII5TCC As0wggI2oAMCAQICAw2VSTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQxMjA4MjM0NjM5WhcNMDUxMjA4MjM0NjM5 WjBCMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR8wHQYJKoZIhvcNAQkBFhBu ZWVtZUBhcGFjaGUub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyZu8bdSh BOVFe3KQjdsj5+J9Ji5+1+1M3IF5JeC6LKOlcLqralU5mqO25xuqJMLcl6AY9K88RMtv9DyN fUz6AWA8fPYUhV1zO5WPuK4k+/9VzwGMIMUt/U1iVkdE0reW+qRWa6saip3HlFCR0iZCf+4w uMf7cO3yBMbFAvXjVNQoV/ghks39q6qS9aPPCehuqccpAds3UXS1JUPcfIuxrHtlEZacyW0O Dxs59fzqIREXxZCR5YotiBXdOvhb9NC5l6pzoViGCLUy7H56FNfVyqWtB8nMa4zTkodxFN6l mofpDpXhSyu3mwZWA5+qWaN0cOt8wviPNSU0KKzTK2GDewIDAQABoy0wKzAbBgNVHREEFDAS gRBuZWVtZUBhcGFjaGUub3JnMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAAm0Q +3NNp/N3X4hNDiBfjehE68roH96Rr/+N4uabBDQb1r5Cd00IRZ3DpzCdGrFq441hJT5faOZ2 RcqWk399YfTXecWEVpHfY7lcFwzCOiSyhTLjkZza8jxLsrzpleXbwWXfOlHGivPxMmSbcCpT 0oNCXMD5adUOcew7Wr1HMaYwggLNMIICNqADAgECAgMNlUkwDQYJKoZIhvcNAQEEBQAwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MTIwODIz NDYzOVoXDTA1MTIwODIzNDYzOVowQjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJl cjEfMB0GCSqGSIb3DQEJARYQbmVlbWVAYXBhY2hlLm9yZzCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMmbvG3UoQTlRXtykI3bI+fifSYuftftTNyBeSXguiyjpXC6q2pVOZqj tucbqiTC3JegGPSvPETLb/Q8jX1M+gFgPHz2FIVdczuVj7iuJPv/Vc8BjCDFLf1NYlZHRNK3 lvqkVmurGoqdx5RQkdImQn/uMLjH+3Dt8gTGxQL141TUKFf4IZLN/auqkvWjzwnobqnHKQHb N1F0tSVD3HyLsax7ZRGWnMltDg8bOfX86iERF8WQkeWKLYgV3Tr4W/TQuZeqc6FYhgi1Mux+ ehTX1cqlrQfJzGuM05KHcRTepZqH6Q6V4Usrt5sGVgOfqlmjdHDrfML4jzUlNCis0ythg3sC AwEAAaMtMCswGwYDVR0RBBQwEoEQbmVlbWVAYXBhY2hlLm9yZzAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBAUAA4GBAAJtEPtzTafzd1+ITQ4gX43oROvK6B/eka//jeLmmwQ0G9a+QndN CEWdw6cwnRqxauONYSU+X2jmdkXKlpN/fWH013nFhFaR32O5XBcMwjoksoUy45Gc2vI8S7K8 6ZXl28Fl3zpRxorz8TJkm3AqU9KDQlzA+WnVDnHsO1q9RzGmMIIDPzCCAqigAwIBAgIBDTAN
Re: Is there an Apache or java standard for expressing non-English String literals
Okay, found it. I assume, though, that it is not necessary to change this, now that I have replaced all the non-ASCII chars with unicode equivalents. Or am I still missing something? Neeme Praks wrote: Window - Preferences - Workbench - Editors and there is Text file encoding, can be (platform) default or custom. Rgds, Neeme Steve Cohen wrote: However, when you say that depends on your file encoding, where is THAT defined, actually? I looked through all the Eclipse options and found nothing indicating option to change encodings. Presumably, other editors I might use might have some other place to define this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there an Apache or java standard for expressing non-English String literals
Would others agree with this? Is the best editor setting for editing code where i18n could be an issue to set the editor to UTF-8 or is it better to leave it at its default local setting? What are the pros and cons here? Had I set the editor for UTF-8 would I not have had these issues? Or is it best to consciously code with explicit unicode escapes to avoid these issues on ANYONE's editor? Or both? Neeme Praks wrote: Yes, now it should be ok. However, I would advise to change it anyway - all platform specific settings are Bad(tm). :-) Steve Cohen wrote: Okay, found it. I assume, though, that it is not necessary to change this, now that I have replaced all the non-ASCII chars with unicode equivalents. Or am I still missing something? Neeme Praks wrote: Window - Preferences - Workbench - Editors and there is Text file encoding, can be (platform) default or custom. Rgds, Neeme Steve Cohen wrote: However, when you say that depends on your file encoding, where is THAT defined, actually? I looked through all the Eclipse options and found nothing indicating option to change encodings. Presumably, other editors I might use might have some other place to define this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] [ftp] [patch] FTPTimestampParserImplTest.java and FTPClientConfigTest.java
Neeme Praks wrote: ok, these new patches make the failures go away in a bit cleaner manner, by manipulating the default locale setting. Also, I noticed that your java sources are in some strange encoding. If I open those tests that use french letters in my Eclipse and save them then they become corrupt and will fail. My configuration assumes that all source files are in UTF8 and I think that should be the most reasonable assumption, no? Rgds, Neeme Okay, as a first step I have checked changes that convert all (I hope, all, may have missed one or two somewhere) non-7bit-ascii chars in string literals as well as javadoc comments, to unicode. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP client date parsing: new format
OK. There are no logging statements because jakarta-commons-net has no dependencies on any particular logging package. Ant does. I assume this configuration thing is a part of a custom task or revised ftp task of your own design. That would be the place to put in logging. You could even put in the stack trace. It would probably be easier to write a mini standalone java program that invokes commons-net-ftp directly, connects with the same server, and debug that. If you don't want to do that and can get me access to that server, I would be willing to try it. (If you do that, you'll probably want to reply directly to me and not send your server connection parameters to the list.) Steve Neeme Praks wrote: It just refuses to list any files from the server. Or is there some way to get more information about the possible issue? I didn't see any logging statements in the code... Rgds, Neeme Steve Cohen wrote: I used the following configuration for parsing: configuration defaultDateFormatStr=-MM-dd HH:mm serverTimeZoneId=Europe/Oslo shortMonthNames=01|02|03|04|05|06|07|08|09|10|11|12/ (and the system type defaults to Unix) How does it fail? It should not be necessary to define shortMonthNames, but I don't think that is the cause of your problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] [ftp] [patch] FTPTimestampParserImplTest.java and FTPClientConfigTest.java
I have now checked in code that I think should resolve these issues, but
you will have to be the test of that. I didn't use your exact patches
but I think I understood the issues you reported and handled them.
Please let me know if anything was missed.
Steve
Neeme Praks wrote:
ok, these new patches make the failures go away in a bit cleaner manner,
by manipulating the default locale setting.
Also, I noticed that your java sources are in some strange encoding. If
I open those tests that use french letters in my Eclipse and save them
then they become corrupt and will fail.
My configuration assumes that all source files are in UTF8 and I think
that should be the most reasonable assumption, no?
Rgds,
Neeme
Steve Cohen wrote:
Okay, now that I understand the problem in general terms, can you
please provide stack traces or other information indicating where in
the code failures are happening? Your patches provide me with a
possible fix, but I need to understand fully the problem. Also if you
could tell me the locale and other jvm properties that would help.
I think there may be other, more standard fixes that I can apply, but
I need to understand the problem fully. It would probably be better,
if possible, if could provide a setUp() routine that puts the JVM into
the same locale-state anywhere that yours is in by default.
I will be non-responsive for several days, but will look at this when
I return later in the week.
Steve
Neeme Praks wrote:
Two patches to make the FTP timestamp parsing tests pass also on
non-english systems.
I'm not sure if this is the best way to fix those issues, though.
Rgds,
Neeme
Index: FTPTimestampParserImplTest.java
===
--- FTPTimestampParserImplTest.java (revision 159615)
+++ FTPTimestampParserImplTest.java (working copy)
@@ -15,6 +15,7 @@
*/
package org.apache.commons.net.ftp.parser;
+import java.text.DateFormatSymbols;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Calendar;
@@ -73,8 +74,19 @@
FTPTimestampParserImpl parser = new FTPTimestampParserImpl();
+ // assume we are FTPing a server in Chicago, two hours ahead of +
// L. A.
+ FTPClientConfig config = + new
FTPClientConfig(FTPClientConfig.SYST_UNIX);
+ config.setDefaultDateFormatStr(FTPTimestampParser.DEFAULT_SDF);
+ config.setRecentDateFormatStr(FTPTimestampParser.DEFAULT_RECENT_SDF);
+ // 2 hours difference
+ config.setServerTimeZoneId(America/Chicago);
+ parser.configure(config);
+ + SimpleDateFormat sdf = - new
SimpleDateFormat(parser.getRecentDateFormatString());
+ new SimpleDateFormat(parser.getRecentDateFormatString(),
parser.getRecentDateFormat().getDateFormatSymbols());
// assume we're in the US Pacific Time Zone
TimeZone tzla = TimeZone.getTimeZone(America/Los_Angeles);
sdf.setTimeZone(tzla);
@@ -84,17 +96,6 @@
String fmtTimePlusThreeHours = sdf.format(threeHoursFromNow);
- // assume we are FTPing a server in Chicago, two hours ahead of -
// L. A.
- FTPClientConfig config = - new
FTPClientConfig(FTPClientConfig.SYST_UNIX);
- config.setDefaultDateFormatStr(FTPTimestampParser.DEFAULT_SDF);
- config.setRecentDateFormatStr(FTPTimestampParser.DEFAULT_RECENT_SDF);
- // 2 hours difference
- config.setServerTimeZoneId(America/Chicago);
- parser.configure(config);
-
-
try {
Calendar parsed = parser.parseTimestamp(fmtTimePlusOneHour);
// the only difference should be the two hours
@@ -103,7 +104,7 @@
(long)TWO_HOURS_OF_MILLISECONDS, cal.getTime().getTime() -
parsed.getTime().getTime());
} catch (ParseException e){
- fail(Unable to parse);
+ fail(Unable to parse + fmtTimePlusOneHour);
}
//but if the file's timestamp is THREE hours ahead of now, that
should @@ -123,13 +124,18 @@
public void testParser() {
FTPTimestampParserImpl parser = new FTPTimestampParserImpl();
+ Calendar cal = Calendar.getInstance();
+ cal.set(Calendar.YEAR, 2002);
+ cal.set(Calendar.MONTH, 1);
+ cal.set(Calendar.DAY_OF_MONTH, 22);
+ SimpleDateFormat sdf = new SimpleDateFormat(MMM dd );
try {
- parser.parseTimestamp(feb 22 2002);
+ parser.parseTimestamp(sdf.format(cal.getTime()));
} catch (ParseException e) {
fail(failed.to.parse.default);
}
try {
- parser.parseTimestamp(fv 22 2002);
+ parser.parseTimestamp(fv 22 2002);
fail(should.have.failed.to.parse.default);
} catch (ParseException e) {
// this is the success case
@@ -140,14 +146,17 @@
config.setRecentDateFormatStr(d MMM HH:mm);
config.setServerLanguageCode(fr);
parser.configure(config);
+ DateFormatSymbols dfs = FTPClientConfig.lookupDateFormatSymbols(fr);
+ sdf = new SimpleDateFormat(MMM d , dfs);
try {
- parser.parseTimestamp(dc 22 2002);
+ parser.parseTimestamp(sdf.format(cal.getTime()));
fail(incorrect.field.order);
} catch (ParseException e) {
// this is the success case
}
+ sdf = new SimpleDateFormat(d MMM , dfs);
try {
- parser.parseTimestamp(22 dc 2002
Re: Is there an Apache or java standard for expressing non-English String literals
robert burrell donkin wrote: On 7 Apr 2005, at 02:09, Steve Cohen wrote: Neeme Praks wrote: Also, I noticed that your java sources are in some strange encoding. If I open those tests that use french letters in my Eclipse and save them then they become corrupt and will fail. My configuration assumes that all source files are in UTF8 and I think that should be the most reasonable assumption, no? The files in question here are org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest.java and org.apache.commons.net.ftp.FTPClientConfig.java in the jakarta-commons-net project. Mr. Praks is correctly pointing out that my test code (and other source code) depends sometimes on typing string literals in languages other than English. What is the CORRECT way to handle this in source code, and what can I do to make editors such as Eclipse handle it correctly? that depends on your file encoding :) if you use UFT-8 (which is typical) it's safest to use unicode escaping when dealing with any non-ascii characters. - robert That's what I have done to fix this. I converted all the non-ASCII chars (and also the HTML-escaped non-ASCIIs in the javadoc comments) to unicode. Javadoc, apparently converts them back to HTML escaped chars when it creates the HTML. However, when you say that depends on your file encoding, where is THAT defined, actually? I looked through all the Eclipse options and found nothing indicating option to change encodings. Presumably, other editors I might use might have some other place to define this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP client date parsing: new format
Neeme Praks wrote: I now implemented support for FTPClientConfig in my local Ant ftp task, but somehow it still fails to parse this directory listing, although it parses the timestamp correctly (I tested that with jUnit). Is it because the parser assumes that the 3rd and 4th parameters (owner and group) are supposed to be numbers as opposed to names? -rw-r--r-- 1 neeme neeme 385 2005-03-21 14:26 about.vsp No. It accepts any non-whitespace characters for these fields. I used the following configuration for parsing: configuration defaultDateFormatStr=-MM-dd HH:mm serverTimeZoneId=Europe/Oslo shortMonthNames=01|02|03|04|05|06|07|08|09|10|11|12/ (and the system type defaults to Unix) How does it fail? It should not be necessary to define shortMonthNames, but I don't think that is the cause of your problem. Neeme Steve Cohen wrote: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is there an Apache or java standard for expressing non-English String literals
Neeme Praks wrote: Also, I noticed that your java sources are in some strange encoding. If I open those tests that use french letters in my Eclipse and save them then they become corrupt and will fail. My configuration assumes that all source files are in UTF8 and I think that should be the most reasonable assumption, no? The files in question here are org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest.java and org.apache.commons.net.ftp.FTPClientConfig.java in the jakarta-commons-net project. Mr. Praks is correctly pointing out that my test code (and other source code) depends sometimes on typing string literals in languages other than English. What is the CORRECT way to handle this in source code, and what can I do to make editors such as Eclipse handle it correctly? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] [ftp] [patch] FTPTimestampParserImplTest.java and FTPClientConfigTest.java
Okay, now that I understand the problem in general terms, can you please
provide stack traces or other information indicating where in the code
failures are happening? Your patches provide me with a possible fix,
but I need to understand fully the problem. Also if you could tell me
the locale and other jvm properties that would help.
I think there may be other, more standard fixes that I can apply, but I
need to understand the problem fully. It would probably be better, if
possible, if could provide a setUp() routine that puts the JVM into the
same locale-state anywhere that yours is in by default.
I will be non-responsive for several days, but will look at this when I
return later in the week.
Steve
Neeme Praks wrote:
Two patches to make the FTP timestamp parsing tests pass also on
non-english systems.
I'm not sure if this is the best way to fix those issues, though.
Rgds,
Neeme
Index: FTPTimestampParserImplTest.java
===
--- FTPTimestampParserImplTest.java (revision 159615)
+++ FTPTimestampParserImplTest.java (working copy)
@@ -15,6 +15,7 @@
*/
package org.apache.commons.net.ftp.parser;
+import java.text.DateFormatSymbols;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Calendar;
@@ -73,8 +74,19 @@
FTPTimestampParserImpl parser = new FTPTimestampParserImpl();
+// assume we are FTPing a server in Chicago, two hours ahead of
+// L. A.
+FTPClientConfig config =
+new FTPClientConfig(FTPClientConfig.SYST_UNIX);
+config.setDefaultDateFormatStr(FTPTimestampParser.DEFAULT_SDF);
+config.setRecentDateFormatStr(FTPTimestampParser.DEFAULT_RECENT_SDF);
+// 2 hours difference
+config.setServerTimeZoneId(America/Chicago);
+parser.configure(config);
+
+
SimpleDateFormat sdf =
- new SimpleDateFormat(parser.getRecentDateFormatString());
+ new SimpleDateFormat(parser.getRecentDateFormatString(), parser.getRecentDateFormat().getDateFormatSymbols());
// assume we're in the US Pacific Time Zone
TimeZone tzla = TimeZone.getTimeZone(America/Los_Angeles);
sdf.setTimeZone(tzla);
@@ -84,17 +96,6 @@
String fmtTimePlusThreeHours = sdf.format(threeHoursFromNow);
- // assume we are FTPing a server in Chicago, two hours ahead of
- // L. A.
- FTPClientConfig config =
- new FTPClientConfig(FTPClientConfig.SYST_UNIX);
- config.setDefaultDateFormatStr(FTPTimestampParser.DEFAULT_SDF);
- config.setRecentDateFormatStr(FTPTimestampParser.DEFAULT_RECENT_SDF);
- // 2 hours difference
- config.setServerTimeZoneId(America/Chicago);
- parser.configure(config);
-
-
try {
Calendar parsed = parser.parseTimestamp(fmtTimePlusOneHour);
// the only difference should be the two hours
@@ -103,7 +104,7 @@
(long)TWO_HOURS_OF_MILLISECONDS,
cal.getTime().getTime() - parsed.getTime().getTime());
} catch (ParseException e){
- fail(Unable to parse);
+ fail(Unable to parse + fmtTimePlusOneHour);
}
//but if the file's timestamp is THREE hours ahead of now, that should
@@ -123,13 +124,18 @@
public void testParser() {
FTPTimestampParserImpl parser = new FTPTimestampParserImpl();
+Calendar cal = Calendar.getInstance();
+cal.set(Calendar.YEAR, 2002);
+cal.set(Calendar.MONTH, 1);
+cal.set(Calendar.DAY_OF_MONTH, 22);
+SimpleDateFormat sdf = new SimpleDateFormat(MMM dd );
try {
- parser.parseTimestamp(feb 22 2002);
+ parser.parseTimestamp(sdf.format(cal.getTime()));
} catch (ParseException e) {
fail(failed.to.parse.default);
}
try {
- parser.parseTimestamp(fv 22 2002);
+ parser.parseTimestamp(fv 22 2002);
fail(should.have.failed.to.parse.default);
} catch (ParseException e) {
// this is the success case
@@ -140,14 +146,17 @@
config.setRecentDateFormatStr(d MMM HH:mm);
config.setServerLanguageCode(fr);
parser.configure(config);
+DateFormatSymbols dfs = FTPClientConfig.lookupDateFormatSymbols(fr);
+sdf = new SimpleDateFormat(MMM d , dfs);
try {
- parser.parseTimestamp(dc 22 2002);
+parser.parseTimestamp(sdf.format(cal.getTime()));
fail(incorrect.field.order);
} catch (ParseException e) {
// this is the success case
}
+sdf = new SimpleDateFormat(d MMM , dfs);
try {
- parser.parseTimestamp(22 dc 2002);
+parser.parseTimestamp(sdf.format(cal.getTime()));
} catch (ParseException e) {
fail(failed.to.parse.french);
}
@@ -159,27 +168,28 @@
// this is the success case
}
try {
- parser.parseTimestamp(29 fv 2002);
+ parser.parseTimestamp(29 fv 2002);
fail(nonexistent.date);
} catch (ParseException e) {
// this is the success case
}
try {
- parser.parseTimestamp(22 ao 30:02);
+
Re: [net] [ftp] [patch] FTPTimestampParserImplTest.java and FTPClientConfigTest.java
Yes it does, thank you very much. Neeme Praks wrote: No, they don't pass on a machine that has a default locale set to something non-english. The problem is that the tests are assuming too much about the default locale. For example, if you create a new SimpleDateFormat without providing a locale or a set of DateFormatSymbols then that SimpleDateFormat will use the default stuff. And then the test code assumes that it will get english month names but, for example in my case, it will get Estonian month names and it will fail. I hope that clarified things up a bit? Rgds, Neeme Steve Cohen wrote: What do you mean, make the tests pass? The tests, as written, already pass. Perhaps you are saying that the tests don't test everything they need to test. But you have not identified what those issues are. If you come up with a test case that shows a problem, then the solution is to add the test and fix the code as necessary. Or am I misunderstanding you? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] [ftp] [patch] FTPTimestampParserImplTest.java and FTPClientConfigTest.java
What do you mean, make the tests pass? The tests, as written, already
pass. Perhaps you are saying that the tests don't test everything they
need to test. But you have not identified what those issues are.
If you come up with a test case that shows a problem, then the solution
is to add the test and fix the code as necessary.
Or am I misunderstanding you?
Neeme Praks wrote:
Two patches to make the FTP timestamp parsing tests pass also on
non-english systems.
I'm not sure if this is the best way to fix those issues, though.
Rgds,
Neeme
Index: FTPTimestampParserImplTest.java
===
--- FTPTimestampParserImplTest.java (revision 159615)
+++ FTPTimestampParserImplTest.java (working copy)
@@ -15,6 +15,7 @@
*/
package org.apache.commons.net.ftp.parser;
+import java.text.DateFormatSymbols;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Calendar;
@@ -73,8 +74,19 @@
FTPTimestampParserImpl parser = new FTPTimestampParserImpl();
+// assume we are FTPing a server in Chicago, two hours ahead of
+// L. A.
+FTPClientConfig config =
+new FTPClientConfig(FTPClientConfig.SYST_UNIX);
+config.setDefaultDateFormatStr(FTPTimestampParser.DEFAULT_SDF);
+config.setRecentDateFormatStr(FTPTimestampParser.DEFAULT_RECENT_SDF);
+// 2 hours difference
+config.setServerTimeZoneId(America/Chicago);
+parser.configure(config);
+
+
SimpleDateFormat sdf =
- new SimpleDateFormat(parser.getRecentDateFormatString());
+ new SimpleDateFormat(parser.getRecentDateFormatString(), parser.getRecentDateFormat().getDateFormatSymbols());
// assume we're in the US Pacific Time Zone
TimeZone tzla = TimeZone.getTimeZone(America/Los_Angeles);
sdf.setTimeZone(tzla);
@@ -84,17 +96,6 @@
String fmtTimePlusThreeHours = sdf.format(threeHoursFromNow);
- // assume we are FTPing a server in Chicago, two hours ahead of
- // L. A.
- FTPClientConfig config =
- new FTPClientConfig(FTPClientConfig.SYST_UNIX);
- config.setDefaultDateFormatStr(FTPTimestampParser.DEFAULT_SDF);
- config.setRecentDateFormatStr(FTPTimestampParser.DEFAULT_RECENT_SDF);
- // 2 hours difference
- config.setServerTimeZoneId(America/Chicago);
- parser.configure(config);
-
-
try {
Calendar parsed = parser.parseTimestamp(fmtTimePlusOneHour);
// the only difference should be the two hours
@@ -103,7 +104,7 @@
(long)TWO_HOURS_OF_MILLISECONDS,
cal.getTime().getTime() - parsed.getTime().getTime());
} catch (ParseException e){
- fail(Unable to parse);
+ fail(Unable to parse + fmtTimePlusOneHour);
}
//but if the file's timestamp is THREE hours ahead of now, that should
@@ -123,13 +124,18 @@
public void testParser() {
FTPTimestampParserImpl parser = new FTPTimestampParserImpl();
+Calendar cal = Calendar.getInstance();
+cal.set(Calendar.YEAR, 2002);
+cal.set(Calendar.MONTH, 1);
+cal.set(Calendar.DAY_OF_MONTH, 22);
+SimpleDateFormat sdf = new SimpleDateFormat(MMM dd );
try {
- parser.parseTimestamp(feb 22 2002);
+ parser.parseTimestamp(sdf.format(cal.getTime()));
} catch (ParseException e) {
fail(failed.to.parse.default);
}
try {
- parser.parseTimestamp(fv 22 2002);
+ parser.parseTimestamp(fv 22 2002);
fail(should.have.failed.to.parse.default);
} catch (ParseException e) {
// this is the success case
@@ -140,14 +146,17 @@
config.setRecentDateFormatStr(d MMM HH:mm);
config.setServerLanguageCode(fr);
parser.configure(config);
+DateFormatSymbols dfs = FTPClientConfig.lookupDateFormatSymbols(fr);
+sdf = new SimpleDateFormat(MMM d , dfs);
try {
- parser.parseTimestamp(dc 22 2002);
+parser.parseTimestamp(sdf.format(cal.getTime()));
fail(incorrect.field.order);
} catch (ParseException e) {
// this is the success case
}
+sdf = new SimpleDateFormat(d MMM , dfs);
try {
- parser.parseTimestamp(22 dc 2002);
+parser.parseTimestamp(sdf.format(cal.getTime()));
} catch (ParseException e) {
fail(failed.to.parse.french);
}
@@ -159,27 +168,28 @@
// this is the success case
}
try {
- parser.parseTimestamp(29 fv 2002);
+ parser.parseTimestamp(29 fv 2002);
fail(nonexistent.date);
} catch (ParseException e) {
// this is the success case
}
try {
- parser.parseTimestamp(22 ao 30:02);
+ parser.parseTimestamp(22 ao 30:02);
fail(bad.hour);
} catch (ParseException e) {
// this is the success case
}
try {
- parser.parseTimestamp(22 ao 20:74);
+ parser.parseTimestamp(22 ao 20:74);
fail(bad.minute);
} catch (ParseException e) {
// this is the success case
}
+sdf = new SimpleDateFormat(d MMM HH:mm,
Re: [net] FTPclient: keeping track of dates of files on the server
Neeme: Is Ant the right tool for your job? Ant is a build tool, not an all-purpose scripting language. If what you describe is all you're doing, you might consider a script written in perl or python, or perhaps in java using commons-net directly. Or if you're in a j2ee container environment like jboss, using some of the clustering features they offer. I wouldn't choose Ant for your use case unless you're also simultaneously doing some other kinds of building and packaging that you haven't mentioned. Steve Neeme Praks wrote: ok, clear enough. I'll look into the source code of the ftp task and play around with it a bit. Another suggestion for that task is to allow retry-in-case-of-failure, not just abort or ignore as in the current version. But I'll take those issues up on Ant list. My use case is simple: I'm using ant ftp task to deploy Velocity scripts to several front-end machines (7 in total). And it is really annoying to change one file and to discover that instead of just uploading one file, it will upload a whole bunch of them... I actually need some more customized behaviour, so I will most probably write a separate task and see if there are any more interested parties in Ant community. Rgds, Neeme - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTPclient: keeping track of dates of files on the server
Sorry I didn't read far enough. This is more properly a discussion for the Ant list. All we handle here is the raw FTP. Ant's FTP task depends on commons-net, though, and until we release the timezone-using version of commons-net, ant will not have the tools to do what you need. I may be speaking out of turn here, but I doubt that that Ant developers will be receptive to your suggestion. The ant ftp task has been designed as a fairly simple wrapper around raw ftp. The newer attribute of the ftp task offers just a simple date-time comparison within the general dependency framework of ant. It sounds like what you are asking for is something much more, basically a version-control system. Ant supports several of these and my guess is that they will tell you to use cvs or one of the proprietary version control systems that ant supports in order to accomplish this logic. Have you considered using the cvs task of ant? I programmed one of the version-control systems that ant supports and your issues sound very familiar to me. But I could be wrong, also. If you outline your use case on the ant list, you may find more interest in supporting it than I expect. If you do, I suspect that would be implemented in a new task that perhaps sits on top of ftp, because there are still many use cases for using the ftp task as is. In any case, the timezone feature of commons-net-ftp will be part of any possible solution. Neeme Praks wrote: Well, as I wrote in my previous email, timezone setting does help, but I would like to take it one step further. When just using plain timezone difference calculation, you are still comparing server time to the local time and those usually are out-of-sync. I would like to have it 100% precise: to compare server time to the server time and local time to local time. If you would read my original post again, maybe you would see the light :-) Rgds, Neeme P.S. It's a Mr, as usual in technology mailing lists. Nice try, though :-P Steve Cohen wrote: Spot on again, Mr. (Ms.?) Praks. And again, the latest version of CVS allows the specification of a server time zone, for precisely this reason. We need to get this released and then supported in Ant. Steve Cohen Neeme Praks wrote: Hi again! Another issue I've been thinking about. Correct me if I'm wrong but the current way that FTP client checks if the file locally is newer or not is the following: 1. it takes the time from the server 2. manipulates the time according to timezone settings 3. compares it to the time on the local file In the ideal case, when the local machine time and the server time are in sync, this scheme should work. However, we do not live in the ideal world. So usually the local time and the server time does not match. This results in four scenarios, and here is my ASCII art illustration: lf = local file |lf IS UPDATED |lf IS NOT UPDATED ---++--- timestamp shows lf | this is BAD, changes | this is OK, as there is as OLDER than the | stay on local disk | no update required file on the server | nothing is uploaded| anyway -- ++--- timestamp shows lf | this is OK, as the | this is not really bad but as NEWER than the | file has to be updated | NOT GOOD either. we will file on the server | anyway | constantly try to update || files that are already || up-to-date ---++--- Actually there is one more axis to this: if the file on the server is updated or not. But it is very similar to the case above, so I will not go into details of that issue now. Hopefully that made sense? I would like to avoid these undesirable scenarios. How to do that? By comparing apples to apples and oranges to oranges: by comparing the server timestamp to the timestamp from the same server and local timestamp to local time. In order to do this, we just need to keep a list of timestamps around somewhere, from session to session. My proposal: When FTP client does checks for timestamps, it stores the last known server and local timestamps of each file in some designated working directory. And after each upload, it updates those timestamps. Then, it can easily determine, if the file on the server has been overwritten or if the local file has been updated since the last synchronization. If the local file is unchanged and server file is unchanged - skip. If the local file is changed and server file is unchanged - upload. If the local file is unchanged and server file is changed - skip. Or, optional behaviour could be to download changes. If the local file is changed and server file is changed - upload and issue warning. Or, the default behaviour could be to just issue warning
Re: [net] FTP client date parsing: new format
Very good news that Debian is going to an all-numeric date format. After mucking around in this mess for a couple of years, I often wondered why standard unix ftp bothered with the abbreviations at all. NT does not and does unix really want to take a back seat to NT in matters such as this? The numeric format is obviously superior. Neeme Praks wrote: This format is from the default FTP server daemon configuration that came with Debian: Connected to stf. 220 stf FTP server (Version 6.4/OpenBSD/Linux-ftpd-0.17) ready. Name (stf:neeme): neeme 331 Password required for neeme. Password: 230- Linux stf 2.6.11 #1 SMP Wed Mar 2 14:08:21 CET 2005 i686 GNU/Linux 230- 230- The programs included with the Debian GNU/Linux system are free software; 230- the exact distribution terms for each program are described in the 230- individual files in /usr/share/doc/*/copyright. 230- 230- Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent 230- permitted by applicable law. 230 User neeme logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp Rgds, Neeme Steve Cohen wrote: Wow! Thanks for showing us this. That's a format I've not seen before. Where did it come from? Is it by any chance a public site? In past experience, all unix ftp servers, which I presume this to be, have used abbreviations for the months. There IS a new system in the latest version of commons-net that would allow you to specify an alternate date format. I consider this a nice validation of the new design - it offers a way to work with a format we didn't even know existed. It's not hooked up to ant yet but that was always my intent. What say, other commons-net committers? Are we ready to build 1.4? Then I could add hooks for this new system in Ant. Steve Cohen Neeme Praks wrote: Hi all! Attached is a sample directory listing that breaks the 1.3.0 commons-net FTP client directory parsing, at least when used from Ant task. The basic difference is that the dates are specified as numbers (2005-03-21 14:26), not as month names. I saw on the mailing list that there is now a possibility to use custom date parsers, but I'm not sure how well that would mix with the Ant ftp task. Or maybe there is already a fix for this in CVS and I can just build from CVS? Thanks, Neeme ftp ls -l 200 PORT command successful. 150 Opening ASCII mode data connection for '/bin/ls'. total 356 -rw-r--r-- 1 inpoc inpoc 385 2005-03-21 14:26 about.vsp -rw-r--r-- 1 inpoc inpoc27 2005-03-21 14:26 animations.vsp -rw-r--r-- 1 inpoc inpoc 778 2005-03-21 14:27 animations.wap.vsp -rw-r- 1 inpoc inpoc 365 2005-03-21 14:27 animations.web.vsp drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 bite.inpoc.lt drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 biterus.inpoc.lt -rw-r--r-- 1 inpoc inpoc 198 2005-03-21 14:27 crossdomain.xml -rw-r--r-- 1 inpoc inpoc27 2005-03-21 14:27 dynamic_sms.vsp -rw-r--r-- 1 inpoc inpoc 1088 2005-03-21 14:27 dynamic_sms.wap.vsp -rw-r- 1 inpoc inpoc 355 2005-03-21 14:27 dynamic_sms.web.vsp drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 emtgo.inpoc.ee drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 emtgorus.inpoc.ee drwxrwxr-x 2 inpoc inpoc 4096 2005-03-21 12:44 face.inpoc.lv drwxr-xr-x 4 inpoc inpoc 4096 2004-10-21 14:45 flash lrwxrwxrwx 1 inpoc inpoc28 2005-03-02 18:06 gfx - ../../www.inpoc.no/ROOT/gfx/ drwxr-xr-x 2 inpoc inpoc 4096 2004-10-27 14:11 gfx.wap lrwxrwxrwx 1 inpoc inpoc26 2005-03-02 18:06 globalgfx - ../../../global/globalgfx/ lrwxrwxrwx 1 inpoc inpoc31 2005-03-02 18:06 globalincludes - ../../../global/globalincludes/ drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 golive.inpoc.ee drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 golive.inpoc.lt drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 goliverus.inpoc.ee drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 goliverus.inpoc.lt drwxr-xr-x 2 inpoc inpoc 4096 2004-09-08 23:09 hei.inpoc.ee -rw-r--r-- 1 inpoc inpoc 381 2005-03-21 14:27 help.vsp -rw-r--r-- 1 inpoc inpoc 2232 2005-03-21 14:27 help.wap.vsp drwxr-xr-x 2 inpoc inpoc 4096 2004-11-09 13:33 ieskok.inpoc.lt lrwxrwxrwx 1 inpoc inpoc33 2005-03-02 18:06 includes - ../../www.inpoc.no/ROOT/includes/ -rw-r--r-- 1 inpoc inpoc 412 2005-03-21 14:27 index.vsp -rw-r--r-- 1 inpoc inpoc 1027 2004-09-08 23:09 index.wap.vsp drwxrwxr-x 3 inpoc inpoc 4096 2004-12-21 16:07 inpoc.delfi.ee drwxr-xr-x 2 inpoc inpoc 4096 2004-09-24 13:45 kangazoo.inpoc.lv drwxr-x--- 11 inpoc inpoc 4096 2005-01-17 15:49 localgfx -rw-r--r-- 1 inpoc inpoc27 2005-03-21 14:27 logos.vsp -rw-r--r-- 1 inpoc inpoc 1081 2005-03-21 14:27 logos.wap.vsp -rw-r- 1 inpoc inpoc 351 2005-03-21 14:27 logos.web.vsp lrwxrwxrwx 1 inpoc inpoc23 2005-03-02 18:06 macros - ../../../global/macros/ -rw-r--r-- 1 inpoc inpoc38 2005-03-21 14
Re: [net] FTP client date parsing: new format
Rory Winston wrote: SOunds good. I do think if we go for 1.4 though, we should probably include some of the smaller issues in BZ that would be easy to fix as well, and maybe get some of those cleaned up. IIRC, most of the smaller bugs include patches or source listings. _ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I'm in agreement with that. Would you care to suggest a timeline? I will have very little free time over the next two weeks. After that, maybe I can look at it. When you did the last commit, was subversion in use yet by jakarta? I know the old process was very cvs-centric. HOw accurate were the docs in the new environment? Or is that an adventure yet to be experienced? There were some complaints a few weeks back about missing JUnit tests. Did you ever find out what the deal was with that? Did svn eat them or were they deliberately removed (perhaps because they were failing in Gump and no one knew how to fix them)? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP client date parsing: new format
I meant when you did the last release, of course. Steve Cohen wrote: Rory Winston wrote: SOunds good. I do think if we go for 1.4 though, we should probably include some of the smaller issues in BZ that would be easy to fix as well, and maybe get some of those cleaned up. IIRC, most of the smaller bugs include patches or source listings. _ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I'm in agreement with that. Would you care to suggest a timeline? I will have very little free time over the next two weeks. After that, maybe I can look at it. When you did the last commit, was subversion in use yet by jakarta? I know the old process was very cvs-centric. HOw accurate were the docs in the new environment? Or is that an adventure yet to be experienced? There were some complaints a few weeks back about missing JUnit tests. Did you ever find out what the deal was with that? Did svn eat them or were they deliberately removed (perhaps because they were failing in Gump and no one knew how to fix them)? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP client date parsing: new format
4-6 weeks sounds reasonable. Rory Winston wrote: The last release was from CVS. The docs were (are? - haven't checked) very CVS-centric. I haven't attmepted to try a release from SVN yet, however I presume it wouldn't be too arduous a task, given the ease of substitutability between CVS/SVN. I fixed the issue with missing JUnit tests - they were missing all along (my mistake), I just added them into SVN. As regards a timeline, I'm also pretty swamped over the next couple of weeks (starting a new role, etc), so it will be tight for me until then. If I do get a chance in the next couple of weeks I will look at fixing some of the more straightforward issues in BZ. It would be nice to get a release out before too long - maybe in the next 4-6 weeks, how does that sound as a rough timescale estimate? Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: Rory Winston wrote: SOunds good. I do think if we go for 1.4 though, we should probably include some of the smaller issues in BZ that would be easy to fix as well, and maybe get some of those cleaned up. IIRC, most of the smaller bugs include patches or source listings. _ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I'm in agreement with that. Would you care to suggest a timeline? I will have very little free time over the next two weeks. After that, maybe I can look at it. When you did the last commit, was subversion in use yet by jakarta? I know the old process was very cvs-centric. HOw accurate were the docs in the new environment? Or is that an adventure yet to be experienced? There were some complaints a few weeks back about missing JUnit tests. Did you ever find out what the deal was with that? Did svn eat them or were they deliberately removed (perhaps because they were failing in Gump and no one knew how to fix them)? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP client date parsing: new format
Wow! Thanks for showing us this. That's a format I've not seen before. Where did it come from? Is it by any chance a public site? In past experience, all unix ftp servers, which I presume this to be, have used abbreviations for the months. There IS a new system in the latest version of commons-net that would allow you to specify an alternate date format. I consider this a nice validation of the new design - it offers a way to work with a format we didn't even know existed. It's not hooked up to ant yet but that was always my intent. What say, other commons-net committers? Are we ready to build 1.4? Then I could add hooks for this new system in Ant. Steve Cohen Neeme Praks wrote: Hi all! Attached is a sample directory listing that breaks the 1.3.0 commons-net FTP client directory parsing, at least when used from Ant task. The basic difference is that the dates are specified as numbers (2005-03-21 14:26), not as month names. I saw on the mailing list that there is now a possibility to use custom date parsers, but I'm not sure how well that would mix with the Ant ftp task. Or maybe there is already a fix for this in CVS and I can just build from CVS? Thanks, Neeme ftp ls -l 200 PORT command successful. 150 Opening ASCII mode data connection for '/bin/ls'. total 356 -rw-r--r-- 1 inpoc inpoc 385 2005-03-21 14:26 about.vsp -rw-r--r-- 1 inpoc inpoc27 2005-03-21 14:26 animations.vsp -rw-r--r-- 1 inpoc inpoc 778 2005-03-21 14:27 animations.wap.vsp -rw-r- 1 inpoc inpoc 365 2005-03-21 14:27 animations.web.vsp drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 bite.inpoc.lt drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 biterus.inpoc.lt -rw-r--r-- 1 inpoc inpoc 198 2005-03-21 14:27 crossdomain.xml -rw-r--r-- 1 inpoc inpoc27 2005-03-21 14:27 dynamic_sms.vsp -rw-r--r-- 1 inpoc inpoc 1088 2005-03-21 14:27 dynamic_sms.wap.vsp -rw-r- 1 inpoc inpoc 355 2005-03-21 14:27 dynamic_sms.web.vsp drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 emtgo.inpoc.ee drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 emtgorus.inpoc.ee drwxrwxr-x 2 inpoc inpoc 4096 2005-03-21 12:44 face.inpoc.lv drwxr-xr-x 4 inpoc inpoc 4096 2004-10-21 14:45 flash lrwxrwxrwx 1 inpoc inpoc28 2005-03-02 18:06 gfx - ../../www.inpoc.no/ROOT/gfx/ drwxr-xr-x 2 inpoc inpoc 4096 2004-10-27 14:11 gfx.wap lrwxrwxrwx 1 inpoc inpoc26 2005-03-02 18:06 globalgfx - ../../../global/globalgfx/ lrwxrwxrwx 1 inpoc inpoc31 2005-03-02 18:06 globalincludes - ../../../global/globalincludes/ drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 golive.inpoc.ee drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 golive.inpoc.lt drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 goliverus.inpoc.ee drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 goliverus.inpoc.lt drwxr-xr-x 2 inpoc inpoc 4096 2004-09-08 23:09 hei.inpoc.ee -rw-r--r-- 1 inpoc inpoc 381 2005-03-21 14:27 help.vsp -rw-r--r-- 1 inpoc inpoc 2232 2005-03-21 14:27 help.wap.vsp drwxr-xr-x 2 inpoc inpoc 4096 2004-11-09 13:33 ieskok.inpoc.lt lrwxrwxrwx 1 inpoc inpoc33 2005-03-02 18:06 includes - ../../www.inpoc.no/ROOT/includes/ -rw-r--r-- 1 inpoc inpoc 412 2005-03-21 14:27 index.vsp -rw-r--r-- 1 inpoc inpoc 1027 2004-09-08 23:09 index.wap.vsp drwxrwxr-x 3 inpoc inpoc 4096 2004-12-21 16:07 inpoc.delfi.ee drwxr-xr-x 2 inpoc inpoc 4096 2004-09-24 13:45 kangazoo.inpoc.lv drwxr-x--- 11 inpoc inpoc 4096 2005-01-17 15:49 localgfx -rw-r--r-- 1 inpoc inpoc27 2005-03-21 14:27 logos.vsp -rw-r--r-- 1 inpoc inpoc 1081 2005-03-21 14:27 logos.wap.vsp -rw-r- 1 inpoc inpoc 351 2005-03-21 14:27 logos.web.vsp lrwxrwxrwx 1 inpoc inpoc23 2005-03-02 18:06 macros - ../../../global/macros/ -rw-r--r-- 1 inpoc inpoc38 2005-03-21 14:27 menu.vsp drwxr-xr-x 2 inpoc inpoc 4096 2004-10-20 09:56 mixfm.inpoc.lv drwxrwxr-x 2 inpoc inpoc 4096 2004-12-22 12:24 mobiil.delfi.ee -rw-r--r-- 1 inpoc inpoc27 2005-03-21 14:27 mobilegames.vsp -rw-r--r-- 1 inpoc inpoc 1292 2005-03-21 14:27 mobilegames.wap.vsp -rw-r- 1 inpoc inpoc 1356 2005-03-21 14:27 mobilegames.web.vsp drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:13 omni.inpoc.lt drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:13 omnirus.inpoc.lt drwxr-x--- 4 inpoc inpoc 4096 2004-11-24 11:23 partners -rw-r- 1 inpoc inpoc 2162 2005-03-21 14:28 phonecontent.browse.wap.vsp -rw-r- 1 inpoc inpoc 1280 2005-03-21 14:28 phonecontent.first.wap.vsp -rw-r- 1 inpoc inpoc 1145 2005-03-21 14:28 phonecontent.search.wap.vsp -rw-r- 1 inpoc inpoc 346 2005-03-21 14:28 phonecontent.vsp -rw-r- 1 inpoc inpoc 994 2005-03-21 14:28 phonecontent.xml.vsp -rw-r--r-- 1 inpoc inpoc27 2005-03-21 14:28 picturemessages.vsp -rw-r--r-- 1 inpoc inpoc 1141 2005-03-21 14:28 picturemessages.wap.vsp -rw-r- 1 inpoc inpoc 370 2005-03-21 14:28
Re: [net] FTPclient: keeping track of dates of files on the server
Spot on again, Mr. (Ms.?) Praks. And again, the latest version of CVS allows the specification of a server time zone, for precisely this reason. We need to get this released and then supported in Ant. Steve Cohen Neeme Praks wrote: Hi again! Another issue I've been thinking about. Correct me if I'm wrong but the current way that FTP client checks if the file locally is newer or not is the following: 1. it takes the time from the server 2. manipulates the time according to timezone settings 3. compares it to the time on the local file In the ideal case, when the local machine time and the server time are in sync, this scheme should work. However, we do not live in the ideal world. So usually the local time and the server time does not match. This results in four scenarios, and here is my ASCII art illustration: lf = local file |lf IS UPDATED |lf IS NOT UPDATED ---++--- timestamp shows lf | this is BAD, changes | this is OK, as there is as OLDER than the | stay on local disk | no update required file on the server | nothing is uploaded| anyway -- ++--- timestamp shows lf | this is OK, as the | this is not really bad but as NEWER than the | file has to be updated | NOT GOOD either. we will file on the server | anyway | constantly try to update || files that are already || up-to-date ---++--- Actually there is one more axis to this: if the file on the server is updated or not. But it is very similar to the case above, so I will not go into details of that issue now. Hopefully that made sense? I would like to avoid these undesirable scenarios. How to do that? By comparing apples to apples and oranges to oranges: by comparing the server timestamp to the timestamp from the same server and local timestamp to local time. In order to do this, we just need to keep a list of timestamps around somewhere, from session to session. My proposal: When FTP client does checks for timestamps, it stores the last known server and local timestamps of each file in some designated working directory. And after each upload, it updates those timestamps. Then, it can easily determine, if the file on the server has been overwritten or if the local file has been updated since the last synchronization. If the local file is unchanged and server file is unchanged - skip. If the local file is changed and server file is unchanged - upload. If the local file is unchanged and server file is changed - skip. Or, optional behaviour could be to download changes. If the local file is changed and server file is changed - upload and issue warning. Or, the default behaviour could be to just issue warning. And we could implement synchronizing file deletions also. The directory contents could look something like this: commons-net-ftp-timestamp-cache/my-ftpserver.cache - one file per unique server inside that file would be something like this: [file path] [server timestamp] [local timestamp] [file path] [server timestamp] [local timestamp] [file path] [server timestamp] [local timestamp] ... [file path] [server timestamp] [local timestamp] What do you make of all this? Does it make any sense? I would be willing to work on implementing this unless someone has some better ideas for achieving similar results. Should this actually go inside commons-net or maybe inside the Ant task instead? Rgds, Neeme - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] NTP + Time test code not in CVS branch
Rory Winston wrote: Jason, Thanks for the heads-up. I will have a look and restore them. Cheers, Rory Jason Mathews wrote: In the latest build of Net commons it appears that the contributed Ntp + Time junit tests got dropped. http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1078351 http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1078351 Test classes in question: Directory of C:\net\src\test\org\apache\commons\net\ntp 10/08/2003 09:56 AM 5,876 TimeStampTest.java Directory of C:\net\src\test\org\apache\commons\net\time 10/08/2003 09:57 AM 6,021 TimeTCPClientTest.java 09/26/2003 08:35 AM 6,332 TimeTestSimpleServer.java -- Jason Mathews [EMAIL PROTECTED] The MITRE Corporation http://www.mitre.org/ Bedford, MA 01730-1407 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] SVN conversion the culprit, perhaps? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Subversion] Revision Keyword
Simon Kitching wrote: And you can get subversion commands to ignore certain files by setting the global-ignores entry in ~/.subversion/config. I have the following: [miscellany] global-ignores = *.o *.lo *.la .*~ *~ .#* *.class .*.marks I believe it's much safer in the long run to do this in the repository folder properties than relying on client-side configuration (although it's probably best to do the first and recommend the second to all users). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] I would like to deprecate a FTPClient.listFiles() method
The introduction of FTPClientConfig a month ago has wrought a certain amount of confusion. There are five FTPClient.listFiles() methods. Two have already been deprecated. The other two are convenience methods and their existence causes confusion. This method is: public FTPFile[] listFiles(String parserKey, String pathname) This method calls initiateListParsing(). If parserKey is null, then the code will look for the __configuration member. The problem arises when the user sets the __configuration member AND calls listFiles with a parserKey. This non-intuively causes the __configuration to be ignored. Since it is possible to set the parserKey through the __configuration, I would like this method to be the preferred way to specify a parser key and the convenience method deprcated. Keep in mind that the no-param listFiles() is the most commonly used and defaults to auto-detection of system type if no configuration has been specified. I also question the utility of public FTPFile[] listFiles(String pathname) but not as strongly. This method is not necessary as it is always possible to call changeWorkingDirectory() before calling listFiles(). What does the team think of these changes? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
subeclipse
After last week's vote, I have been mucking around with subversion and subeclipse trying to get my feet wet. Here is one thing I learned about subeclipse after I carelessly remarked on the subversion mailing list that subeclipse wasn't ready for prime time. I was of course contacted by a subeclipse developer who indignantly maintained that subeclipse was much closer to release quality than I had implied. We then had a civil discussion, and while I think his standards for release quality are lower than mine (he doesn't see synchronize as a must-have, I won't take subeclipse seriously until it has it - but nonetheless says the release version will have it), I did learn something that may be of interest to jakarta-commons developers whoare trying to use subversion with eclipse: If you are trying to get the latest version of subeclipse, do not use Eclipse's search for updates of existing features, instead use search for new features. Eclipse kept telling me that there was no version greater than 0.9.22 while this fellow was telling me he'd just released 0.9.26. Running search for new features against the subversion.tigris.org site quickly found what I was looking for. Any jakarta-commons devs who want to try subeclipse but are stuck on 0.9.22 should try this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Net] Bug in FTPFile.Timestamp near end of month
What version of commons-net are you using?
The latest versions on the site (nightly build, source or binary) have a
fix for this problem. It explicitly lets you set a time zone for the
ftp server so that you can get correct dates. In fact, you who have a
real need for this functionality, would be an ideal person to try this
out. If you are interested I will happily help you through any
difficulties you may have with this, although I think you will find it
easy enough to use.
Steve Cohen
W. McDonald Buck wrote:
I'm reporting a minor bug in UnixFTPEntryParser.java, in computing the
timestamp for an FTPFile. I looked briefly at the parsers for the other
systems, and didn't see a similar problem. I'm not subscribed to this
list so please send any response by email.
Scenario:
It is January 31, 2005 at 10:00pm in Boulder, Colorado.
I'm using org.apache.commons.net.ftp to parse a directory of files on a
server 3 timezones to the east, comparing timestamps on the files using
FTPFile.getTimestamp(). I'm getting a wrong answer.
Problem: I'm looking at a file just created in Washington, D.C. and it
is already February 1, 2005 there. The following code in
UnixFTPEntryParser @ line 205 is wrong:
// if the month we're reading is greater than now, it must
// be last year
if (cal.get(Calendar.MONTH) month)
{
year--;
}
cal.set(Calendar.YEAR, year);
At this point month contains the month number of the file, scanned off
the returned ls. This code compares the remote file's month of creation
to the current month on the local machine, and if greater than the local
month, subtracts 1 from the year.
Since the file I'm looking at was created moments ago in Washington,
D.C. where it is already Feb 1, 2005, but it is still Jan 31, 2005 in
Boulder, where the code is running, the test above subtracts 1 from the
year, and sets the timestamp of the FTPFile to Feb 1, 2004 -- off by a
year.
A solution which allows for files in earlier timezones to be a few hours
ahead will, of course, create a bug for files which are a few hours less
than a year old in the current or lagging time zones. Is it fair to say
that precision of measurement is more likely to be important on files a
few hours old than on files already a year old? That is true for me at
least.
I'm not set up to send you a patch for this, but wouldn't it be simple
just to add one day, to compensate for possible time zone differences,
i.e. :
cal.add(Calendar.DAY_OF_MONTH,1);
if (cal.get(Calendar.MONTH)month)
{
year--;
}
cal.add(Calendar.DAY_OF_MONTH,-1);
cal.set(Calendar.YEAR, year);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][VOTE] svn migration
Paul Libbrecht wrote: You're underestimating the eclipse deployment. Am I? I don't think so. I am not talking about general use of subversion, I am talking about use of svn to manage jakarta-commons projects. The only problematic use case I've found with subeclipse is adding a project to a repository. (Of course, there may be others I haven't hit yet). That is clearly not something the ordinary jakarta-commons committer like myself is going to be doing everyday. When I do something more than committing changes or updating (such as preparing a release), I don't use eclipse at all, even for CVS, but follow the command line scripts on the jakarta-commons website. All friends I know who use Windows have no other ways of using cvs than Eclipse... (they know they can do differently but...). But the migration is clearly going to tighten the wish for maturity of Subclipse paul Le 24 janv. 05, à 00:35, Steve Cohen a écrit : However, I recognize that that's a relatively minor use case for jakarta-commons. I presume that most projects would be added to svn at the command line, and this is a one-time operation anyway. Other use cases within Eclipse seemed to work all right. So I will go along with the infrastructure guys, noting that many of the negative votes are not based on actual experience as extensive as even my limited experience. The ride may be a little bumpy, but isn't that par for the course? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][VOTE] svn migration
Tim O'Brien wrote: Alright a sufficient amount of time has passed for public comments and testing. This is a vote thread for migrating commons to SVN. If this vote passes, I'll contact Justin and schedule the least disruptive migration time possible. Tim O'Brien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +0.75 I have reservations about subeclipse based on experience.. I think the Team-ShareProject is broken for SubEclipse. I tried to do this with a local project I play with in my spare time and I couldn't get it to work. However, I recognize that that's a relatively minor use case for jakarta-commons. I presume that most projects would be added to svn at the command line, and this is a one-time operation anyway. Other use cases within Eclipse seemed to work all right. So I will go along with the infrastructure guys, noting that many of the negative votes are not based on actual experience as extensive as even my limited experience. The ride may be a little bumpy, but isn't that par for the course? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
