I am not seeing any -1s on this, so I would like to proceed with a VOTE to accept the code and start the IP clearance process. For that I need a definitive snapshot of somewhere that I can point to for the VOTE and clearance docs. My git-foo is pretty limited. Can someone suggest a stable URL that we can use to identify the code that we will be accepting, should the VOTE pass?
Thanks! Phil On 10/25/15 12:25 PM, dbrosIus wrote: > +1 and git please > > -------- Original message -------- > From: Phil Steitz <phil.ste...@gmail.com> > Date: 10/25/2015 3:15 PM (GMT-05:00) > To: Commons Developers List <dev@commons.apache.org> > Subject: Re: Proposed Contribution to Apache Commons, > > On 10/2/15 12:08 PM, Gary Gregory wrote: >> Well, a champion can volunteer to shepherd this through our incubator I >> suppose, > OK, I will volunteer to do this. I propose that we start this as a > Commons Sandbox project. To do that, we need a VOTE to accept the > code, a software grant and the IP clearance form [1] submitted to > the Incubator PMC. We can use either git or svn for the new sandbox > repo. > > Any objections? Any preference for git or svn? > > Phil > > [1] http://incubator.apache.org/ip-clearance/ip-clearance-template.html > > >> like CommonsRDF, which seems pretty inactive ATM. There is also >> the issue of "donate and forget" vs. staying plugged in the community. >> >> I just do not have the extra FOSS cycles to dig into the code ATM to see >> what's under the hood. >> >> Gary >> >> On Fri, Oct 2, 2015 at 12:01 PM, Phil Steitz <phil.ste...@gmail.com> wrote: >> >>> On 10/2/15 11:46 AM, Gary Gregory wrote: >>>> I do not have time to dig into this one ATM but I'd like to give my 2c. >>>> >>>> Does this project introduce a new RE-like language or is it an API >>> wrapper >>>> for REs? It sounds like it is both. >>> It looks to me like what it says it is, which is an alternative to >>> REs, which IMO is a nice idea. Less "pattern matching language" and >>> more objects expressing matching intent. End result is less >>> developer thought required to accomplish a common task. Seems to >>> fit nicely in Commons to me. >>> >>> Phil >>>> A project like this I could see in Commons if the project was split into >>> an >>>> API module and modules for different pattern matching languages, where >>> the >>>> standard Java RE would be the reference example. Naomi (I love the name >>>> BTW, someones wife or daughter?) would be another implementation module. >>>> With both under its belt, the project would be on fairly solid footing >>>> (granted I do not know Naomi). You could even imaging implementations >>> that >>>> would accept a JXPath or a SQL WHERE clause. >>>> >>>> If the project is only meant to introduce a new RE-like language, then a >>>> TLP would be probably more appropriate. >>>> >>>> 2c, >>>> Gary >>>> >>>> On Thu, Oct 1, 2015 at 11:58 PM, Henri Yandell <flame...@gmail.com> >>> wrote: >>>>> On Tue, Sep 29, 2015 at 5:42 PM, Phil Steitz <phil.ste...@gmail.com> >>>>> wrote: >>>>> >>>>>> On 9/29/15 3:55 PM, Gary Gregory wrote: >>>>>>> Norman, >>>>>>> >>>>>>> Hello and welcome to Apache Commons. >>>>>>> >>>>>>> It's not clear to me why Naomi is better than regular expressions. >>>>>> Pointing >>>>>>> to Javadocs is not the best way to get traction. >>>>>>> >>>>>>> Your project would be better served by having some documentation on >>>>> your >>>>>>> front page with an example driven tutorial. >>>>>>> >>>>>>> Is Naomi faster than REs? >>>>>>> >>>>>>> What can I do in Naomi that REs can't do? And vice-versa. >>>>>>> >>>>>>> Examples of this on your front page would help you at least get folks >>>>> to >>>>>>> consider learning a brand new way of doing things... >>>>>> +1 >>>>>> The code in SimpleExamples starts to get to this. Looks interesting >>>>>> and powerful. Either here or on the github readme you should take a >>>>>> stab at explaining a little more how hard problems using regex get >>>>>> easier with naomi, illustrated with some simple examples. Then >>>>>> maybe with help from community members here, you can develop some >>>>>> overview / getting started docs that help people get into the code. >>>>>> >>>>> +1. >>>>> >>>>> Reading SimpleExamples, my summary would be a boilerplate description of >>>>> "It replaces the arcane regular expression language with an API". It >>>>> reminds me of command line argument parsers. Perl had/has a great >>> regular >>>>> expression like command line argument parser, but it was cryptic and you >>>>> either loved it or hated it. Then along came Commons CLI, args4j and all >>>>> the others, providing a more OO/procedural API instead of its own mini >>>>> language. Not as 'powerful' (in that you had to type more), but simpler >>> (in >>>>> that you didn't have to learn a new lingo and didn't have to juggle >>>>> multiple languages inside one context (a source file)). >>>>> >>>>> I definitely need that user manual. It's hard, with a brain trained on >>>>> regular expressions, to read 'Pattern greek3=new >>> CharSequencePattern("?")' >>>>> and realize (I think) that it means a literal ? character. It's also the >>>>> primary way it'll be successful. You need that educational path that >>>>> explains what a ExplicitCharClass is for, rather than randomly clicking >>> on >>>>> javadoc :) >>>>> >>>>> There'll also be much debate to be had I suspect. Is "a-e" too complex, >>>>> compared to "abcde" or "a","e". Which parts of regex are worth >>> supporting, >>>>> vs not. Can I mix bits of regexp with bits of Naomi? new >>>>> ExplicitCharClass("a-eg-p"). >>>>> >>>>> Random.... I'd like the idea of varargs for automatic and'ing. ie: >>>>> >>>>> new ExplicitCharClass("a-p", "!f") [and is a not char class too >>>>> complex?]. >>>>> >>>>> Continuing on my summary, as I peruse the code a little more, I'd go >>> with: >>>>> "Build a regular expression via an API, not an arcane language of its >>> own". >>>>> I'd love to see that grow to: >>>>> >>>>> "Express regular expressions as objects, or mix and match objects with >>> that >>>>> arcane mini language we all love or loathe". >>>>> >>>>> Hen >>>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
