In message <[EMAIL PROTECTED]>, 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. daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
