Yup, the first incarnation did not copy the fields of the annotated annotation
as attributes. This feature is only on 3.0
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
> <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
> <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]
> <mailto:[email protected]>> wrote:
>
>
> On Fri, Dec 19, 2014 at 1:59 PM, Neil Bartlett <[email protected]
> <mailto:[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
>
> <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]
>> <mailto:[email protected]>> wrote:
>>
>>
>>
>> On Fri, Dec 19, 2014 at 1:37 PM, Tim Ward <[email protected]
>> <mailto:[email protected]>> wrote:
>> Hi Ray,
>>
>> Sent from my iPhone
>>
>> On 19 Dec 2014, at 21:23, Raymond Auge <[email protected]
>> <mailto:[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]
>>> <mailto:[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]
>>> <mailto:[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
>>>> <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]
>>>> <mailto:[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
>>>>> <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
>>>>> <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
>>>>> <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] <mailto:[email protected]>
>>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> [email protected] <mailto:[email protected]>
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>> <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] <mailto:[email protected]>
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>> _______________________________________________
>> OSGi Developer Mail List
>> [email protected] <mailto:[email protected]>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> <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] <mailto:[email protected]>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected] <mailto:[email protected]>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> <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
