On Tue, Jan 13, 2015 at 10:42 AM, Ferry Huberts <[email protected]> wrote:
>
>
> On 13/01/15 16:27, Raymond Auge 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();
>>
>
> String value();
> String ns() default "osgi.extender";
> String version default "${@version}";
>
>
> or something like that, check the bnd annotations source code
>
I searched the entire bnd project repo and found no examples of
parameterized ProvideCapability.
Even the parser source code does not show any evidence that
parameterization is supported in any way other than to support just one
single large glob from
String value();
- Ray
>
> }
>>
>> 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]
>> <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
>>
>> 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";;
>>>>> 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";;
>>>>>> 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] <mailto:[email protected]
>>>>>> >
>>>>>> 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
>>>>
>>>>
>>>>
>>>> --
>>>> *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
>>>>
>>>
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> [email protected] <mailto:[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] <mailto:[email protected]>
>>> 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
>>
>>
>>
>> --
>> *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
>>
>>
> --
> Ferry Huberts
>
> _______________________________________________
> 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
