Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Content-Type: text/plain;
  charset="iso-8859-1"
From: steve cohen <scohen@javactivity.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
Date: Wed, 31 Dec 2003 11:07:40 -0600
User-Agent: KMail/1.4.3
References: <200312311614.hBVGEueX026563@gandalf.savarese.org>
In-Reply-To: <200312311614.hBVGEueX026563@gandalf.savarese.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <200312311107.41013.scohen@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 <200312301411.31997.stevecoh1@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