I wrote:
>+1 on the TLP vote
s/vote/idea/
will vote +1 when the actual vote is held.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
+1 on the TLP vote
In message <[EMAIL PROTECTED]>, =?iso-88
59-1?Q?J=F6rg_Schaible?= writes:
>I never got why things like ECS, ORO, regexp are not part of commons. =
>What makes them different to logging or digester? I can understand the =
>separation for something like POI, but not necessarily f
In message <[EMAIL PROTECTED]>, Rory Winston writes:
>I knwo you said that you were going to have a look at adding connect
>timeout functionality to FTPClient. I had some spare time today, and I
>decided to see if I could give it a go on the 2.0 branch. However, I
Sorry. I plum forgot. Thank
In message <[EMAIL PROTECTED]>, "Christian Hufgard (J
IRA)" writes:
>FTPClient/DefaultSocketFactory does not regard default timeout
>--
>
> Key: NET-141
> URL: http://issues.apache.org/jira/browse/NET-141
In message <[EMAIL PROTECTED]>, Rory Winston writes:
>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).
+0
I was hoping to see more radical API and implemen
In message <[EMAIL PROTECTED]>, Anil Philip wr
ites:
>I googled and read that the oro.jar is missing.
>However my application is sensitive to download times
>and I dont wish to add the oro.jar if possible - I am
>not using regex here.
>Is there any way out?
The oro jar 77k in size (a good deal sm
In message <[EMAIL PROTECTED]>, "Rob Hasselbaum" writes:
>Could a committer please review and commit my patch for bug 38688? I'm
>preparing a patch for a different bug now that impacts some of the same
>lines of code and it would be nice to avoid a messy merge later.
Done. You can fetch it from
In message <[EMAIL PROTECTED]>, Matt Benson
writes:
>As an interested observer, I tend to agree that if
>there is no conceivable use for binary list results,
>[net] may as well adapt automagically.
I was about to open a Bugzilla enhancement request to track this, but
as I was writing that if FTP
In message <[EMAIL PROTECTED]>, Mario Ivankovits writes:
>Sure, I can do this, but shouldnt [net] try to be RFC compliant?
>Leaving it to the user to be compliant is odd, isnt it?
The original intent of commons-net was to provide low-level access to
IETF protocols. That meant providing primitive
In message <[EMAIL PROTECTED]>, Mario Ivankovits writes:
>Ever heard of this?
>
>> I ran into a problem with a strict FTP server that needs the LIST
>> command to be send while on ascii mode. If it is sent on binary mode,
The RFC states the data transfer for LIST is of type ASCII or EBCDIC.
It's
In message <[EMAIL PROTECTED]>, Rory Winston writes:
>* You're correct that there is no inherent advantage, at least
>functionality-wise, in removing the ORO dependency. I think the major
I didn't mean to suggest that the dependency shouldn't be removed.
I was just being nitpicky and saying tha
In message <[EMAIL PROTECTED]>, Steve Cohen writes:
>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.
My +1 wasn't intended to reflect a vote. It was just shorthand for
"I concur."
>While I'm generally in
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
In message <[EMAIL PROTECTED]>, Rory Winston writes:
>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
I've long advocated branching to take advantage of JDK 1.4, but I
had a more radical agenda. I belie
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
g writes:
>Added getter/setter for Input/OutputStream
>+ public InputStream getInputStream() {
>+ return _input_;
>+ }
I really don't think these should be public. Otherwise, one might as well
work directly with the Socket
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
g writes:
>Removed dependency on TelnetClient
...
>-public class FTP extends TelnetClient
>+public class FTP extends SocketClient
>From RFC 959:
control connection
The communication path between the USER-PI and SERVER-PI for
t
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
g writes:
...
>URL: http://svn.apache.org/viewcvs?rev=373207&view=rev
>Log:
>Changed to JD 1.4 regex package
...
>+import java.util.regex.MatchResult;
There is no MatchResult interface in JDK 1.4. It was added in JDK 1.5.
daniel
--
In message <[EMAIL PROTECTED]>, Rahul
Akolkar writes:
>No, haven't had to deal with such a situation. But doesn't this mean
>that the code will only work on a subset of the 1.3 JDKs (Sun)? If so,
>maybe (3) isn't all that bad?
In general, I am biased against introducing dependencies on com.sun p
In message <[EMAIL PROTECTED]>, Niklas Gustavsson writes:
>Fair enough, but if it is treated as binary, shouldn't the type be "I"?
That's what I get for not doing my homework :) Okay, so I have no idea
why it is sending B (other than it being a mistake). I'm not even sure
why I thought the spec
In message <[EMAIL PROTECTED]>, Niklas Gustavsson writes:
>When issuing ftp.type(FTP.EBCDIC_FILE_TYPE), FTP will send "TYPE B".
>This is not correct according to RFC 959 where the EBCDIC type is
>specified as "E".
I'm pretty sure sending B is intentional since we do not perform automatic
transl
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
In message <[EMAIL PROTECTED]>, Joe Germuska writes:
>>overdue, probably due to that everyone probably thinks he is a
>>already committer)
>
>That's what I thought!
Same here.
+1
daniel
-
To unsubscribe, e-mail: [EMAIL PROTE
In message <[EMAIL PROTECTED]>, Mario Ivankovits writes:
>Due to some user requests I would like to know if you think its possible
>to get VFS out of the sandbox.
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
In message <[EMAIL PROTECTED]>, "Jeffrey D. Brekke" writes:
>I'm having hanging problems running the functional tests under 1.5, but
>1.4.2 works ok. Anyone else seeing this running "maven test:functional"?
ListingFunctionalTest hung for me with both because of my firewall.
I added a call to en
"Rory Winston" writes:
>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 "s
>traightforward" issues in BZ. It w
In message <[EMAIL PROTECTED]>, Lindberger
Per writes:
>In org.apache.commons.net.ftp.FTP there is a public method named
>removeProtocolCommandistener. I think this would be worth changing to
Thanks. I applied the fix.
daniel
---
In message <[EMAIL PROTECTED]>, "Tim O'Brien" write
s:
>This is a vote thread for migrating commons to SVN. If this vote
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
In message <[EMAIL PROTECTED]>, "Noel J. Bergman" w
rites:
>We don't version Commons as a single component, and I don't know that we
>want to force everyone to always take every single component. Someone
>wanting to build all of Commons is not the norm.
I didn't want to reopen the issue. I was
In message <[EMAIL PROTECTED]>, Henri Yandell writes:
>On Sun, 19 Dec 2004 00:00:20 +1300, Simon Kitching
><[EMAIL PROTECTED]> wrote:
>> svn 1.1 (released 2004-09-29) supports "symbolic links". Perhaps that
>> would resolve the issue by allowing us to (manually) build an
>> alternative directory c
"Rory Winston" writes:
>I think we should push out a 1.3.0 release pre-xmas. There are
>many, many enhancements and fixes, and also a new component in HEAD.
+1
BTW, thanks for all the work you've done going through and addressing
all of those issue reports.
daniel
---
In message <[EMAIL PROTECTED]>, Vic Cekvenich writes:
>to the people of thinking of releaseing email:
>
>I think a lot more work is in net's smtp package such as simple emailer.
>So, maybe build on that,that is a superset.
I didn't notice the original message this was in reply to, but I thought
c
In message <[EMAIL PROTECTED]>, "Rory Winston" w
rites:
>Has there been any code contributed re: (S)NTP? I feel I may have a use for
>this in my day-to-day, and I am just wondering if there has been any movs
>toward including this. I see there is a TODO on the list that says "review
>(S)NTP code",
In message <[EMAIL PROTECTED]>, "Rory Winston" w
rites:
>Actually, just having a quick perusal, I think this may be the culprit
...
>I've fixed, tested, + committed.
Thanks. That's the second straight sloppy patch I've made. I always
tell myself I shouldn't touch code after midnight :) I must
>http://issues.apache.org/bugzilla/show_bug.cgi?id=23488
>
>OS400 FTP server directory listing is not being parsed properly in FTPFile cla
>ss.
>
>--- Additional Comments From [EMAIL PROTECTED] 2004-09-23 13:25 ---
>Should this bug be marked as FIXED? I can see that we have an OS400 parse
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
.org writes:
>--- Additional Comments From [EMAIL PROTECTED] 2004-09-23 15:00 ---
>Sorry, my bad. I didn't realize that Daniel has an AIX parser in there already
>.
I don't think I wrote any of the parsers other than the original default
In message <[EMAIL PROTECTED]>, =?iso-8859-1?q
?jo=FFe3o=20Paulo=20souza?= writes:
>I´m using commons.net.ftp package to make the ftp transaction of files from one
> server to other.I´m connecting for example with an id = bla.
>So all files stored by the method storeFile from ftpClient class s
In message <[EMAIL PROTECTED]>, Joseph Hindsley
writes:
>I had submitted a patch last week for the FTP and FTPClient classes
>(http://issues.apache.org/bugzilla/show_bug.cgi?id=30970) that doesn't
>seem to have had any activity. The patch changes FTP to extend
>SocketClient instead of TelnetCl
+1 on moving from Bugzilla to JIRA.
I've yet to meet an issue tracking system that didn't cause me issues,
but JIRA clearly has more features to support planning, status assessment,
and development. The Foundation already has free access to the product
and source code and is already using it, so
In message <[EMAIL PROTECTED]>, Steve Cohen writes:
>A diff -u patch file is best. Please don't send the actual files.
>cvs diff -u [files] >> patchfile.txt
As a reminder, we've previously vetoed changes of this sort (in FTP.java):
public int sendCommand(String command, String args) throws
In message <[EMAIL PROTECTED]>, "Ash, Mi
chael L" writes:
>Doing the setControlEncoding would be wonderful, I have recompiled the
>code doing what you suggested and it does work, but I um can't use it
>because its not an official release :)
At the moment CVS HEAD is basically identical to the la
In message <[EMAIL PROTECTED]>, Steve Cohen writes:
>Sorry I missed your earlier post. The answer is, unfortunately, that the
>package does not support the easy conversion to UTF-8.
If he needs to change the encoding for the control connection, he can
recompile the source with FTP.__DEFAULT_ENC
In message <[EMAIL PROTECTED]>, Jeffrey D. Brekke writes:
>Probably my fault back when we changed package names. Sorry about that.
I don't think it occurred to anyone at the time that there were
all of those hardcoded links that needed to be converted. If it's
anyone's fault, it's mine since I
What I tried to do was replace the references to straight up files with
[EMAIL PROTECTED] classname} or [EMAIL PROTECTED] classname#member} and references to
in
file anchors with [EMAIL PROTECTED] #member}. But there were quite a number of
classname.html#_top_ references and I replaced those wi
In message <[EMAIL PROTECTED]>, Steve Cohen writes:
>Have at it, Daniel. You can surely do the job quicker than I can.
Alrighty, I'll get to it and report back when I finish.
daniel
-
To unsubscribe, e-mail: [EMAIL PROTECT
In message <[EMAIL PROTECTED]>, Steve Cohen writes:
>These broken links are almost all of the following form
>
>
>
>Of course, these won't work.
>
>Can someone help me answer these questions?
>
>How did they ever work?
>Is this the result of some global search and replace gone awry?
>What is t
[X] +1 - Steve Cohen should proceed with release of commons-net 1.2.2
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
.org writes:
>a listing. Assuming it's implemented, it would also make sense to have FTPFi
>le
>return the type as being UNKNOWN_TYPE for these other cases.
I haven't kept up with all of the parser changes, but that's why
FTPFile.UNKNOWN_TYPE ex
I wrote:
>want to escape; but quotemeta works equally well)? Why use a negative
>look-behind assertion in ((?negative look-behind assertion is redundant because if there's a character
>present that's not a slash, then it's not the start of the input)? Of
I forgot to add that that's assuming sin
In message <[EMAIL PROTECTED]>, Mario Ivankovits writes:
>It looks like Perl and Java are very (very) simmilar. So asking ORO to
The Java regex syntax is almost a superset of Perl, which is why I don't
see the impact of using a Perl engine for JDK 1.3 and java.util.regex
for J2SE 1.4 as being ma
In message <[EMAIL PROTECTED]>, Mario Ivankovits writes:
>Whew! Fast work, thank you.
If no one involved in VFS has the time to get involved as a committer
for jakarta-oro, I need to know more or less by when you would need
a 2.1 release of jakarta-oro to be released so you don't have to ask
user
In message <[EMAIL PROTECTED]>, "Rami Ojares" writes:
>The problem with having a generic interface for different regex implementation
>s
>is that the syntax and semantics of regexes are different. I want to know
>EXACTLY what my regexes match and what constucts/syntax I can use.
Somehow I missed
In message <[EMAIL PROTECTED]>, Mario Ivankovits writes:
>jakarta-oro seems a very powerfull solution, but even if is intentaion
>was only to be an interface - its size has reached 100K - i already hear
I made the change to PatternMatchingEngineFactory we discussed (use
Class.forName() for all
In message <[EMAIL PROTECTED]>, "Noel J. Bergman" w
rites:
>Daniel, are you still interested/trying to move ORO into Commons? What is
I'm interested in doing whatever it will take to get people using the library
or who should be using the library more involved in development. At first
I thought
In message <[EMAIL PROTECTED]>, Mario Ivankovits writes:
>jakarta-oro seems a very powerfull solution, but even if is intentaion
>was only to be an interface - its size has reached 100K - i already hear
I didn't mean to give the impression that its intention was to be only
an interface, but to
In message <[EMAIL PROTECTED]>, Paul Libbrech
t writes:
>I keep believing, however, that such a thing should be done by Jexl or
>something else... it makes no sense to need this getStatic, at least
>compared to Java.
I agree. After I shot off my email I was going to reply to it and add
"maybe
I've been experimenting with Jelly Swing recently after finding Groovy
Swing problematic, trying to see whether it will make GUI prototyping
faster. I may have missed it, but I couldn't find a tag in any of the
tag libraries to access a static class field. There's invokeStatic
for invoking stati
In message <[EMAIL PROTECTED]>, Steve Cohen writes:
>This will be a fix release to fix the problem introduced in 1.2.0 that it will
>not compile using jdk < 1.4 and nothing else.
Just to be procedurally correct, here's my +1 again (that way you
can provide a link to the thread in the vote result)
In message <[EMAIL PROTECTED]>, Steve Cohen writes:
>I think a fix release is needed for this.
>Guys, what should the name of such a version be?
1.2.1
>Are there any guidelines about releasing a fix version for such a small but
>vital thing?
Just roll another release. Here's my +1 in advance.
In message <[EMAIL PROTECTED]>, Steve Cohen writes:
>Where do we stand on this?
Hey, you called the vote, you're supposed to know :)
>I have two +1s from known committers to the project, another +1 from Mario,
>who I don't believe is a committer on this project but may be one for some
>other c
In message <[EMAIL PROTECTED]>, Jeffrey D. Brekke writes:
> and allow for hooking onto goals.
>
>I think we can extend the preparation of the tar dists with
>. Inside the postgoal, copy the NOTICE file into the
>correct directory. I'll try it soon.
Thanks for the education. The only reference
In message <[EMAIL PROTECTED]>, Jeffrey D. Brekke writes:
>standard stuff won't do. Or better yet, lets just put the two lines
>from the NOTICE.txt into the README.txt.
We can't do that because putting it in NOTICE is required by the Apache
License. If I didn't miss anything, we're talking abou
In message <[EMAIL PROTECTED]>, Steve Cohen writes:
>The candidate release is available at http://cvs.apache.org/~scohen/
...
>Please vote on this release. If the vote passes I will produce the release.
+1
-
To unsubscribe, e
[ ] +1 Welcome Rory!
[ ] 0 No comment.
[ ] -1 Not yet, because ...
Rory Winston has contributed significant functionality additions
to the Commons Net NNTP package in the form of patches over the
past year:
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=105360087319228&w=2
http://marc
In message <[EMAIL PROTECTED]>, "Rory Winston" writes:
>well - day job permitting). I am not a committer as of yet - I do
>realize that you mentioned making me a committer before - what would it
>take to get myself on the committers list? AIUI, it's a voting process
>by existing committers?
We ju
In message <[EMAIL PROTECTED]>, robert burr
ell donkin writes:
>is it time for jakarta commons to move to the new wiki...?
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
In message <[EMAIL PROTECTED]>, "Rory Winston" w
rites:
>Whereas the new Wiki is:
>
>http://wiki.apache.org/old/CommonsNet/FrequentlyAskedQuestions
I'm confused. That page is not editable (it's listed as an immutable
page) and does not appear on the list of wikis at http://wiki.apache.org/
The p
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
writes:
> FTPFile[] results;
>
> if ((socket = _openDataConnection_(FTPCommand.LIST, pathname))
>== null)
> -return null;
> +return new FTPFile[0];
I don't think that's the
In message <[EMAIL PROTECTED]>, Steve Cohen writes:
>This is all true, Daniel, but I think the initial motivation of Dominique
>Devienne was to REMOVE the requirement that oro be on ant's runtime classpath
I wrote:
>wrapper and J2SE 1.4 autodetection, in which case I would hope the point
>would
In message <[EMAIL PROTECTED]>, Dom
inique Devienne writes:
>Probably not... I simply try to avoid having twice the same functionality on
>my classpath, and JDK1.4+ fulfills my regexp needs (albeit simple) just
>fine. I've read a few times that ORO is superior to the JDK's regexp impl,
>so it's no
In message <[EMAIL PROTECTED]>, Steve Cohen writes:
>You've built an interface to encapsulate the choice in regex implementations
>with automatic checking. Sweet! Perhaps we could port it to commons-net -
...
>Perhaps this checker mechanism could be ported to commons (a la
>commons-logging).
In message <[EMAIL PROTECTED]>, Steve Cohen writes:
>Question - primarily for Daniel: Do you think it makes sense to dial back to
>using jakarta-oro-2.0.1 in commons-net.1.1.1 to preserve JDK 1.1.
>compatibility? What features/bug fixes would be lost? Unless we either do
>this or rewrite, we
In message <[EMAIL PROTECTED]>, Jeffrey D. Brekke writes:
>I think any committer could be the release manager, +1.
>
>I haven't had time to look at the code changes deeply. Based on what
>I've seen and what was discussed, I'm +0 on the release of 1.2.0, but
>I do think that a jdk 1.1 compatible v
In message <[EMAIL PROTECTED]>, steve cohen writes:
>Oops! CVS doesn't have "undelete", does it? :-( Sorry for not
>knowing/understanding this rule. Do we add it back in (losing history) or is
>there some way to put that back as well? What is best way to proceed?
It looks like you already t
In message <[EMAIL PROTECTED]>, steve cohen writes:
>I also agree that there is a need for postfiltering (to solve the "most recent
>version only" problem), although, actually, I think prefiltering out the
>dupes may be the way to go. Either way, some kind of hook will be necessary,
>one that's
In message <[EMAIL PROTECTED]>, "Noel J. Bergman" w
rites:
>> We may need a signed CLA before we can include it should it pass muster.
>
>This is an area I find confusing, as well, but AIUI to date we mostly
>require a CLA only from a committer. If the codebase is significant (a grey
>area), one
In message <[EMAIL PROTECTED]>, Jeffrey D. Brekke writes:
>[Alternatives to VMS Parser/Version issue]
>
>Another alternative is to create another parser, creating two VMS
>parsers, potentially sub-classing one VMS parser to avoid code
>duplication. A specialized VMS parser that will filter off mu
In message <[EMAIL PROTECTED]>, steve cohen writes:
>I keep coming back to the ant use case and how we'd handle it there. I
>suppose we could add yet another parameter to the ant task to handle
>this odd case, but I'd rather not. I'm still not happy with this but I don't
>have a better sugge
In message <[EMAIL PROTECTED]>, steve cohen writes:
>Almost right, Daniel. I think it filters out dupes when versioning is turned
>on.
I thought that's what you said before, but I saw
if (versioning) {
files = super.parseFileList(listingStream);
} else {
in VMSFTPEnt
In message <[EMAIL PROTECTED]>, steve cohen writes:
>After looking at the code, I have a different idea. Reimplementing
>createFileList() in terms of parseFileList() would negate the whole reason
>for inventing createFileList() in the first place - your suggestion wishing
Agreed. I'm lagging
In message <[EMAIL PROTECTED]>, steve cohen writes:
>Except for the issue outlined below (re FTPFileListParser deprecation) my
>latest commit have implemented everything that Daniel discussed earlier
>today:
Great! I added caching of the system name to avoid issuing SYST to the
server for ev
I wrote:
>Looking at the code, I would have to agree that parseFileList should
>be preserved and move into FTPFileEntryParser. That allows us to
>rewrite createFileList to call parseFileList instead of
>FTPFileList.create, which allows the VMSFTPEntryParser to continue
>doing its thing.
Scratch
In message <[EMAIL PROTECTED]>, steve cohen writes:
>There's still one problem with deprecating FTPFileListParser.
>The one method of this interface (parseFileList()) is used in the
>VMSFTPEntryParser. There is an implementation here that is distinct from the
>default one in FTPFileListParserIm
In message <[EMAIL PROTECTED]>, "Daniel F. Savar
ese" writes:
>I forgot to add that I think we need a beta release for 1.2 to give us
I also forgot to add that there's at least one pending code submission/patch
that we need to review and include before a 1.2 release. I believe it
was the NTP/SNT
In message <[EMAIL PROTECTED]>, steve cohen writes:
>1) deprecate listFiles() methods that take a FileEntryParser parameter.
>2) reimplement listFiles() to do what getFileList(null) now does.
>3) reimplement listFiles(String pathname) to do what getFileList(null,
>pathname) now does.
>4) rename g
In message <[EMAIL PROTECTED]>, steve cohen writes:
>On the fresh checkout I did, there was an ftp2 directory but it was empty.
>Is that another reason to get away from CVS - that it's too hard to get rid of
>directories?
Yep. CVS doesn't treat directories the same as files. I have -P flags
nex
I forgot to add that I think we need a beta release for 1.2 to give us
a chance to back out or fix anything that we discover is suboptimal
before we set the stuff in stone in the API. Mostly I'm thinking of
method signatures. Anyway, to recap the proposed deprecation list:
interfaces:
In message <[EMAIL PROTECTED]>, steve cohen writes:
>Problem is, the current implementations of FTPFileEntryParser, also, for
>reasons of backward compatibility, implement FTPFileListParser. I don't
>remember exactly why I did that but there was a reason. But the problem is
>that deprecating
In message <[EMAIL PROTECTED]>, steve cohen writes:
>In looking over the source to AIXFTPEntryParser, I see the following comment,
>apparently from the author, ([EMAIL PROTECTED]):
It sounds like you're already doing the detective work, so I'll leave
it to you.
>I seriously must wonder if this
In message <[EMAIL PROTECTED]>, steve cohen writes:
>Is there a recommended way to go about this? It was doubtful to me that
>anyone had ever used these packages, but I now see that I was wrong. Someone
>went and implemented an AIXFTPEntryParser in the ftp2.parser package (and not
>on the mai
In message <[EMAIL PROTECTED]>, Martin Cooper writes:
>On Fri, 2 Jan 2004, Daniel F. Savarese wrote:
>> All I was getting at was what to name the tag. My understanding was
>> that a tag needs to be created as a branch. I should have used
...
>to point out that there a
In message <[EMAIL PROTECTED]>, Hen
ri Yandell writes:
>What do people think about calling a vote for promotion out of the
>sandbox now?
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PR
In message <[EMAIL PROTECTED]>, steve cohen writes:
>On Thursday 01 January 2004 04:17 pm, Jeffrey D. Brekke wrote:
>> Should we roll out a release of this version?
+1. We clearly have lazy consensus, but we need a formal vote cc'ed
to the PMC list for all to be kosher.
>I guess so. It should
In message <[EMAIL PROTECTED]>, steve cohen writes:
>This code was calling a method in ORO that returned a Collection, also not
>JDK1.1 compatible. Since the older ORO method that returned a Vector had
>been deprecated, I looked at what it was doing, which was simply splitting a
>string on a c
In message <[EMAIL PROTECTED]>, steve cohen writes:
>Seems to me the HashMap ---> Hashtable change could be made against HEAD.
>It's only NECESSARY for 1.1 compatibility but it poses no great problem for a
>1.2 compatible version; it isn't as if this would impact some functionality
>deep in t
In message <[EMAIL PROTECTED]>, Jeffrey D. Brekke writes:
>Daniel, I agree with all your ideas, but it seems to me you can branch
>from any tagged point in the revision history so I'm not sure what the
>idea is behind deleting/renaming the tags.
All I was getting at was what to name the tag. My
I wrote:
>Sanity check the steps to make sure this is what we want:
> o rename NET_1_1_0 tag to something else, let's say FOO
> o tag FOO as NET_1_1_0, this time with the -b flag to make it a branch tag
I left out "delete the FOO tag" ...
>If that seems like not a good thing, another option is
In message <[EMAIL PROTECTED]>, steve cohen writes:
>I am not completely CVS-literate and setting up the branches is beyond my
>current level of experience but probably would be good experience for me.
In my response to Jeffrey's email, I asked about whether we wanted to
replace the existing NET
>I wrote:
>In message <[EMAIL PROTECTED]>, Jeffrey D. Brekke writes:
>>Its just a suggestion. I can live with an experimental branch also,
>>just in other projects I've been involved with, if HEAD isn't the
>>focal point of new development, it get confusing where to put stuff,
>>what is working,
In message <[EMAIL PROTECTED]>, Jeffrey D. Brekke writes:
>After we make a 1.1 compatible release and tag, that will be the
>branch point for any 1.1 fixes. Next we can make a release with 1.2
>support and tag, that will be the branch point for any 1.2 related
>fixes. All development then procee
In message <[EMAIL PROTECTED]>, Geir Magnusson
Jr writes:
>Don't forget that not all platforms have 1.4 or a mature 1.4 that
>people trust. it too a while for apple to get 1.4 out to OS X - I
>wouldn't use OS X in production of course, but it's my development
>platform...
Absolutely. J2SE 1
1 - 100 of 161 matches
Mail list logo
