On Tue, Jan 13, 2015 at 2:20 PM, Peter Kriens <[email protected]> wrote:
> Yup, the first incarnation did not copy the fields of the annotated > annotation as attributes. This feature is only on 3.0 > Got it! .. It's still super cool! Thx > > Kind regards, > > Peter Kriens > > > > On 13 jan. 2015, at 16:27, Raymond Auge <[email protected]> wrote: > > On the topic of @ProvideCapability, I was not able to create > a parameterized annotation such as: > > @Retention(RetentionPolicy.CLASS) > @ProvideCapability( > name="jsp.taglib", ns = "osgi.extender", version = "${@version}" > ) > public @interface JspTagLib { > String value(); > } > > Such that I could then apply it as: > > @JspTagLib("http://alloy.liferay.com/tld/aui";) > class Foo {} > > Rather I had to use this > > @ProvideCapability( > ns = "osgi.extender", version = "${@version}", > value = "uri=http://alloy.liferay.com/tld/aui"; > ) > class Foo {} > > Is this because I'm using at bnd 2.3? > > Is it possible to make a parameterized extensions of @ProviderCapability? > > - Ray > > On Fri, Dec 19, 2014 at 5:06 PM, Raymond Auge <[email protected]> > wrote: > >> >> >> 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) >> > > > > -- > *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
