commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel F. Savarese" <>
Subject Re: [vfs][all][poll][RESULT] regular expression library or jdk1.4 as minimum requirement
Date Tue, 15 Jun 2004 19:45:29 GMT

In message <>, 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 stress that it's not just an engine implementation.

>others yelling ;-)

It's possible to split up oro into several smaller jars, one with the
core interfaces, one for each engine, one with the utility classes, etc.
Offering multiple smaller jars has been on a TODO list and is just a
matter of changing the jar generation in build.xml.  Not a big deal,
but one of those things I always hoped someone with the need/desire
would come along and do.  I know people are more interested in using
regular expression libraries than in maintaining or advancing their
development (I'm the same way).

>Might it be possible to split the discovery/interfaces (use 
>class.forName for its own implementations too) and the implementation to 
>have a small(er) "discovery library"?

Yes, not hardcoding in the Awk, Glob, and Perl5 engine constructors into
PatternMatchingEngineFactory occurred to me last night.  Since I'm already
distracted from work, I can make that change now and make a first pass
at repackaging the jars.  So as not to break Gump builds, I'll probably
continue to generate a jakarta-oro-version.jar instead of a
jakarta-oro-all-version.jar in addition to the componentized jars.
But don't hesitate to ask for commit privileges (a PMC vote would grant
them in short order) and make any changes you see as necessary.  I've been
trying to get jakarta-oro development to be user-driven, but haven't done
a good job.

>For sure, i know it IS possible ;-), the question is, is this something 
>the ORO project would like to do, or could this be a starting point to 
>refactor ORO and build a "commons-RegexpDiscovery", or move the 
>implementations to jakarta-regexp, or ....

I've previously put forward the idea of opening up jakarta-oro (and
jakarta-regexp) to any commons committer as a first step to trying to
resolve some of the redundancy of effort and decide the future of
the regular expression libraries in light of the perception of their
impending obsolecence (e.g., should they serve as a temporary bridge
until everyone has migrated to J2SE 1.4 and then be shelved?).
Anyway, my only concern is not to change the package names of any of
the existing classes--or at least provide a smooth migration path
that won't immediately break existing code--should a complete move
to Jakarta Commons be made.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message