Super??? You have no idea how cool this is!! :-)
I actually used it to implement web resources in enRoute. The annotation in
Java now automatically includes the indicated resources in the index.html
@AngularWebresource( resource={“angular.js”, “angular-resource.js”})
Now in the HTML
<script
src=“osgi.enroute.webresources/com.example.my.bundle/1.2.3.201501131010/*.js”>
This will create one compressed and cached file for all web resources + the
contents of the requiring bundle’s resources that end in .js in the /web
directory. (And in bnd you can of course do <script
src=“osgi.enroute.webresources/${bsn}/${Bundle-Version}/*.js”> to parameterize
the bundle’s coordinates.)
If you want to check it out, see https://github.com/osgi/osgi.enroute.examples/
<https://github.com/osgi/osgi.enroute.examples/> All the examples are updated
to this model.
Kind regards,
Peter Kriens
> On 13 jan. 2015, at 20:27, Raymond Auge <[email protected]> wrote:
>
>
> On Tue, Jan 13, 2015 at 2:20 PM, Peter Kriens <[email protected]
> <mailto:[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]
>> <mailto:[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] <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]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
