Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » B3 » Re: b3 - resolver model
Re: b3 - resolver model [message #571192] Fri, 18 September 2009 10:54
Henrik Lindberg is currently offline Henrik LindbergFriend
Messages: 2501
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
Previous Topic:Ideas from Grails dependency resolution
Next Topic:Packaging
Goto Forum:
  


Current Time: Fri Dec 19 21:14:45 GMT 2014

Powered by FUDForum. Page generated in 0.02005 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software