| Re: b3 - resolver model [message #571192] |
Fri, 18 September 2009 10:54 |
 Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Copied from an email:
>> On Sep 17, 2009, at 10:12 PM, Thomas Hallgren wrote:
>>
>> On 09/17/2009 01:57 AM, Henrik Lindberg wrote:
>> - In Buckminster, there are flags for mutable, source on readers, and
>> regexp pattern matching on component names to control the routing. In
>> b3, this is instead moved to a regular OSGi type filter. The OSGi
>> filter does not have the pattern matching capabilities of a regexp, but
>> wildcard at the end, or middle seems to be what everyone is using, so
>> this should be fine.
> I've been thinking some more about this. Perhaps the OSGi filter is too
> limited in it's pattern matching capabilities after all. Or, if not
> limited, then at least somewhat obscure. I think people are used to two
> types of pattern matching. The regular shell type matching (similar to
> what Ant uses) and the regexp.
Agree.
>> Experience shows that even very experienced developers tend to make
>> mistakes with regexp. Forgetting to escape the dot for instance, is very
>> common. The most pragmatic approach to pattern matching is probably to
>> do use the same approach as Ant. Developers, especially in the build
>> domain, are very familiar with that.
> I can see us do this in two ways.
> 1. We change the model so that the pattern matching is separate from
> other types of filters.
> 2. Since we have our own OSGi implementation, we can add pattern
> matching operator.
>
> I would opt for #1 since OSGi is a standard. It doesn't feel kosher to
> add our own operators to it.
Agree, here as well. I will reintroduce my earlier design that allows a
composition of different types of filters. (For newcomers who do not
know what I am talking about - there will be models posted soon).
>> - I modeled that the IResolver takes more that one Filter. I don't know
>> if that is a good idea, but it would allow easy composition of shared
>> filters for common namespaces; i.e. just add a filter for (or
>> (b3.namspace=osgi.bundle)(b3.namespace=eclipse.feature)) instead of
>> having to first compose a string with all constraints. Idea being to
>> reduce number of instances. For convenience sake, this can just as
>> easily be done in a filter factory (a useful implementation is in
>> Buckminster).
>>
> My preference would be one single filter. Ease of composition is
> something that needs to be addressed by tooling one way or another.
>
Yes, agree - especially since the earlier design allowed composition of
filters - no need to have an additional way to compose them.
- henrik
|
|
|
Powered by
FUDForum. Page generated in 0.02516 seconds
] 
Search
Help
Register
Login
Home
