This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Use Require/Provided-Capabilities for NetBeansInOSGi | ||
|---|---|---|---|
| Product: | platform | Reporter: | Jesse Glick <jglick> |
| Component: | Netigso | Assignee: | Jaroslav Tulach <jtulach> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | jtulach |
| Priority: | P3 | ||
| Version: | 7.2 | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 210325 | ||
|
Description
Jesse Glick
2012-04-23 23:09:09 UTC
My original assumption was that NB tokens would map directly to capability names with no qualifications: OpenIDE-Module-Provides: some.Interface OpenIDE-Module-Requires: another.Interface => Provide-Capability: some.Interface Require-Capability: another.Interface Yarda however suggested another idiom: "For our purposes we could probably define org.netbeans.token capability. With attribute token and use it like: OpenIDE-Module-Provides: xyz Provide-Capability: org.netbeans.token;token:String=xyz for providing. And for requiring, needing or recommending: Require-Capability: org.netbeans.token;resolve:=mandatory/optional; filter:=(token=xyz);effective:=startup" Not sure if the more complex idiom offers some advantages. No plans to work on this any time soon. |