commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Cohen <sco...@javactivity.org>
Subject Re: Incorrect documentation of FTP task [net]
Date Wed, 18 Feb 2004 03:04:11 GMT
On Tuesday 17 February 2004 8:27 pm, Steve Cohen wrote:
> On Tuesday 17 February 2004 10:11 am, Dominique Devienne wrote:
> > > From: Steve Cohen [mailto:scohen@javactivity.org]
> > >
> > > While it is true that the CVS HEAD of commons-net is required and while
> > > it is
> > > true that jakarta-oro is required (jakarta-oro is now required for any
> > > uses
> > > of the ftp task using commons-net), I don't believe it is true that
> > > 2.0.8 of
> > > oro is required.  As far as I know, any jakarta-oro verson greater than
> > > VERSION 2.0.1 will work.  Certainly, the latest commons-net code takes
> > > no special advantage of the latest oro-code.
> >
> > Why can't commons-net use java.util.regex when running under JDK1.4+,
> > rather than requiring Jakarta-oro, when a good Regular Expression is
> > already built in? Ant already does this (use ORO or JDK regex). Thanks,
> > --DD
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
>
> To have relied on the JDK regex would tie commons-net to JDK 1.4+ unless we
> could somehow have managed this conditiionality.  The decision to go with
> oro was made when JDK 1.4 was in much less widespread use, and may even
> have come before the release of 1.4.   How does Ant do it?  Is Ant now
> using preprocessed code?  Please point me at the place in ant where you
> accomplish this.
>
> This comes up more frequently now in Ant because Ant 1.6 made the switch to
> commons-net from NetComponents.  NetComponents did not rely on oro because
> it did not do regular expression parsing of the listings.  It was also much
> less flexible because of that - it could only handle unix FTP servers. 
> Using regexes opened up a path to implement support of other server types
> more easily.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Answering my own question, I now see what Ant is doing - in the 
ant/src/main/org/apache/tools/ant/util/regexp package.

http://cvs.apache.org/viewcvs.cgi/ant/src/main/org/apache/tools/ant/util/regexp/

You've built an interface to encapsulate the choice in regex implementations 
with automatic checking.  Sweet!  Perhaps we could port it to commons-net - 
it's too ant-specific as it stands.  But, do we really want all jars used by 
ant to make their own copy of this functionality?  I don't think so.  That 
starts to get messy really quick.

Perhaps this checker mechanism could be ported to commons (a la 
commons-logging).  Then it could be available to other clients, in 
particular, to commons clients.  But of course then we'd be requiring yet 
another jar in order to use ant!  Doh!  Unless this jar were on the DEFAULT 
classpath of ant.  

I think we ought to think seriously about what we are doing here before we 
rush into coding anything like this.

There is also another ant task that unconditionally requires oro, by the way - 
<perforce>.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message