[ 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
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
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
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
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.
Cheers
Rory
Henri Yandell wrote:
On 9/9/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
Steve Cohen wrote:
I am
, 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
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
that there are many still in this
boat.
Steve Cohen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
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
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
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
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;
, 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
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
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
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
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
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]
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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]
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
? 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
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
...
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
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
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
=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
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
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
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
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
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
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
/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
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.
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
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
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
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
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
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
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[]
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
, 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
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
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
1 - 100 of 271 matches
Mail list logo
