I've been checking, http://download.oracle.com/javase/1.5.0/docs/api/java/util/regex/Pattern.html and the non-capturing groups are documented in there.
What is Hudson using for compiling? -W On 24 December 2010 16:22, Wolfgang Laun <wolfgang.l...@gmail.com> wrote: > On 24 December 2010 15:19, Geoffrey De Smet <ge0ffrey.s...@gmail.com>wrote: > >> Hi Laun, >> >> Can you take a look at this regression? >> https://issues.jboss.org/browse/JBRULES-2849 >> >> > I shall, but... > > > >> I believe the usage of "?" in the regexes is wrong (which is causing the >> issue). >> For example: regex "(?<=\\W|^)-\\s*\\s+(.*?)\\s+is\\s+(.*?)$" >> >> The "?" means the character before me might or might not be there. >> so "ab?c" matches on "abc" and "ac" >> The "(" means start of a group. >> So "(?" should fail-fast >> > > "(?" is the start of a non-capturing group. > > (but it doesn't, just behave differently in jdk5 and jdk6). >> > > > >> Also ".*?" should fail-fast: either you want ".*" (none or more) or ".+" >> (one ore more). >> > > Not so: This is a non-greedy quantifier, and this has been in the code of > 5.1.1. > > -W > > >> >> >> > Op 24-12-10 11:23, Wolfgang Laun schreef: >> >> This is a summary of the currently implemented new features for the DSL >> expansion. I'll have to add tests and documentation, but before doing so, >> I'd like to learn whether there are any objections (resulting in the >> removal) or suggestions for improvement. Myself, I'm not sure about one or >> two items which I've marked with "(?)". Also, there's a couple of items >> which might gain from easy-to-implement additions, see "Votes, please". An >> example showing most of the new options is given below. >> >> 1. The right hand side of entry definitions can be empty. (Useful for >> deleting "filler" phrases.) >> 2. Long entry lines can be split without the need of escaping EOL: >> - Any line beginning with # or // starts a DSL comment and is not >> passed to the DSL parser. >> - Any line beginning with '[' starts a new entry. >> - All other lines are appended to the preceding line, with a space >> replacing EOL. >> - Empty lines are inserted to maintain original line numbers, and >> line and column numbers in error messages from the parser are >> recalculated >> to reflect the user view of the DSL text. >> 3. The special comment introduction "#/" is used to mark a line >> containing debug options. Currently recognized keywords are: >> - result - dumps the resulting DRL >> - steps - shows all expansion operations in conditions and >> consequences >> - keyword, when, then - display the corresponding entry definitions >> - usage - shows how often an entry was actually used in an >> expansion >> 4. Variable substitution uses the definition of that variable seen >> last in the current when or then part expansion. not just from the current >> line. (But this probably should keep variables from the when part for the >> following then part. Votes, please.) >> 5. The value used in a variable substitution can be modified on the >> fly by adding one of the modifiers after and '!' in the variable >> reference. >> Currently recognized modifiers are: >> - uc, lc - convert all letters to upper case or lower case, >> respectively >> - ucfirst - convert the first letter to upper case, and all other >> letters to lower case >> - num - extract all digits and a '-' preceding the first digit and >> insert the numeric value; a '.' or ',' two digits from the right is >> retained >> as a decimal point, which is useful for monetary quantitites. (?) >> 6. Another modification of the value used for substituting the >> reference is by providing a "multiple choice" after an '!', consisting of >> strings separated alternatively by '?' and '/': If the string extracted >> from >> the DSLR line matches the string before a '?', the string following it is >> used for substitution; otherwise test the next choice. (?) >> 7. A DSL value starting with a hyphen ('-') can also be used in a >> consequence to add another setter expression into a preceding >> "modify(x){}". >> (Should probably be extended to be able to handle the insertion of another >> parameter to any preceding method call and, as a special, but useful, case >> the concatenation to a preceding x.println() or x.print() call. Votes, >> please.) >> >> DSL: >> [when][][Tt]here is an?= >> [when][]{entity} called {x}= >> ${entity!lc}: {entity!ucfirst}( $name: >> name=="{x!M?Mark/E?Edson/G?Geoffrey/unknown}") >> [when][]and no other with the same {attr}=not {entity!ucfirst}( {attr} == >> ${attr} ) >> [then][]change person=modify($person)\{\} >> [then][]- set {attr} to {value} = set{attr!ucfirst}( {value!num} ) >> >> DSLR: >> rule "Rule 1" >> when >> There is a PERSON called M >> and no other with the same name >> then >> change person >> - set salary to US$9,999.99 >> - set rank to "colonel" >> end >> >> DRL: >> 8 rule "Rule 1" >> 9 when >> 10 $person: Person( $name: name=="Mark") >> 11 not Person( name == $name ) >> 12 then >> 13 modify($person){ setSalary( 9999.99 ), setRank( "colonel" ) } >> 14 end >> >> Cheers >> Wolfgang >> >> >> >> _______________________________________________ >> rules-dev mailing >> listrules-...@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev >> >> >> -- >> With kind regards, >> Geoffrey De Smet >> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> >
_______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
