next possible commons project [regexp]
My summary of the discussion that I started: 1 Many thanks to everybody, who responds; 2 I didn't know about 'pluggable' ORO possibilty, I'll take a look at this (puting something in commons only to have 'commons' in package name is not a good idea); 3 I agree that totally 'bootstraping' funcionality of regexp (like logging) may be dangerous; I was rather thinking about one API for accessing some 'standard' (POSIX, Perl..) regexps in the same way; Something 'pluggable' and having as simple API as possible - in most cases regexp are used (at least by myself) to verifiy given String against given regexp, that's all 4 I know I've seen this before, I know I've seen this before Gotcha: http://jakarta.apache.org/ant/manual/CoreTypes/mapper.html I think I'll try to implement my idea. And, if it'll look interesing, I'll show to commons community. Regards Tomek Pik [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: next possible commons project - [regexp] (or [template?])
From: Tomasz Pik [EMAIL PROTECTED]
Original Message
Java 1.4 has a new regex package, and there are others
that could be
considered if a reliance on 1.4 is to be avoided.
Maybe something like 'Commons Logging' - one hat (with limited
funcionality) for most of the regexp packages
(http://regex.info/java.html)?
Regards
Tomek Pik
Have you found a need for this? If so, have you got some code that
would provide a starting point?
While we're floating implementation-abstraction packages, I've
recently put together a very light weight package to abstract the api
of a templating system from the implementation. I have
implementations for Velocity and Jelly so far. I'd share if people
are interested. So far I'm getting by with basically two versions of
one API method:
public String mergeTemplate(String templateName, Map context)
and
public void mergeTemplate(String templateName, Map context, Writer writer)
It uses Commons Discovery for configuration. It works for me. But
then, my needs are pretty simple.
Joe
--
--
* Joe Germuska{ [EMAIL PROTECTED] }
It's pitiful, sometimes, if they've got it bad. Their eyes get
glazed, they go white, their hands tremble As I watch them I
often feel that a dope peddler is a gentleman compared with the man
who sells records.
--Sam Goody, 1956
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: next possible commons project - [regexp]
Daniel Rall wrote: Jeff Dever [EMAIL PROTECTED] writes: Jakarta does have a top level regexp project: http://jakarta.apache.org/regexp/ Jakarta Regexp is the more simple of the two Jakarta regex packages (I believe that Tomcat uses this one). ORO is much more full featured, offering the full power of Perl 5 regexes. How would yet another regex package seek to differentiate itself from the existing two? AND JDK 1.4 Regex? -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: next possible commons project - [regexp]
In the same way as [logging], by not being a regexp package itself. Of course it may just not be appropriate... Stephen - Original Message - From: Berin Loritsch [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Thursday, September 26, 2002 4:40 PM Subject: Re: next possible commons project - [regexp] Daniel Rall wrote: Jeff Dever [EMAIL PROTECTED] writes: Jakarta does have a top level regexp project: http://jakarta.apache.org/regexp/ Jakarta Regexp is the more simple of the two Jakarta regex packages (I believe that Tomcat uses this one). ORO is much more full featured, offering the full power of Perl 5 regexes. How would yet another regex package seek to differentiate itself from the existing two? AND JDK 1.4 Regex? -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: next possible commons project - [regexp]
Jeff Dever [EMAIL PROTECTED] writes: Jakarta does have a top level regexp project: http://jakarta.apache.org/regexp/ Jakarta Regexp is the more simple of the two Jakarta regex packages (I believe that Tomcat uses this one). ORO is much more full featured, offering the full power of Perl 5 regexes. How would yet another regex package seek to differentiate itself from the existing two? -- Daniel Rall [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: next possible commons project - [regexp]
Stephen Colebourne wrote: In the same way as [logging], by not being a regexp package itself. Of course it may just not be appropriate... To be honest, I don't like the autodiscovery mechanisms in Commons logging. I would be hard pressed to support another something like that for something less likely to be in widespread use. It is possible to just use the project that you need and stick with it for RegEx. There are very few projects out there that are meant to be used as a library that require a regex package (that I am aware of, but I don't get out much anymore). The chances of using two projects that require different RegEx solutions are so minute, that a commons version doesn't seem necessary. That's just my 2 cents. -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: next possible commons project - [regexp]
Stephen Colebourne writes: In the same way as [logging], by not being a regexp package itself. Of course it may just not be appropriate... I just want to point out that jakarta-oro is more than just a regular expression package and already contains the generic interfaces to wrap other packages (as it is, oro already implements 3 different regular expression grammars). It's a simple matter to add a factory to generate generic matchers for arbitrary regular expression packages. The project has plans to do this pending the completion of some other work, but anyone with an immediate need is welcome to put forth a design and start implementing. daniel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: next possible commons project - [regexp]
I just want to point out that jakarta-oro is more than just a regular expression package and already contains the generic interfaces to wrap other packages (as it is, oro already implements 3 different regular expression grammars). It's a simple matter to add a factory to generate generic matchers for arbitrary regular expression packages. The project has plans to do this pending the completion of some other work, but anyone with an immediate need is welcome to put forth a design and start implementing. Sounds like no work needed in commons then ;-) Stephen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: next possible commons project - [regexp]
On Thursday 26 September 2002 12:27 pm, Berin Loritsch wrote: Stephen Colebourne wrote: In the same way as [logging], by not being a regexp package itself. Of course it may just not be appropriate... To be honest, I don't like the autodiscovery mechanisms in Commons logging. I would be hard pressed to support another something like that for something less likely to be in widespread use. It is possible to just use the project that you need and stick with it for RegEx. There are very few projects out there that are meant to be used as a library that require a regex package (that I am aware of, but I don't get out much anymore). The chances of using two projects that require different RegEx solutions are so minute, that a commons version doesn't seem necessary. That's just my 2 cents. The odds of having two projects that require regexp packages that can also tolerate having the definition of regular expression changed underneath them approaches zero. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: next possible commons project - [regexp]
Steve Downey wrote: The odds of having two projects that require regexp packages that can also tolerate having the definition of regular expression changed underneath them approaches zero. I agree with this as far as most applications are concerned. I don't know the original motivation for this thread, but I can offer the reasons why it's thought to be useful in jakarta-oro. Having a generic API for regular expressions allows you to write text processing classes, for example tokenizers, whose use depends on user-defined regular expressions. The developer using the library can then choose a regular expression grammar that meets his particular needs or fancy. I view it more as a library-building convenience. But there are some instances where an application would make direct use of the facility. For example, a text search tool that lets you choose a regular expression grammar that you are familiar with. You write one search algorithm using a single set of interfaces, but the instances of those interfaces are user-determined and decided at run time. For the most part, however, applications that depend on statically predefined regular expression have no use for such a facility. In addition, the facility as conceived in jakarta-oro is not quite analogous to commons-logging because multiple regular expression engines can coexist in the same application and are not automatically chosen for you, while it's my understanding that commons-logging dynamically chooses one underlying logging library (which makes sense for logging). In any case, if anyone who has an immediate need for dynamically pluggable regular expression engines is welcome to make the addition to jakarta-oro instead of waiting for us to get around to it. daniel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: next possible commons project - [regexp]
On Thursday 26 September 2002 02:35 pm, Daniel F. Savarese wrote: Steve Downey wrote: The odds of having two projects that require regexp packages that can also tolerate having the definition of regular expression changed underneath them approaches zero. I agree with this as far as most applications are concerned. I don't know the original motivation for this thread, but I can offer the reasons why it's thought to be useful in jakarta-oro. The original motivation was a proposal to have a commons-regexp package like commons-logging that would abstract out the differences between different regexp packages. IOW, to be able to plug either jakarta-regexp or jakarta-oro in as implementation where a regexp is required. Actually the original motivation was the suggestion that HttpClient's parser use regular expressions to match parts of the HTTP spec, rather than write the parser by hand. The spec provides BNF, and converting that to regular expressions is fairly straightforward. Since the regular expressions would have to be defined and understood by HttpClient, changing the implementation of the regular expression parser would probably cause bugs. Either the regexp would be illegal, or return different results. Also, one of the motivations for commons-logging was that logging needs to interoperate. Two logging packages for an application is a disaster. Two regexp packages for an application is an inconvienence. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: next possible commons project - [regexp]
Steve Downey [EMAIL PROTECTED] writes: On Thursday 26 September 2002 12:27 pm, Berin Loritsch wrote: Stephen Colebourne wrote: In the same way as [logging], by not being a regexp package itself. Of course it may just not be appropriate... To be honest, I don't like the autodiscovery mechanisms in Commons logging. I would be hard pressed to support another something like that for something less likely to be in widespread use. It is possible to just use the project that you need and stick with it for RegEx. There are very few projects out there that are meant to be used as a library that require a regex package (that I am aware of, but I don't get out much anymore). The chances of using two projects that require different RegEx solutions are so minute, that a commons version doesn't seem necessary. That's just my 2 cents. The odds of having two projects that require regexp packages that can also tolerate having the definition of regular expression changed underneath them approaches zero. I agree whole heartedly with that statement. Jakarta Regexp does not handle nearly the same range of regular expressions which ORO handles (its use case is different). Trying to treat the two engines as the same is insanity. -- Daniel Rall [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
