Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Message-Id: <200402182025.i1IKPFbp031282@yoda.savarese.org>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
cc: "'Ant Developers List'" <dev@ant.apache.org>
Subject: Re: Incorrect documentation of FTP task [net] 
In-reply-to: Your message of "Wed, 18 Feb 2004 09:14:04 CST."
             <830BF4914C3C4B4EB1C438D93ABF897A04D8B5@lgchexch011.ad.lgc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 18 Feb 2004 15:25:15 -0500
From: "Daniel F. Savarese" <dfs@savarese.org>


In message <830BF4914C3C4B4EB1C438D93ABF897A04D8B5@lgchexch011.ad.lgc.com>, 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 not a question of merit, but simply to avoid duplication (I used
>java.util.regex with the REX/Shallow Parser expressions, and it worked fine,
>so that's good enough for me.)

What I'm getting at is tht oro is not a regex engine.  It is a collection
of regex engines and additional text processing features.  It provides
generic interfaces for pattern matching.  Why reinvent generic interfaces,
when they are already there?  So I implemented the glue last night to make
that evident.  I could just go all the way and add the java.util.regex
wrapper and J2SE 1.4 autodetection, in which case I would hope the point
would become moot since you'd have the desired functionality.  Although,
I'd prefer for other to get involved to at kibitz about the glue
(implementing the java.util.regex wrapper is just a matter of setting
aside a little time).  If oro were a part of commons would this even be an
issue?  I think a desire for Commons Net to use a regex engine abstraction 
other than oro may be more of a perceptual issue than an engineering issue.
I'm not suggesting Ant change it's wrapper since it's already there.  It's
just that Steve indicated it wasn't quite general enough for Commons Net
and I already know that the code changes to Commons Net will be minimal
with oro because it already uses PatternMatcher and PatternCompiler.

>I understand Jakarta libraries must run on many JDKs, so cannot require JDK
>1.4+, but OTOH, it's annoying to have useful OS projects you're interested
>in pick up so many other dependencies, often for just a few convenient
>classes, thus using 1% of that dependency, which often has a large overlap
>with other libraries from the JDK or other libraries one's forced to use
>(thru indirect dependencies).

Too true.

daniel


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