Bugzilla – Full Text Bug Listing
| Summary: | [metadata] LDAPFilter should not implement OSGi Filter interface | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | DJ Houghton <dj.houghton> | ||||
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | minor | ||||||
| Priority: | P3 | CC: | daniel_megert, hargrave, john.arthorne, pascal, thomas, tjwatson | ||||
| Version: | 3.7 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
I'll have a look. BJ, Filter is implementable by clients. Is adding matches considered a breaking API change from OSGi point of view? Created attachment 177835 [details]
patch
Here is a simple fix that calls IFilterExpression.matchCase(Map<String, ? extends Object>)
All interfaces are implementable by anyone :-) OSGi has added methods to framework interfaces in the past. For example, matchCase was added to Filter in 1.3. Methods are being added to Bundle, etc. for 1.6. Filters are meant to be implemented by the framework (BundleContext.createFilter) and FrameworkUtil (FrameworkUtil.createFilter) and not by bundles. The only interfaces in the framework package meant to be implemented by bundles are the activator and listener types. I am not sure why p2 is implementing a framework type (Filter). Surely it should define its own interface for this. Otherwise it seems like bad cohesion. The quick fix is to implement the new method. The better fix is for p2 to define its own interface instead of using the framework's Filter. I have released Tom's patch to HEAD because the integration build is currently blocked by this. I will leave this open to continue discussing a long term fix (such as not implementing Filter). (In reply to comment #5) > I will leave this open to continue discussing a long term fix > (such as not implementing Filter). Maybe we need a new, more descriptive bug summary then? The reason for using the OSGi interface and using the LDAPFilter was to retain some interchangeability with OSGi. The filter LDAPFilter interface as such is probably not needed at all since the parser converts the LDAP filter string into a p2QL expresssion anyway. Perhaps we should consider removing this altogether. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This bug was marked as stalebug a while ago. Marking as worksforme. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag. |
There are compile errors in HEAD in the metadata bundle. The LDAPFilter class is missing a method because of an API change in OSGi. This is currently blocking the integration build. /src/org/eclipse/equinox/internal/p2/metadata/expression/LDAPFilter.java : 1 error : 1. ERROR in /src/org/eclipse/equinox/internal/p2/metadata/expression/LDAPFilter.java (at line 9) public class LDAPFilter extends Unary implements IFilterExpression { The type LDAPFilter must implement the inherited abstract method Filter.matches(Map<String,?>)