You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Daniel F. Savarese" <df...@savarese.org> on 2003/12/31 17:14:56 UTC
Re: [net] VMSFTPEntryParser bug?
In message <20...@comcast.net>, Steve Cohen writes:
>But what about my point that what we have now is NOT 1.1 compatible?
>VMSFTPEntryParser broke that, although it could, if necessary, be
>reimplemented to use Hashtable instead of HashMap.
I misread your email (unfortunately an increasingly common experience
given the volume of email I have to skim). I thought you said the
unit test wasn't 1.1 compatible. Given that the 1.1 release was
supposed to be 1.1 compatible, I'm in favor of replacing the HashMap
with a Hashtable in a 1.1.1 release and doing a JDK 1.1 build to
spot any other compatibility problems. After that, I say we branch
the code. Without selectable I/O, we're forced to use inefficient
kluges. The guts of the telnet implementation is an abomination, which
I wouldn't be too concerned about except that it underpins the
FTPClient command conversation.
>There was some discussion about mandating 1.3, but that met resistance from
>some. Let alone 1.4. That was a non-starter, as we've already heard from
>several users here on the other thread.
I don't think it's a non-starter. As long as we give advance warning
about how the transition is being handled. Say we branch and commit
to making bug fixes on the 1.1 tree for x number of month. Since ant
is J2SE 1.2 dependent, we ought not move to 1.3 (what do we really gain
from 1.3 anyway?). We can plan a series of 1.2 compatible releases
for some pre-announced period of time all the while working on a
J2SE 1.4 dependent 2.0 release on an experimental code branch. I
know it makes maintenance more difficult, but the code is showing
its age and not making an attempt to reimplement using java.nio is
selling users short in the long run. I'm willing to take the
initiative on the experimental or proposal branch.
>Are there any users of Commons-Net who need 1.1 compatibility? (Remember
>NetComponents is still available).
Available as a courtesy, but unsupported. We'll find out soon enough
if anyone still needs JDK 1.1 compatibility if we migrate to 1.2 and
announce no new features for 1.1.x releases and only bug fixes for
those who request them. To summarize, I now believe the stepping stones
should be J2SE 1.2 and then 1.4. J2SE 1.2 compatibility for releases
1.2.x - 1.9.x on the head branch and J2SE 1.4 for release 2.0 on an
experimental branch. JDK 1.1 compatibility for 1.1.x releases on a 1.1
maintenance branch.
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [net] Branching
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I've found that keeping normal development happening on the
> HEAD branch to be more beneficial than an experimental
> branch. We would branch for bug fixes only, all new
> development proceeds on HEAD.
If projects start moving to Subversion, which will start happening next year
anyway, these sorts of issues would become moot. Not saying that net should
switch; just pointing out one of the benefits of Subversion.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[net] Branching
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
I like the idea of supporting older jvm versions while moving forward
with new development. I would suggest we do the branching slightly
different than you have described. I've found that keeping normal
development happening on the HEAD branch to be more beneficial than an
experimental branch. We would branch for bug fixes only, all new
development proceeds on HEAD.
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 proceeds on HEAD.
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, etc.
>>>>> On Wed, 31 Dec 2003 11:14:56 -0500, "Daniel F. Savarese" <df...@savarese.org> said:
> In message <20...@comcast.net>, Steve Cohen
> writes:
>> But what about my point that what we have now is NOT 1.1
>> compatible? VMSFTPEntryParser broke that, although it could, if
>> necessary, be reimplemented to use Hashtable instead of HashMap.
> I misread your email (unfortunately an increasingly common
> experience given the volume of email I have to skim). I thought you
> said the unit test wasn't 1.1 compatible. Given that the 1.1
> release was supposed to be 1.1 compatible, I'm in favor of replacing
> the HashMap with a Hashtable in a 1.1.1 release and doing a JDK 1.1
> build to spot any other compatibility problems. After that, I say
> we branch the code. Without selectable I/O, we're forced to use
> inefficient kluges. The guts of the telnet implementation is an
> abomination, which I wouldn't be too concerned about except that it
> underpins the FTPClient command conversation.
>> There was some discussion about mandating 1.3, but that met
>> resistance from some. Let alone 1.4. That was a non-starter, as
>> we've already heard from several users here on the other thread.
> I don't think it's a non-starter. As long as we give advance
> warning about how the transition is being handled. Say we branch
> and commit to making bug fixes on the 1.1 tree for x number of
> month. Since ant is J2SE 1.2 dependent, we ought not move to 1.3
> (what do we really gain from 1.3 anyway?). We can plan a series of
> 1.2 compatible releases for some pre-announced period of time all
> the while working on a J2SE 1.4 dependent 2.0 release on an
> experimental code branch. I know it makes maintenance more
> difficult, but the code is showing its age and not making an attempt
> to reimplement using java.nio is selling users short in the long
> run. I'm willing to take the initiative on the experimental or
> proposal branch.
>> Are there any users of Commons-Net who need 1.1 compatibility?
>> (Remember NetComponents is still available).
> Available as a courtesy, but unsupported. We'll find out soon
> enough if anyone still needs JDK 1.1 compatibility if we migrate to
> 1.2 and announce no new features for 1.1.x releases and only bug
> fixes for those who request them. To summarize, I now believe the
> stepping stones should be J2SE 1.2 and then 1.4. J2SE 1.2
> compatibility for releases 1.2.x - 1.9.x on the head branch and J2SE
> 1.4 for release 2.0 on an experimental branch. JDK 1.1
> compatibility for 1.1.x releases on a 1.1 maintenance branch.
> daniel
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
Posted by steve cohen <sc...@javactivity.org>.
This makes a lot of sense, Daniel, and as long as I stay unemployed, I will
even have time to devote to the project :-)
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.
I am working now on a system that should help our interface with Ant. There
has been quite a bit of complaining on the Ant list about the ability to
connect to non-unix servers. We'd previously developed the ability to parse
other systems, but accessing them from an outside system like ant was still
impossible. Ant could, of course, be recoded, but not, at this point,
without requiring it to have far more knowledge of commons-net internals than
I think is healthy. So I am developing an FTPFileEntryParserFactory and some
convenience methods in FTPClient to enable Ant to be recoded decently.
These changes will belong on the 1.2 branch.
Since the strings accepted by this factory method will have been chosen so as
to map to the output of the SYST command (with a backup facility for also
accepting a fully-qualified classname of the parser class), this system could
also be used to implement an auto-detect system. I personally feel that that
is a bell-and-whistle that is less important than the ant interface, since a
programmer will usually know what system he is connecting to, or can easily
find out, but some have asked for it.
I can also make the HashMap-->Hashtable change for the 1.1.1 branch. The JDK
1.1 incompatibility was DISCOVERED through failure of the unit test but the
offending code is in the class being tested, not the test itself. I have
already checked in the fix to the test that does not expect the file list to
be in an order that the parser cannot guarantee.
And it sounds like you have an itch for doing the nio stuff.
On Wednesday 31 December 2003 10:14 am, Daniel F. Savarese wrote:
> In message <20...@comcast.net>, Steve Cohen writes:
> >But what about my point that what we have now is NOT 1.1 compatible?
> >VMSFTPEntryParser broke that, although it could, if necessary, be
> >reimplemented to use Hashtable instead of HashMap.
>
> I misread your email (unfortunately an increasingly common experience
> given the volume of email I have to skim). I thought you said the
> unit test wasn't 1.1 compatible. Given that the 1.1 release was
> supposed to be 1.1 compatible, I'm in favor of replacing the HashMap
> with a Hashtable in a 1.1.1 release and doing a JDK 1.1 build to
> spot any other compatibility problems. After that, I say we branch
> the code. Without selectable I/O, we're forced to use inefficient
> kluges. The guts of the telnet implementation is an abomination, which
> I wouldn't be too concerned about except that it underpins the
> FTPClient command conversation.
>
> >There was some discussion about mandating 1.3, but that met resistance
> > from some. Let alone 1.4. That was a non-starter, as we've already
> > heard from several users here on the other thread.
>
> I don't think it's a non-starter. As long as we give advance warning
> about how the transition is being handled. Say we branch and commit
> to making bug fixes on the 1.1 tree for x number of month. Since ant
> is J2SE 1.2 dependent, we ought not move to 1.3 (what do we really gain
> from 1.3 anyway?). We can plan a series of 1.2 compatible releases
> for some pre-announced period of time all the while working on a
> J2SE 1.4 dependent 2.0 release on an experimental code branch. I
> know it makes maintenance more difficult, but the code is showing
> its age and not making an attempt to reimplement using java.nio is
> selling users short in the long run. I'm willing to take the
> initiative on the experimental or proposal branch.
>
> >Are there any users of Commons-Net who need 1.1 compatibility? (Remember
> >NetComponents is still available).
>
> Available as a courtesy, but unsupported. We'll find out soon enough
> if anyone still needs JDK 1.1 compatibility if we migrate to 1.2 and
> announce no new features for 1.1.x releases and only bug fixes for
> those who request them. To summarize, I now believe the stepping stones
> should be J2SE 1.2 and then 1.4. J2SE 1.2 compatibility for releases
> 1.2.x - 1.9.x on the head branch and J2SE 1.4 for release 2.0 on an
> experimental branch. JDK 1.1 compatibility for 1.1.x releases on a 1.1
> maintenance branch.
>
> daniel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org