Hi, I'm not sure if options 2 + 4 work together without changing the API yet one more time when / if we decide to also support regex (albeit just a minor increase). I have nothing against supporting them from the beginning - unfortunately we don't have a clear separation between API and implementation here and the API has to anyways state what it supports.
This means that a ResourceChangeListener will support the following ways for defining a matcher: 1. explicit paths, absolute or relative to search paths 2. '.' , for the cases when the listener is interested in all changes under the search paths 3. limited glob pattern matching ('*', '**'), by prefixing the pattern with 'glob:' 4. regex matching, by prefixing the pattern with 'regex:' Did I miss something? Thanks, Radu On Wed, 20 Jul 2016 at 07:09 Carsten Ziegeler <cziege...@apache.org> wrote: > > what about option 2 + 4 together (but only implementiong 'glob' > currently)? > > > > then it would be: > > - easy to detect if the user wishs to use a pattern instead of a fixed > path by looking for a prefix (currently this is done by magically looking > for special characters) > > - possible to add regex or other pattern support later without breaking > compatibility > > - gives us a quick start with only supporting glob currently > > > Sounds good to me > > Carsten > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org > >