Re: [osgi-dev] @ConsumerType vs @ProviderType

[Milen Dyankov via osgi-dev]

Welcome to the club ;) I struggled with that myself for a long time.

I think I finally got to understand it couple of years ago. Here is how I
explained it during one of my talks:
https://www.youtube.com/watch?v=hGNrZmr0zz8=youtu.be=1569
I hope this helps better than me trying to write it all down here.

Best,
Milen

On Wed, Oct 16, 2019 at 9:15 PM Leschke, Scott via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> I’m trying to wrap my head around these two annotations and I’m struggling
> a bit. Is the perspective of the provider and consumer roles from a bundle
> perspective or an application perspective?
>
> I’ve read the Semantic Versioning whitepaper a number of times and it
> doesn’t really clear things up for me definitely.
>
>
>
> If an application has an API bundle that only exposes Interfaces and
> Abstract classes, and those interfaces are implemented by other bundles in
> the app, are those bundles providers or consumers? My inclination is that
> they’re providers but then when does a bundle become a consumer?  Given
> that API bundles are compile only (this is the rule right?), would a good
> rule be that if you implement the interface and export the package it’s in,
> that type would be @ProviderType, if you don’t implement it it’s
> @ConsumeType?
>
>
>
> It would seem to me that @ProviderType would be the default using this
> logic, as opposed to @ConsumerType, which leads me to believe that I’m
> thinking about this wrong.
>
>
>
> Any help appreciated as always.
>
>
>
> Regards,
>
>
>
> Scott Leschke
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
http://about.me/milen
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] [SCR] How to detect a missing configuration for a DS component

[Milen Dyankov via osgi-dev]

>From the top of my head configuration is by default optional but there was
way to say that configuration is required. Is such cases if configuration
is not provided you should get UNSATISFIED_CONFIGURATION

On Tue, Apr 17, 2018 at 4:54 PM, Christian Schneider via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> I am currently working on root cause analysis for DS components. To do
> this I rely on the ServiceComponentRuntime service.
>
> I got the description of this component in
> ComponentDescriptionDTO desc;
>
> and I can get configurations for it using:
> Collection configs = scr.
> getComponentConfigurationDTOs(desc)
>
> I wonder how to correctly detect the state of a missing configuration.
>
> There is the configuration state UNSATISFIED_CONFIGURATION but how can it
> occur?
> If my component has no config then getComponentConfigurationDTOs returns
> an empty list and if a configuration is present it can not be unsatisfied,
> can it?
>
> Best
> Christian
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>



-- 
http://about.me/milen
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] How to hint the resolver to pick a certain service provider

[Milen Dyankov]

Thanks Neil,

just want to clarify one thing. You wrote " That is, you can have a
requirement with effective:=*resolve* that is not satisfied, and OSGi will
still resolve and activate the bundle just fine."

Did you mean to write something other than "resolve" here? Because from the
previous sentance it seams the "resolve" is what actually the OSGi runtime
will NOT ignore!

Best,
Milen



On Fri, Aug 18, 2017 at 4:20 AM, Neil Bartlett <njbartl...@gmail.com> wrote:

> Hi Milen,
>
> It’s pretty simple… if ‘effective' is unspecified OR has the value
> “resolve”, then the OSGi Framework uses that requirement in its own
> resolution of the bundle. If you specify ANY value other than “resolve”,
> then OSGi Framework completely ignores the requirement. That is, you can
> have a requirement with effective:=resolve that is not satisfied, and OSGi
> will still resolve and activate the bundle just fine.
>
> When you resolve in Bndtools, we always try to find matches for all
> effective:=resolve requirements (otherwise the end result would be broken
> in OSGi!). Optionally you can choose to find matches for additional
> effective values such as “active”. That’s what “-resolve-effective: active”
> means in a bndrun file.
>
> The convention of using effective:=active in a bundle exists because
> sometimes you want to indicate to tools (like Bndtools) that you would LIKE
> to have a thing… but if the thing doesn’t exist, then you don’t want that
> to prevent resolution of the bundle in OSGi.
>
> I hope that all makes sense.
>
> Unfortunately I don’t think this is really relevant to Christian’s
> problem, though.
>
> Neil
>
>
> On 17 Aug 2017, at 16:50, Milen Dyankov <milendyan...@gmail.com> wrote:
>
> Hi Christian,
>
> have you tried adding   effective="..." to the annotations and then   
> -resolve-effective:
> ...  to bndrun file?  Sorry for the dots but I never understood how to
> determine what the values should be to make given resolver ignore or
> enforce the requirement. I always play around with them until they give me
> the desired result. I something think there are no more than 10 people on
> this planet who actually understand this :)
>
> Best,
> Milen
>
> On Thu, Aug 17, 2017 at 1:34 PM, Christian Schneider <
> ch...@die-schneider.net> wrote:
>
>> Hi Peter,
>>
>> thanks for your help.
>>
>> I do not cast the type. The user only uses the RComponent interface. The
>> idea of the component model is that the user of component is not exposed to
>> the implementation details of a component. This is of course the root of
>> the problem of why I need more than java types. It is the same for camel.
>>
>> I just tried to create a custom annotation but the result in the manifest
>> looked a bit strange so I now first try to use plain @RequireCapability and
>> @ProvideCapability. When I got this working I will try again with a custom
>> annotation to make it easier to use.
>>
>> This is what I got now..
>> On my mqtt component I define:
>> @ProvideCapability( ns="rcomp", name="mqtt")
>>
>> It results in this Provide-Capability header:
>> rcomp;rcomp=mqtt
>>
>> In my rcomp-example bundle I use:
>> @RequireCapability(ns="rcomp", filter="(rcomp=mqtt)")
>>
>> It results in this Require-Capability header:
>> rcomp;filter:="(rcomp=mqtt)"
>>
>> So I think this looks good.
>>
>> Strangely when I create my bndrun with a requirement on rcomp-example and
>> do a resolve then it does not add my rcomp-mqtt bundle.
>>
>> When I then run the framework it fails with this error:
>> could not resolve the bundles: [rcomp-examples-1.0.0.201708171022
>> org.osgi.framework.BundleException: Unable to resolve rcomp-examples
>> [12](R 12.0): missing requirement [rcomp-examples [12](R 12.0)] rcomp;
>> (rcomp=mqtt) Unresolved requirements: [[rcomp-examples [12](R 12.0)] rcomp;
>> (rcomp=mqtt)]
>> ]
>>
>> Shouldn't the resolver automatically add the rcomp-mqtt bundle and even
>> abort the resolve in case the bundle is not available in the repository?
>>
>> Best
>> Christian
>>
>>
>>
>>
>> On 17.08.2017 10:31, Peter Kriens wrote:
>>
>>> The purpose of the @Reference.target is to be overridden by
>>> configuration, adding the filter to the requirement would basically destroy
>>> that use case.
>>>
>>> For what you want there is a very good solution: Plain Old Java Types …
>>> I suspect that in your code you already do some casti

Re: [osgi-dev] How to hint the resolver to pick a certain service provider

[Milen Dyankov]

Hi Christian,

have you tried adding   effective="..." to the annotations and then
-resolve-effective:
...  to bndrun file?  Sorry for the dots but I never understood how to
determine what the values should be to make given resolver ignore or
enforce the requirement. I always play around with them until they give me
the desired result. I something think there are no more than 10 people on
this planet who actually understand this :)

Best,
Milen

On Thu, Aug 17, 2017 at 1:34 PM, Christian Schneider <
ch...@die-schneider.net> wrote:

> Hi Peter,
>
> thanks for your help.
>
> I do not cast the type. The user only uses the RComponent interface. The
> idea of the component model is that the user of component is not exposed to
> the implementation details of a component. This is of course the root of
> the problem of why I need more than java types. It is the same for camel.
>
> I just tried to create a custom annotation but the result in the manifest
> looked a bit strange so I now first try to use plain @RequireCapability and
> @ProvideCapability. When I got this working I will try again with a custom
> annotation to make it easier to use.
>
> This is what I got now..
> On my mqtt component I define:
> @ProvideCapability( ns="rcomp", name="mqtt")
>
> It results in this Provide-Capability header:
> rcomp;rcomp=mqtt
>
> In my rcomp-example bundle I use:
> @RequireCapability(ns="rcomp", filter="(rcomp=mqtt)")
>
> It results in this Require-Capability header:
> rcomp;filter:="(rcomp=mqtt)"
>
> So I think this looks good.
>
> Strangely when I create my bndrun with a requirement on rcomp-example and
> do a resolve then it does not add my rcomp-mqtt bundle.
>
> When I then run the framework it fails with this error:
> could not resolve the bundles: [rcomp-examples-1.0.0.201708171022
> org.osgi.framework.BundleException: Unable to resolve rcomp-examples
> [12](R 12.0): missing requirement [rcomp-examples [12](R 12.0)] rcomp;
> (rcomp=mqtt) Unresolved requirements: [[rcomp-examples [12](R 12.0)] rcomp;
> (rcomp=mqtt)]
> ]
>
> Shouldn't the resolver automatically add the rcomp-mqtt bundle and even
> abort the resolve in case the bundle is not available in the repository?
>
> Best
> Christian
>
>
>
>
> On 17.08.2017 10:31, Peter Kriens wrote:
>
>> The purpose of the @Reference.target is to be overridden by
>> configuration, adding the filter to the requirement would basically destroy
>> that use case.
>>
>> For what you want there is a very good solution: Plain Old Java Types … I
>> suspect that in your code you already do some casting to a more specific
>> type from RComponent? If that is the case then you have a bad code smell,
>> which is also visible in Camel I think. We ‘know’ the type but we’re forced
>> to go to properties to line things up as we want.
>>
>> However, I am guessing so you might need it in a different scenario. If
>> you want to do what you want I think you can use the annotation support in
>> bnd for requirements.
>>
>> @RequireCapability( ns=“osgi.service”,
>> filter=“(&(objectClass=org.apache.karaf.rcomp.api.RComponent)(name=${value}))”
>> )
>> @interface ReqRc { String value(); }
>>
>> @ReqRc(“mqtt” )
>> @Component(property=“name=mqtt”)
>> public class …
>>
>> Hope this helps.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>> On 17 Aug 2017, at 10:07, Christian Schneider 
>>> wrote:
>>>
>>> I am currently working on a little framework that offers components with
>>> a common service interface but different property value per component.
>>>
>>> LIke:
>>>
>>> https://github.com/cschneider/reactive-components/blob/maste
>>> r/rcomp-mqtt/src/main/java/org/apache/karaf/rcomp/mqtt/
>>> MqttComponent.java
>>> @Component(property="name=mqtt")
>>>
>>> A user of the mqtt component will use a filter like this:
>>> @Reference(target="(name=mqtt)")
>>>
>>> Bnd creates a requirement like this:
>>> osgi.service;filter:="(objectClass=org.apache.karaf.rcomp.
>>> api.RComponent)";effective:=active
>>>
>>> The requirement does not include the filter.
>>>
>>> It would be nice if bndtools or karaf later could help me by auto
>>> picking or recommending the mqtt component bundle when the user bundle is
>>> required.
>>>
>>> Can I somehow make bnd create a requirement including a filter? .. or
>>> alternatively is there another easy to use way how a specific provider can
>>> announce itself and a user bundle can specify the requirement for a
>>> specific provider?
>>>
>>> I think this same problem applies to Apache Camel. When a user bundle
>>> uses a certain camel component then the resolver currently does not help
>>> with this and the bundle fails at runtime.
>>>
>>> Christian
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>> ___
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> 

Re: [osgi-dev] Start Ordering in OSGi

[Milen Dyankov]

Hi Peter,

if I understand correctly (I must admit it's not immediately clear to me),
you think of Aggregate State service as something that should be a general
purpose service provided by OSGi implementation or some library. In another
words, it's not something that developers need to implement themselves in
each project. Is that right? If so, I do believe it will be very useful
addition to the OSGi specs. I would also love to see it provided as
independent nonstandard library meanwhile!

That said, I think it would be very useful if the article can give (or
point to) an example of how a service can modify its own service
properties! I don't think this is a well understood concept among OSGi
developers (much like the negative conditions you mentioned). Perhaps many
developers could benefit from it if they were aware of the possibilities!

Best regards,
Mien




On Mon, Apr 24, 2017 at 7:12 PM, Peter Kriens 
wrote:

> I’ve written a blog about start ordering issues in OSGi and a potential
> solution. This likely will interest many since it is a vexing OSGi problem.
>
> Feedback appreciated.
>
> http://aqute.biz/2017/04/24/aggregate-state.html
>
> Kind regards,
>
> Peter Kriens
>
>


-- 
http://about.me/milen
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] requirements capabilities and resolver for general purpose provisioning

[Milen Dyankov]

Hi all,

Is anyone aware of any attempt to use the requirements,
repositories and resolver specs for anything other than provisioning OSGi
runtime? It seams to me the specs are generic enough to be used in other
scenarios.

One example that comes to my mind is provisioning a telecommunication
offer. Say user purchase "plan A" which requires things like "text
messaging", "roaming", ... and then resolver finds services  with such
capabilities which on the other hand have their own requirements.

The above is just an example I made up, it's not something I'm really
interested in. I'm rather looking for any example of usage of those
concepts outside the scope of their original purpose.

Best,
Milen


-- 
http://about.me/milen
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] runtime bundle augmentation

[Milen Dyankov]

I definitely want to try it :)

On Fri, Dec 16, 2016 at 6:25 PM, Raymond Auge <raymond.a...@liferay.com>
wrote:

> Only the Oxygen version of Equinox framework supports this AND if you
> write an extension to add support for augments, which I have, but it's not
> released anywhere officially.
>
> If you want to try it maybe you could help me find a home for it.
>
> - Ray
>
> On Fri, Dec 16, 2016 at 12:22 PM, Milen Dyankov <milendyan...@gmail.com>
> wrote:
>
>> Is there runtime alternative for bnd's `-augment`?
>>
>> Usecase is say vendor of  A provides proper bundle with
>> "Require-Capability: X". There is bundle B which provides X but no one
>> bothered to put "Provide-Capability" in it. Augmenting B in `bndrun` is
>> tempting option to  "properly" assemble a runtime but it's kind of useless
>> in this case as this would not resolve at runtime anyway. I know I can wrap
>> B and provide the capability myself but if someone else is installing B
>> they need to know to use my version of it instead of original one. So I'm
>> just curious if I can somehow tell the runtime resolver "BTW this bundle
>> (if and when available) provides this capability" instead.
>>
>> Best,
>> Milen
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> 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
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>



-- 
http://about.me/milen
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] runtime bundle augmentation

[Milen Dyankov]

Is there runtime alternative for bnd's `-augment`?

Usecase is say vendor of  A provides proper bundle with
"Require-Capability: X". There is bundle B which provides X but no one
bothered to put "Provide-Capability" in it. Augmenting B in `bndrun` is
tempting option to  "properly" assemble a runtime but it's kind of useless
in this case as this would not resolve at runtime anyway. I know I can wrap
B and provide the capability myself but if someone else is installing B
they need to know to use my version of it instead of original one. So I'm
just curious if I can somehow tell the runtime resolver "BTW this bundle
(if and when available) provides this capability" instead.

Best,
Milen
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Component being activated twice?

[Milen Dyankov]

Not sure why you decided to move the discussion back here but fine with me,
at least I'm not the one highjacking the thread :)

I agree with "well defined distros" but that only works for greenfield
projects. There may be hundreds of variations of runtimes out there. Some
vary basic examples:

- felix/equinox with or without (scr, blueprint, fileinstall, gogo, ...)
- karaf with or without (spring, jpa, cxf, ...)
- liferay with or without tons of customizations

And when you enter the world of internal corporate rules and "standards"
this is easily becoming unmanageable on distro level only IMHO. So from my
perspective proposed "-runprovided" is just scoped version of
"-runrequires". We don't use distro for "-runrequires" but name the bundles
we *know* we want in *this project*. Same should be for things we *know*
will be provided for *this project* IMHO.

Regards,
Milen

On Thu, Nov 24, 2016 at 12:16 PM, Daghan ACAY 
wrote:

> Joining this thread these with Tim's other email about *-runprovided*.
>
> It reminds me the Set theory in maths. One can define the very same set by
> saying
>
> 1- -distro: liferay
> 2- distro: karaf minus -runblacklist
> 3- -runprovided(example) plus -runrequires.
>
> I hope i am not missing crucial detail by trying to simplify it. But
> assuming my simplification is valid, i prefer we have major -distro's which
> we can fine tune them with the existing -runblacklist and -runrequires.
>
> This being said, distros should be well defined and we'll documented and
> minimal in number. I guess this is one thing enroute is trying to solve.
> Osgi is great but leaves to much to the developer and configuration. It
> might benefit osgi to go convention over configuration.
>
> To be honest very little talks about using Spring with different app
> serves mixing cxf instead of Spring REST etc. IMHO we are spoiled with
> options and we want more for the sake of asking for it.
>
> Now my question is: can osgi/enroute provide well defined distros in the
> near future. Some examples might be:
>
> 1-karaf
> 2-felix/enroute
> 3- equinox/eclipse
> 4- possibly servicemix
>
> Or should we start creating or own distros?
>
> I hope i did not derail the discussion.
>
> Regards
> Daghan
>
> Sent by MailWise  – See your
> emails as clean, short chats.
>
>
>  Original Message 
> From: Raymond Auge 
> Sent: Thursday, November 24, 2016 03:49 AM
> To: OSGi Developer Mail List 
> Subject: Re: [osgi-dev] Component being activated twice?
>
> Given the current state of the art, what most affects your resolver output
> starts with:
>
> *-runee:* JavaSE-1.8 # this sets the base in terms of which JRE you are
> targeting this is the fundamental parts provided by all JREs of a given
> version
>
> then you have:
>
> *-distro:*  # which is an *optional* pre-created jar with a
> manifest containing all the capabilities provided by your "target
> platform", in your case it's Karaf + whatever addons you've added to your
> karaf instance.
>
> those two things define what should NOT be included in your resolve result.
>
> Then your input is:
>
> *-runrequires:*  # this is your application you want to run. All
> the bundle's you've defined here are the ones you absolutely want to have
> in the runtime.
>
> *-runblacklist:*  # this is the set of bundles which you've
> explicitly asked the resolver to never return in it's result.. but it
> doesn't mean they're not already provided by your system.
>
> For me the lynch pin to making this whole cycle complete would be that:
>
> *-distro:* 
>
> represent the current reality, vs some snapshot in time which may no
> longer be valid.
>
> If it were possible to have that then you could theoretically point:
>
> *-distro:* karak;index="socket:/..."
>
> OR
>
> *-distro:* liferay;index="file:/..."
>
> OR
>
> *-distro:* websphere;index="http:/..."
>
> OR
>
> *-distro:* my_super_custom_runtime;index="git:/..."
>
> and your resolver operation would actually protect you from introducing
> incompatible, or completely duplicated things.
>
> If we took this a step further and had:
>
> *-distro:* repo;name="liferay"
>
> and have the repo config be:
>
> *-plugin.distro.repo:* \
> com.foo.super.LiveIndexOfRuntimeRepository; \
> index="socket:/..."; \
> name="liferay"
>
> BOOM
>
> Not only would I have resolution protection for those things I mentioned
> above, but I could physically browse the runtime to see what's already
> there.
>
> - Ray
>
>
> On Wed, Nov 23, 2016 at 11:27 AM, Tim Ward  wrote:
>
>> OK, so if I feature:uninstall scr from Karaf I can let Resolve do its
>> thing and everything works.
>>
>> Is that an error in
>>
>> http://enroute.osgi.org/appnotes/bndtools-and-karaf.html
>>
>> then?
>>
>>
>> On 23/11/2016 16:23, Christian Schneider wrote:
>>
>> -runfw just sets the OSGi framework. Karaf basically also does this

Re: [osgi-dev] notion of "provided" scope for build time resolver

[Milen Dyankov]

not according to http://bnd.bndtools.org/chapters/825-instructions-ref.html
:)


On Wed, Nov 23, 2016 at 10:42 PM, Raymond Auge <raymond.a...@liferay.com>
wrote:

> -distro: is an existing bnd instruction implemented by Peter.
>
> - Ray
>
> On Wed, Nov 23, 2016 at 4:22 PM, Milen Dyankov <milendyan...@gmail.com>
> wrote:
>
>> I didn't want to highjack the "Component being activated twice?" thread
>> so decided to start a new one.
>>
>> Regarding the "*-distro*" instruction - I don't seam to find any info
>> about it. I assume this was simply an idea Ray proposed and not something
>> that exist and need to be improved? Please correct me if I'm wrong and
>> point me to some documentation.
>>
>> From the previous discussion I get the impression the really missing
>> piece in bnd / repos / resolver is the concept of dependency scope
>> "provided" that we know from Maven. If I understood Ray's intention
>> correctly this is what he generally wants to have with "-distro" except
>> it's on repository level instead of bundle level. I'm just curios if it
>> wouldn't make more sense to have both. That is so in addition to what Ray
>> proposes one could say for example:
>>
>> -*-runprovided: *
>>
>> which would mean use those to resolve build time but do not
>> package/deploy/include them in anything that would go in runtime.
>>
>> Best,
>> Milen
>>
>>
>> --
>> http://about.me/milen
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> 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
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>



-- 
http://about.me/milen
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] notion of "provided" scope for build time resolver

[Milen Dyankov]

I didn't want to highjack the "Component being activated twice?" thread so
decided to start a new one.

Regarding the "*-distro*" instruction - I don't seam to find any info about
it. I assume this was simply an idea Ray proposed and not something that
exist and need to be improved? Please correct me if I'm wrong and point me
to some documentation.

>From the previous discussion I get the impression the really missing piece
in bnd / repos / resolver is the concept of dependency scope "provided"
that we know from Maven. If I understood Ray's intention correctly this is
what he generally wants to have with "-distro" except it's on repository
level instead of bundle level. I'm just curios if it wouldn't make more
sense to have both. That is so in addition to what Ray proposes one could
say for example:

-*-runprovided: *

which would mean use those to resolve build time but do not
package/deploy/include them in anything that would go in runtime.

Best,
Milen


-- 
http://about.me/milen
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Component being activated twice?

[Milen Dyankov]

In this particular case removing scr from Karaf is OK because there is
nothing in it that needs it. That would not be a universal solution though.
Same thing with deploying through agent - works perfect in such experiment
green field cases but that's likely not how one would deploy in big
projects.
Different combinations of runtimes and build tools would likely need to be
resolved in different ways.

I don't have any universal solution for that but at least I finally managed
to understand Ray's point about resolving against specific runtimes which
seemed a weird idea up until now.

Best,
Milen

On Wed, Nov 23, 2016 at 5:35 PM, Christian Schneider <
ch...@die-schneider.net> wrote:

> Good question. I think one issue with not installing the scr feature is
> that you do not have the scr karaf commands.
> Apart from that not installing the scr feature would make it easier for
> bndtools users.
>
> Maybe you can create a pull request on the documentation and discuss with
> the maintainers if the change is good.
>
> Christian
>
>
> On 23.11.2016 17:27, Tim Ward wrote:
>
> OK, so if I feature:uninstall scr from Karaf I can let Resolve do its
> thing and everything works.
>
> Is that an error in
>
> http://enroute.osgi.org/appnotes/bndtools-and-karaf.html
>
> then?
>
> On 23/11/2016 16:23, Christian Schneider wrote:
>
> -runfw just sets the OSGi framework. Karaf basically also does this inside
> when you can choose between felix and equinox but karaf is a lot more than
> that.
> So correctly setting up bndtools for karaf as a runtime will involve a lot
> more than -rnfw.
>
> I think there currently is not complete solution for this but I am also be
> very interested in the combination of karaf and bndtools.
>
> Christian
>
> On 23.11.2016 17:18, Tim Ward wrote:
>
> I was sort-of guessing that that's what -runfw was about, but didn't find
> enough documentation to be able to understand it. Via monkey-see monkey-do
> cut-and-paste I've ended up with
>
> -runfw: org.apache.felix.framework;version='[5.6.1,5.6.1]'
>
> which clearly does NOT tell it "you are running on Karaf, with
> such-and-such list of other bundles installed".
>
> Further, I was sort-of guessing that -runblacklist might be relevant here,
> but was puzzled to find it expressed (in the GUI) in terms of bundles?
> packages? rather than capabilities.
>
> But it's not what I want, because putting the unwanted bundle in as a
> blacklisted item gets me
>
> ==
> Unable to resolve <> version=null:
>missing requirement com.telensa.apps.planet.p2c.provider
>
> ->  Unable to resolve com.telensa.apps.planet.p2c.provider
> version=1.0.0.201611231522:
>missing requirement org.osgi.service.component; version=[1.3.0,2.0.0)]
> ==
>
> when I try to resolve.
>
> Another point which might relate to duplicate scrs: in
> http://enroute.osgi.org/appnotes/bndtools-and-karaf.html it says to do
>
> karaf@root(bundle)> feature:install scr
>
> Did that contribute to my problem? Should I alternatively uninstall that
> feature?
>
> On 23/11/2016 16:06, Timothy Ward wrote:
>
> Isn’t this exactly what enRoute was trying to do with the distros?
>
> Regards,
>
> Tim
>
> On 23 Nov 2016, at 16:05, Raymond Auge  wrote:
>
> @Peter this is exactly a scenario I'd love to be able to eliminate by
> exposing the target runtime as a repo which we can specify as the the BASE
> for the resolver.
>
> - Ray
>
> On Wed, Nov 23, 2016 at 11:04 AM, Tim Ward  wrote:
>
>> So, if I manually delete
>>
>> org.apache.felix.scr
>>
>> from -runbundles then both symptoms go away.
>>
>> All I've got to do now is try to find out how to stop the Resolve button
>> putting it back in every time?
>>
>>
>> On 23/11/2016 15:58, Peter Kriens wrote:
>>
>> That sounds a bit like scr is started twice.
>>
>> Sounds? Are their other possible explanations?
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>> On 23 Nov 2016, at 16:49, Christian Schneider 
>> wrote:
>>
>> On 23.11.2016 16:47, Tim Ward wrote:
>>
>> OK, doesn't look like configuration.
>>
>> - Comment out @RequireConfigureExtender
>> - Resolve
>> - Confirm that osgi.enroute.configurer.simple.provider no longer appears
>> in -runbundles
>> - Confirm that osgi.enroute.configurer.simple.provider no longer appears
>> in Karaf's "list" command
>> - Restart Karaf and run it again
>>
>> and the same happens.
>>
>> By the way, I also get the following from time to time in the log, which
>> I've ignored so far, but it does suggest that my component isn't the only
>> thing being started twice?
>>
>> 2016-11-23 15:43:43,266 | INFO  | pool-61-thread-3 | ScrServiceMBeanImpl
>>  | 55 - org.apache.karaf.scr.management - 4.0.7 | Activating
>> the Apache Karaf SCR Service MBean
>> 2016-11-23 15:43:43,268 | ERROR | pool-61-thread-3 | ScrServiceMBeanImpl
>>  | 55 - 

Re: [osgi-dev] OSGi enRoute Maven Testers wanted ...

[Milen Dyankov]

I ended up having:

→ mvn clean install
[INFO] Scanning for projects...
[INFO]
[INFO]

[INFO] Building osgi.enroute.examples.eval.bndrun 1.0.0-SNAPSHOT
[INFO]

[WARNING] The POM for
biz.aQute.bnd:bnd-export-maven-plugin:jar:3.4.0-SNAPSHOT is missing, no
dependency information available
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 0.109 s
[INFO] Finished at: 2016-10-12T00:26:21+02:00
[INFO] Final Memory: 7M/309M
[INFO]

[ERROR] Plugin biz.aQute.bnd:bnd-export-maven-plugin:3.4.0-SNAPSHOT or one
of its dependencies could not be resolved: Could not find artifact
biz.aQute.bnd:bnd-export-maven-plugin:jar:3.4.0-SNAPSHOT -> [Help 1]
[ERROR]

after creating the bndrun sub-project. This is with maven 3.3.9. I had to
add


  
bnd-snapshots

https://bndtools.ci.cloudbees.com/job/bnd.master/lastSuccessfulBuild/artifact/dist/bundles/

default
  

to my parent POM to make it work.

Regards,
Milen

On Tue, Oct 11, 2016 at 4:23 PM, BJ Hargrave  wrote:

> > Btw. I wonder if we could use a command line option for maven to auto
> update the runbundles. So you could describe to first run the build with
> mvn install. It fails and then run again with the option to replace the
> runbundles. That would be a lot simpler than copy pasting them.
>
> We just added support like this to the gradle plugin. It has resolve.XXX
> tasks which run the resolver for the XXX.bndrun file and then replaces the
> -runbundles statement in that bndrun file.
>
> https://github.com/bndtools/bnd/blob/master/biz.aQute.bnd.
> gradle/src/aQute/bnd/gradle/BndPlugin.groovy#L451-L497
>
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM // office: +1 386 848 1781
> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
> hargr...@us.ibm.com
>
>
>
> - Original message -
> From: Christian Schneider 
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: OSGi Developer Mail List 
> Cc:
> Subject: Re: [osgi-dev] OSGi enRoute Maven Testers wanted ...
> Date: Fri, Oct 7, 2016 2:20 PM
>
> Hi Peter,
>
> do you also provide the full source code of the finished project?
> I read most of the instructions and generally they look good but I think I
> personally would never try to recreate the whole project by hand by
> following the steps.
> I think most people would simply checkout the finished example and try and
> experiment with it while reading the sections of the tutorial.
>
> I also think the instructions for creating and adding the runbundles
> manually are quite tedious. I would rather leave the option to auto resolve
> on for the start and explain in a special section what the risks are and
> how to avoid these by "approving" the resolve manually like you describe
> now.
>
> Btw. I wonder if we could use a command line option for maven to auto
> update the runbundles. So you could describe to first run the build with
> mvn install. It fails and then run again with the option to replace the
> runbundles. That would be a lot simpler than copy pasting them.
>
> Christian
>
> On 06.10.2016 15:51, Peter Kriens wrote:
>
> I’ve created a tutorial for OSGi enRoute with Maven and vi. I am in need
> of some people that are willing to review this tutorial.
>
> The tutorial is at http://enroute.osgi.org/tutorial_eval/050-start.html
>
> You can find the Github source code at: https://github.com/osgi/
> osgi.enroute.site/tree/gh-pages/_tutorial_eval
>
> Please provide tool requests and issues or just mail me personally at
> peter.kri...@aqute.biz .
>
> Any help would be HIGHLY appreciated. Kind regards,
>
> Peter Kriens
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>



-- 
http://about.me/milen
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] The JPA spec bundle does not work with jpa 2.1

[Milen Dyankov]

>
> I agree with Christian that this should be clearly documented in a wiki
> somewhere.


Please someone, DO document this!
I already moved this thread to my "Things about OSGi that you need to read
at least 5 times before they start making sense" folder :) but for anyone
not on this list, it would be really helpful to have this documented!



On Fri, Sep 16, 2016 at 6:13 PM, Elliot Huntington <
elliot.hunting...@gmail.com> wrote:

> I agree with Christian that this should be clearly documented in a wiki
> somewhere. My personal opinion is that a bare-bones enroute JPA example
> would be a good place for this.
>
> Elliot
>
> On Fri, Sep 16, 2016 at 9:26 AM, Thomas Watson 
> wrote:
>
>> Regardless, should the best practice for providing osgi.contract
>> capabilities be to only provide one capability per osgi.contract name?  And
>> use Lists for attributes where you want to express multiple version support?
>>
>> I know for a fact there are Servlet 2.5 applications that will simply
>> break if run on a Servlet 3.0 implementation.  If the best practice is to
>> provide distinct osgi.contract capabilities for each 'version' then these
>> types of user bundles will have issues binding to the correct contract.
>>
>> Tom
>>
>>
>>
>>
>>
>> From:BJ Hargrave/Austin/IBM@IBMUS
>> To:osgi-dev@mail.osgi.org
>> Date:09/16/2016 10:08 AM
>> Subject:Re: [osgi-dev] The JPA spec bundle does not work with
>> jpa 2.1
>> Sent by:osgi-dev-boun...@mail.osgi.org
>> --
>>
>>
>>
>> As Tom mentions, when a bundle provides multiple contracts, the filter of
>> the requirement only has to match one of the contracts. So adding an
>> additional filter expression like (version<=2.1) does not exclude the
>> bundle which also offers the contract at version=3.
>>
>> As an implementation bundle, contracts do not really help you. They were
>> meant for using bundles: consumers of the API, not implementers of the API.
>>
>> The API bundle which provides the contract should probably export the
>> packages with version(s) that the implemention bundle can import against to
>> establish the tighter coupling between the API and the implementation.
>>
>> --
>>
>> BJ Hargrave
>> Senior Technical Staff Member, IBM // office: +1 386 848 1781
>> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
>> hargr...@us.ibm.com
>>
>>
>> - Original message -
>> From: Timothy Ward 
>> Sent by: osgi-dev-boun...@mail.osgi.org
>> To: OSGi Developer Mail List 
>> Cc:
>> Subject: Re: [osgi-dev] The JPA spec bundle does not work with jpa 2.1
>> Date: Thu, Sep 15, 2016 5:16 PM
>>
>> BJ - My understanding is that contract versions don’t work like normal
>> semantic versions (if only they did…) and that version 2.0.1 may be totally
>> incompatible with version 2.0.0. I therefore don’t think it’s safe to use a
>> range like “[2.1,2.2)”. My understanding of their intended use is that
>> consumers select an exact version of the contract using “=“, and that
>> providers declare the versions that they support. What I’m trying to do is
>> to work out what providers and substitutable exporters should do.
>>
>> To use a concrete example that actually exists.
>>
>> If I write a Servlet 3.0 container, then I need to wire to the Servlet
>> 3.0 API. The Servlet 2.5 API will be missing interfaces that I need,
>> causing NoClassDefFoundErrors, and the Servlet 3.1 API will have methods
>> that I don’t implement, causing NoSuchMethodErrors if called at runtime.
>>
>> I do, however, want the providers of the servlet packages to offer the
>> servlet contract to consumers at backward compatible versions so that a
>> Servlet 2.5 Servlet can be used on a Servlet 3.1 implementation. This is my
>> understanding of why the contracts exist.
>>
>> Therefore we have the following three API bundles, with contracts taken
>> from *https://www.osgi.org/portable-java-contract-definitions/*
>> 
>>
>> *A* (Servlet 2.5):
>>
>> Export-Package: javax.servlet, javax.servlet.http
>> Provide-Capability: osgi.contract;
>>  osgi.contract=JavaServlet; version:Version=2.5; uses:="javax.servlet,
>>  javax.servlet.http"
>>
>>
>> *B* (Servlet 3.0):
>>
>> Export-Package: javax.servlet, javax.servlet.http
>> Provide-Capability: osgi.contract; osgi.contract=JavaServlet;
>> version:Version=3;
>>  uses:="javax.servlet, javax.servlet.http", osgi.contract;
>>  osgi.contract=JavaServlet; version:Version=2.5; uses:="javax.servlet,
>>  javax.servlet.http"
>>
>> *C* (Servlet 3.1)
>>
>> Export-Package: javax.servlet, javax.servlet.http
>> Provide-Capability: osgi.contract; osgi.contract=JavaServlet;
>> version:Version=3.1;
>>  uses:=“javax.servlet, javax.servlet.http",
>>  osgi.contract; osgi.contract=JavaServlet; version:Version=3;
>>  uses:="javax.servlet, javax.servlet.http", osgi.contract;
>>  

Re: [osgi-dev] Bundle resolution in BND

[Milen Dyankov]

I'm sorry to respond without actually providing an answer but I couldn't
help it. Least time (not so long ago) I asked myself similar question I
ended up learning what NP-complete process is ;) And I'm still trying to
make sense out of it ...

31 sie 2016 13:31 "Daghan ACAY"  napisał(a):
>
> Hi there,
>
>
> I was working on understanding bundle resolution and workspaces in BND
and enRoute. Here is my simplified set up:
>
>
> workspace 1 two projects
>
> ProjectA.api
>
> ProjectB.provider (this depends on Bundle1 and Bundle2)
>
>
> I resolve Project B using central maven repository. And release Both
ProjectA and ProjectB to "Release"
>
>
> Workspace 2 one project. This workspace has reference to "Release"
directory of the workspace 1 hence can see ProjectA and ProjectB. However,
this workspace does not have the Central repository pointing to Bundle1 and
Bundle2 above. Project in workspace 2 is called
>
>
> ProjectC.provider (this depends on ProjectA.api)
>
>
> Here is my question . When I try to resolve Project C, resolution fails
saying
>
> "Project C  cannot be resolved because ProjectB cannot be resolved
because it needs Bundle1."
>
>
> Why should I have dependencies of my dependencies in my second workplace?
Isn't it against resolution process? I mean if you have multiple
dependencies then do you need to go and find every single one of the
transient dependencies in your current local repositories. This can be
exponentially big. Should not resolution find the dependencies even though
they are not on your local repositories? I know I am going in the territory
of MVN but I really thing there must be a simpler way. Similar to
"provided" in MVN may be? or a global, I mean literally global "cnf"?
>
>
> I also tried to export the dependencies of ProjectB.provider from
ProjectB.provider to aid the resolution in Workspace2 but this does not
seem right either in terms of the size of ProjectB or conventions of OSGi.
So can you please tell me how can one use external bundle and resolve
without knowing the transient dependencies? IF this cannot be done than how
should one proceed to organise their workspaces while collaborating with
others?
>
>
> Sorry for the long message but I wanted to be as clear as possible.
>
>
> Regards
>
> -Daghan
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Where is the RFC and RFP list ?

[Milen Dyankov]

Just as a side note https://github.com/buunguyen/octotree makes
browsing the repo a bit less painful

On Mon, Jul 4, 2016 at 4:17 PM, Raymond Auge  wrote:
> I have to agree with Cristiano.
>
> The issue may be fine on the RFP subdirectory, but on the RFC side it's
> really really hard unless you have a good memory for mapping numbers to RFC
> names. I can personally only keep one or two such mappings in my brain at a
> time. I often have to attempt an iterative search through the structure to
> find what I'm looking for and it's a royal pain in the backside. I
> occasionally get lucky if the person working on the document refers to the
> full name of the RFC in their git commits.
>
> I wish we could find a solution for this.
>
> Sincerely,
> - Ray
>
>
> On Mon, Jul 4, 2016 at 9:29 AM, Cristiano Gavião  wrote:
>>
>> Aaah, that directory is much better:
>> https://github.com/osgi/design/tree/master/rfps
>>
>> On 04/07/2016 05:33, David Bosschaert wrote:
>>
>> Hi Christiano,
>>
>> You can simply see the list in github here:
>> https://github.com/osgi/design/tree/master/rfcs and
>> https://github.com/osgi/design/tree/master/rfps
>>
>> Released OSGi specs can be downloaded from here:
>> https://www.osgi.org/developer/downloads/
>>
>> Hope this helps,
>>
>> David
>>
>> On 2 July 2016 at 17:49, Cristiano Gavião  wrote:
>>>
>>> Hello,
>>>
>>> In the github spec repository (https://github.com/osgi/design) readme
>>> page is specified that a list of specs are maintained here:
>>> http://wiki.osgi.org/wiki/RFCs and here: http://wiki.osgi.org/wiki/RFPs
>>>
>>> But those link are not reachable anymore.
>>>
>>> could someone point me to the right place?
>>>
>>> thanks,
>>>
>>> Cristiano
>>> ___
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>>
>>
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>>
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
>
> --
> Raymond Augé (@rotty3000)
> Senior Software Architect Liferay, Inc. (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
http://about.me/milen
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Java 9 / JSR 276 and OSGi plans

[Milen Dyankov]

Thanks for the link Neil but I've seen your post already (much like
everything else you make publicly available :)

Regards,
Milen

On Fri, Mar 11, 2016 at 1:49 PM, Neil Bartlett <njbartl...@gmail.com> wrote:

> The following does not answer your question with respect to the OSGi
> Alliance’s official plans… however I have already built a proof-of-concept
> demonstrating that OSGi can run within the Java 9 “unnamed module” and
> resolve dependencies against the platform modules. I wrote a blog post
> about it here: http://njbartlett.name/2015/11/13/osgi-jigsaw.html
>
> Regards,
> Neil
>
>
> On 11 Mar 2016, at 12:44, Milen Dyankov <milendyan...@gmail.com> wrote:
>
> Hello,
>
> can someone please point me to some resource that describes the plans for
> OSGi / JSR 276 interoperability?
>
> I'm sorry if this has been already discussed here, I just joined the list
> after trying without success to search through archives. I was also pretty
> sure it would be easy to find this information online but it seams it's
> either not available or I don't know how to find it.
>
> To put some more context to my question, at the moment I'm interested to
> know how people who make decisions about OSGi's future, would describes the
> general approach of building applications with Java9 and OSGi, rather than
> discuss deep technical details.
>
> It seams to me that Penrose project is inactive (judging by source code
> and mailing list activities) from around 2012/2013. Not that I'm very
> familiar with it, but IIRC it was supposed to provide that
> interoperability. From what I can tell, there is no much interest (if at
> all) in this subject from the Java platform engineers. So, assuming Java 9
> will be released soon (let's just say 2017 is soon enough for long term
> planning) what will be the recommended way to run OSGi on top of it? Would
> one just continue to use classpath and ignore modulepath? If not, then are
> there any plans for future versions of OSGi to allow to dynamically load
> java modules? Will bundles need to be converted to java modules (perhaps
> automatically behind the scenes) or vice versa?
>
> I would really appreciate it, if someone can share a vision of how would
> one build applications with Java 9 and OSGi in the foreseeable future.
>
> Thank you,
> Milen
>
> --
> http://about.me/milen
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>



-- 
http://about.me/milen
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev