On Fri, Dec 19, 2014 at 1:59 PM, Neil Bartlett <[email protected]> wrote: > > Incidentally, if you use the latest bnd(tools) development builds, you can > get some of the nasty Require-Capability syntax generated from Java > annotations. For example, you can define your own annotation and add it to > a class in your bundle: > > @JspTagLib(uri = “foo”) > public class MyTagLib extends … > > Where the annotation is itself annotated as follows: > > @Retention(RetentionPolicy.CLASS) > @RequireCapability( > ns = "osgi.extender", > filter = "(&(osgi.extender=jsp.taglib)(version>=1.0))”, > effective = "active") > public @interface JspTagLib { > String uri(); > } > > > When bnd sees the annotated class in your bundle, it adds the following to > the generated manifest: > > Require-Capability: > osgi.extender;uri=foo;filter:="(&(osgi.extender=jsp.taglib)(version>=1.0))";effective:=active >
Yes this is brilliant stuff that Peter has already submitted as a RFC for R7. https://github.com/osgi/design/blob/master/rfps/rfp-0167-Manifest-Annotations.pdf This brings an exciting ease of use to the req&cap model! - Ray > > Regards > Neil > > > On 19 Dec 2014, at 21:41, Raymond Auge <[email protected]> wrote: > > > > On Fri, Dec 19, 2014 at 1:37 PM, Tim Ward <[email protected]> wrote: >> >> Hi Ray, >> >> Sent from my iPhone >> >> On 19 Dec 2014, at 21:23, Raymond Auge <[email protected]> wrote: >> >> Thanks Tim, I can start with this. >> >> I just want to make it clear that there are 3 actors involved for this >> scenario (perhaps that doesn't matter, let's see): >> >> 1) a JSP client bundle (has jsps) >> Required-Capability: ...jsp.extender... >> Required-Capability: ...jsp.taglib;filter:="(uri=foo)" >> >> 2) a taglib bundle (provides taglib) >> Required-Capability: ...jsp.extender... >> Provide-Capability: ... jsp.taglib;uri="foo"... >> >> 3) jsp extender (provides the JSP servlet to client bundles, ensures the >> client's required taglibs are available to the servlet) >> Provide-Capability: ...jsp.extender... >> >> >> Between the three of these that would do the trick, although unless the >> extender bundle directly interacts with the client bundle (which it may do >> for this case) >> > > it does. > > >> then I would only put the extender requirement in the extendee (providing >> the tag lib) not the client. >> > > Got it! > > Thanks you Tim. Happy Holidays! > > - Ray > > >> >> On Fri, Dec 19, 2014 at 1:11 PM, Tim Ward <[email protected]> wrote: >>> >>> Having just noticed a couple of omissions... >>> >>> To actually match the filter in my previous email the extender would >>> need to specify: >>> >>> Provide-Capability: osgi.extender;osgi.extender=jsp.taglib;version=1.0.0 >>> >>> Also, unless the extendee should be prevented from resolving in the >>> absence of the extender then it should specify effective:=active (as >>> opposed to the default of resolve) >>> >>> And now I'm done - speak to you all next year! >>> >>> Tim >>> >>> >>> Sent from my iPhone >>> >>> On 19 Dec 2014, at 20:55, Tim Ward <[email protected]> wrote: >>> >>> Hi Ray, >>> >>> There is already an osgi.extender namespace declared for this sort of >>> dependency. The extender provides a capability in the osgi.extender >>> namespace, which is required by the extendee. There's a blueprint example >>> in the spec, but this would work for your JSPs. Time for a JSP extender in >>> Enrerprise R7? >>> >>> Apologies for phone-based syntax issues! >>> >>> Extender: >>> >>> Provide-Capability: osgi.extender;osgi.extender=jsp.taglib >>> >>> Extendee: >>> >>> Require-Capability: >>> filter:=(&(osgi.extender=jsp.taglib)(version>=1.0.0)(!(version>=2.0.0))); >>> jsp.taglib.uri="http://my.uri.domain/cooltags_1_0";; >>> jsp.taglib.file="/META-INF/cooltags.tld";uses:="..... >>> >>> Regards, >>> >>> Tim >>> >>> Sent from my iPhone >>> >>> On 19 Dec 2014, at 19:38, Raymond Auge <[email protected]> wrote: >>> >>> Hey All, >>> >>> I'm wondering about modelling an extender pattern using requirements & >>> capabilities header. >>> >>> Hopefully I can explain this in a way that can be understood: >>> >>> In order to implement the extender pattern we often define a new >>> "custom" header which declares the "opt-in" on the extender. >>> >>> However, I'm wondering if instead of using a new "Custom header" if it >>> might not be better to define this "opt-in" using a Provide-Capability. >>> >>> For instance, suppose I wanted to support dynamic provision of JSP >>> taglibs. >>> >>> I could model this using pure java jars with taglibs by adding a header >>> to the jar something like: >>> >>> Provide-Capability: >>> jsp.taglib; >>> jsp.taglib.uri="http://my.uri.domain/cooltags_1_0";; >>> jsp.taglib.file="/META-INF/cooltags.tld";uses:=".....", >>> jsp.taglib; >>> jsp.taglib.uri="http://my.uri.domain/othertags_2_0";; >>> jsp.taglib.file="/META-INF/othertags.tld";uses:=".....", >>> Require-Capability: jsp.extender; filter:="(version=1.0)" >>> >>> This way I don't have to invent a new syntax or header and this can >>> easily be resolved against in both directions. >>> >>> The extender bundle would look for bundles providing jsp.taglib >>> capabilities and make the TLDs available to the JSP servlet it provides to >>> the clients using JSP. >>> >>> A client bundle using both JSP and using the taglib would ask for them >>> by making a Require-Capability against both >>> >>> Require-Capability: jsp.extender; filter:="(version=1.0)" >>> Require-Capability: jsp.taglib; filter:="(jsp.taglib.uri= >>> http://my.uri.domain/cooltags_1_0)" >>> >>> Thoughts? >>> -- >>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>> (@rotty3000) >>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/> >>> (@Liferay) >>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> >>> (@OSGiAlliance) >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >> >> >> -- >> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >> (@rotty3000) >> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/> >> (@Liferay) >> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> >> (@OSGiAlliance) >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> > (@OSGiAlliance) > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
