Re: [osgi-dev] A middle ground between hard dependencies and purely dynamic dependencies (DS)

2016-10-07 Thread Elliot Huntington 
Me. 

On Oct 7, 2016 3:41 PM, "Neil Bartlett"  wrote:

>
> On 7 Oct 2016, at 22:33, Benson Margulies  wrote:
>
> On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett 
> wrote:
>
>
> On 7 Oct 2016, at 20:56, Benson Margulies  wrote:
>
> On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts  wrote:
>
>
>
> On 07/10/16 21:04, Benson Margulies wrote:
>
>
> I am trying to express the following idea using DS:
>
>  "If service X is provisioned in this container, do not activate me
> until it is activated and injected into me. If service X is not
> provisioned in this container, go ahead and activate me without it."
>
>
>
> how about making the dependency: static + greedy + optional.
>
>
> So, in practical terms, how greedy is 'greedy'? What's the behavior?
>
>
> Greedy means that if a service becomes available after your component is
> activated, then it will *always* be supplied to your component, even if
> that
> forces a restart of the component due to the reference having static
> policy.
>
> (It’s worth contrasting this with its opposite, reluctant: if you have an
> optional, static, reluctant reference then your component will NOT be
> restarted in order to give it a service that arrives after it is activated.
> That is, the component will continue to be bound to nothing even when a
> valid candidate service is available. While this makes perfect sense if you
> take the time to think it through, OSGi newbies tend to find it
> counterintuitive).
>
> By the way, with a greedy reference, you will also get re-bound when a
> service comes along that has a higher ranking than the one you are
> currently
> bound to. Again, this happens even if it requires restarting the component
> due to a static reference policy.
>
> All this is in the R6 Compendium spec, Section 112.3.7 “Reference Policy
> Option”.
>
>
> I will do a better job of reading the specs when they are plain HTML
> files, searched by google, and not fenced with a mile legal verbiage.
>
>
> Please don’t misunderstand… when I give a reference to the spec it’s to
> back up what I’m saying so that you know it’s true, and to give you the
> opportunity to dig deeper. It is certainly NOT an accusation that you are
> being lazy for not already having found this information yourself.
>
> I would also like the specs to be more searchable. The PDFs look beautiful
> but that’s not so important unless they are in book form, and who wants to
> carry around a 1246 pages of Compendium?
>
> Neil
>
>
>
>
>
> Regards,
> Neil
>
>
>
>
>
> that way your component will get started always, and restarted once X
> becomes available.
>
>
> I fully appreciate that this concept is not compatible with the
> generally dynamic approach of OSGi in general, and declarative
> services in particular. However, I can think of a variation like:
>
> "I am willing to wait N seconds for service X. If it isn't there by
> then, activate me without it."
>
> I am taking a risk here -- it's always possible that some phenomenon
> would result in a delay of longer than N. But in my case, the startup
> properties of the containing application are such that this would be a
> low risk.
>
> Another possible approach would be to focus on provide/require
> capability. I don't know how I would get DS to pay attention, but it
> seems as if there's not enough information:
>
> Provide-Capability: osgi.service;objectClass:List="com.basiste
> ch.rosette.osgi.RosetteBundleWarmup,com.basistech.rosette.osgi.Rosett
> eComponentService"
>
> Note that any properties are not represented here. So if the
> dependency is specific to some filter on properties, you can't use
> this data.
>
> At the extreme, I could take very close control of start order, and
> then go ahead and use optional references. That's a lot of start order
> management.
>
> Finally? I could use configuration admin, by setting the reference
> cardinality as part of provisioning. To do this cleanly, I think I'd
> want some sort of management layer that generated these 'minimum
> cardinality properties'; editing it in something like Karaf's cfg
> files would be quite messy.
>
> Is there something I'm missing?
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
> --
> Ferry Huberts
> ___
> 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
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
>

Re: [osgi-dev] A middle ground between hard dependencies and purely dynamic dependencies (DS)

2016-10-07 Thread Benson Margulies 
On Fri, Oct 7, 2016 at 5:41 PM, Neil Bartlett  wrote:
>
> On 7 Oct 2016, at 22:33, Benson Margulies  wrote:
>
> On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett  wrote:
>
>
> On 7 Oct 2016, at 20:56, Benson Margulies  wrote:
>
> On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts  wrote:
>
>
>
> On 07/10/16 21:04, Benson Margulies wrote:
>
>
> I am trying to express the following idea using DS:
>
>  "If service X is provisioned in this container, do not activate me
> until it is activated and injected into me. If service X is not
> provisioned in this container, go ahead and activate me without it."
>
>
>
> how about making the dependency: static + greedy + optional.
>
>
> So, in practical terms, how greedy is 'greedy'? What's the behavior?
>
>
> Greedy means that if a service becomes available after your component is
> activated, then it will *always* be supplied to your component, even if that
> forces a restart of the component due to the reference having static policy.
>
> (It’s worth contrasting this with its opposite, reluctant: if you have an
> optional, static, reluctant reference then your component will NOT be
> restarted in order to give it a service that arrives after it is activated.
> That is, the component will continue to be bound to nothing even when a
> valid candidate service is available. While this makes perfect sense if you
> take the time to think it through, OSGi newbies tend to find it
> counterintuitive).
>
> By the way, with a greedy reference, you will also get re-bound when a
> service comes along that has a higher ranking than the one you are currently
> bound to. Again, this happens even if it requires restarting the component
> due to a static reference policy.
>
> All this is in the R6 Compendium spec, Section 112.3.7 “Reference Policy
> Option”.
>
>
> I will do a better job of reading the specs when they are plain HTML
> files, searched by google, and not fenced with a mile legal verbiage.
>
>
> Please don’t misunderstand… when I give a reference to the spec it’s to back
> up what I’m saying so that you know it’s true, and to give you the
> opportunity to dig deeper. It is certainly NOT an accusation that you are
> being lazy for not already having found this information yourself.

OK, sorry about the snark. I have a certain amount of pent-up
frustration, especially after a bunch of URLs went dead when the
enRoute info went up. Thanks as always for the help.


>
> I would also like the specs to be more searchable. The PDFs look beautiful
> but that’s not so important unless they are in book form, and who wants to
> carry around a 1246 pages of Compendium?
>
> Neil
>
>
>
>
>
> Regards,
> Neil
>
>
>
>
>
> that way your component will get started always, and restarted once X
> becomes available.
>
>
> I fully appreciate that this concept is not compatible with the
> generally dynamic approach of OSGi in general, and declarative
> services in particular. However, I can think of a variation like:
>
> "I am willing to wait N seconds for service X. If it isn't there by
> then, activate me without it."
>
> I am taking a risk here -- it's always possible that some phenomenon
> would result in a delay of longer than N. But in my case, the startup
> properties of the containing application are such that this would be a
> low risk.
>
> Another possible approach would be to focus on provide/require
> capability. I don't know how I would get DS to pay attention, but it
> seems as if there's not enough information:
>
> Provide-Capability: osgi.service;objectClass:List="com.basiste
> ch.rosette.osgi.RosetteBundleWarmup,com.basistech.rosette.osgi.Rosett
> eComponentService"
>
> Note that any properties are not represented here. So if the
> dependency is specific to some filter on properties, you can't use
> this data.
>
> At the extreme, I could take very close control of start order, and
> then go ahead and use optional references. That's a lot of start order
> management.
>
> Finally? I could use configuration admin, by setting the reference
> cardinality as part of provisioning. To do this cleanly, I think I'd
> want some sort of management layer that generated these 'minimum
> cardinality properties'; editing it in something like Karaf's cfg
> files would be quite messy.
>
> Is there something I'm missing?
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
> --
> Ferry Huberts
> ___
> 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

Re: [osgi-dev] A middle ground between hard dependencies and purely dynamic dependencies (DS)

2016-10-07 Thread Neil Bartlett 

> On 7 Oct 2016, at 22:33, Benson Margulies  wrote:
> 
> On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett  > wrote:
>> 
>> On 7 Oct 2016, at 20:56, Benson Margulies  wrote:
>> 
>> On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts  wrote:
>> 
>> 
>> 
>> On 07/10/16 21:04, Benson Margulies wrote:
>> 
>> 
>> I am trying to express the following idea using DS:
>> 
>>  "If service X is provisioned in this container, do not activate me
>> until it is activated and injected into me. If service X is not
>> provisioned in this container, go ahead and activate me without it."
>> 
>> 
>> 
>> how about making the dependency: static + greedy + optional.
>> 
>> 
>> So, in practical terms, how greedy is 'greedy'? What's the behavior?
>> 
>> 
>> Greedy means that if a service becomes available after your component is
>> activated, then it will *always* be supplied to your component, even if that
>> forces a restart of the component due to the reference having static policy.
>> 
>> (It’s worth contrasting this with its opposite, reluctant: if you have an
>> optional, static, reluctant reference then your component will NOT be
>> restarted in order to give it a service that arrives after it is activated.
>> That is, the component will continue to be bound to nothing even when a
>> valid candidate service is available. While this makes perfect sense if you
>> take the time to think it through, OSGi newbies tend to find it
>> counterintuitive).
>> 
>> By the way, with a greedy reference, you will also get re-bound when a
>> service comes along that has a higher ranking than the one you are currently
>> bound to. Again, this happens even if it requires restarting the component
>> due to a static reference policy.
>> 
>> All this is in the R6 Compendium spec, Section 112.3.7 “Reference Policy
>> Option”.
> 
> I will do a better job of reading the specs when they are plain HTML
> files, searched by google, and not fenced with a mile legal verbiage.

Please don’t misunderstand… when I give a reference to the spec it’s to back up 
what I’m saying so that you know it’s true, and to give you the opportunity to 
dig deeper. It is certainly NOT an accusation that you are being lazy for not 
already having found this information yourself.

I would also like the specs to be more searchable. The PDFs look beautiful but 
that’s not so important unless they are in book form, and who wants to carry 
around a 1246 pages of Compendium?

Neil


> 
> 
>> 
>> Regards,
>> Neil
>> 
>> 
>> 
>> 
>> 
>> that way your component will get started always, and restarted once X
>> becomes available.
>> 
>> 
>> I fully appreciate that this concept is not compatible with the
>> generally dynamic approach of OSGi in general, and declarative
>> services in particular. However, I can think of a variation like:
>> 
>> "I am willing to wait N seconds for service X. If it isn't there by
>> then, activate me without it."
>> 
>> I am taking a risk here -- it's always possible that some phenomenon
>> would result in a delay of longer than N. But in my case, the startup
>> properties of the containing application are such that this would be a
>> low risk.
>> 
>> Another possible approach would be to focus on provide/require
>> capability. I don't know how I would get DS to pay attention, but it
>> seems as if there's not enough information:
>> 
>> Provide-Capability: osgi.service;objectClass:List="com.basiste
>> ch.rosette.osgi.RosetteBundleWarmup,com.basistech.rosette.osgi.Rosett
>> eComponentService"
>> 
>> Note that any properties are not represented here. So if the
>> dependency is specific to some filter on properties, you can't use
>> this data.
>> 
>> At the extreme, I could take very close control of start order, and
>> then go ahead and use optional references. That's a lot of start order
>> management.
>> 
>> Finally? I could use configuration admin, by setting the reference
>> cardinality as part of provisioning. To do this cleanly, I think I'd
>> want some sort of management layer that generated these 'minimum
>> cardinality properties'; editing it in something like Karaf's cfg
>> files would be quite messy.
>> 
>> Is there something I'm missing?
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> 
>> 
>> --
>> Ferry Huberts
>> ___
>> 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 
>>

Re: [osgi-dev] A middle ground between hard dependencies and purely dynamic dependencies (DS)

2016-10-07 Thread Benson Margulies 
On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett  wrote:
>
> On 7 Oct 2016, at 20:56, Benson Margulies  wrote:
>
> On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts  wrote:
>
>
>
> On 07/10/16 21:04, Benson Margulies wrote:
>
>
> I am trying to express the following idea using DS:
>
>   "If service X is provisioned in this container, do not activate me
> until it is activated and injected into me. If service X is not
> provisioned in this container, go ahead and activate me without it."
>
>
>
> how about making the dependency: static + greedy + optional.
>
>
> So, in practical terms, how greedy is 'greedy'? What's the behavior?
>
>
> Greedy means that if a service becomes available after your component is
> activated, then it will *always* be supplied to your component, even if that
> forces a restart of the component due to the reference having static policy.
>
> (It’s worth contrasting this with its opposite, reluctant: if you have an
> optional, static, reluctant reference then your component will NOT be
> restarted in order to give it a service that arrives after it is activated.
> That is, the component will continue to be bound to nothing even when a
> valid candidate service is available. While this makes perfect sense if you
> take the time to think it through, OSGi newbies tend to find it
> counterintuitive).
>
> By the way, with a greedy reference, you will also get re-bound when a
> service comes along that has a higher ranking than the one you are currently
> bound to. Again, this happens even if it requires restarting the component
> due to a static reference policy.
>
> All this is in the R6 Compendium spec, Section 112.3.7 “Reference Policy
> Option”.

I will do a better job of reading the specs when they are plain HTML
files, searched by google, and not fenced with a mile legal verbiage.


>
> Regards,
> Neil
>
>
>
>
>
> that way your component will get started always, and restarted once X
> becomes available.
>
>
> I fully appreciate that this concept is not compatible with the
> generally dynamic approach of OSGi in general, and declarative
> services in particular. However, I can think of a variation like:
>
>  "I am willing to wait N seconds for service X. If it isn't there by
> then, activate me without it."
>
> I am taking a risk here -- it's always possible that some phenomenon
> would result in a delay of longer than N. But in my case, the startup
> properties of the containing application are such that this would be a
> low risk.
>
> Another possible approach would be to focus on provide/require
> capability. I don't know how I would get DS to pay attention, but it
> seems as if there's not enough information:
>
> Provide-Capability: osgi.service;objectClass:List="com.basiste
> ch.rosette.osgi.RosetteBundleWarmup,com.basistech.rosette.osgi.Rosett
> eComponentService"
>
> Note that any properties are not represented here. So if the
> dependency is specific to some filter on properties, you can't use
> this data.
>
> At the extreme, I could take very close control of start order, and
> then go ahead and use optional references. That's a lot of start order
> management.
>
> Finally? I could use configuration admin, by setting the reference
> cardinality as part of provisioning. To do this cleanly, I think I'd
> want some sort of management layer that generated these 'minimum
> cardinality properties'; editing it in something like Karaf's cfg
> files would be quite messy.
>
> Is there something I'm missing?
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
> --
> Ferry Huberts
> ___
> 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
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] A middle ground between hard dependencies and purely dynamic dependencies (DS)

2016-10-07 Thread Ferry Huberts 



On 07/10/16 21:04, Benson Margulies wrote:

I am trying to express the following idea using DS:

   "If service X is provisioned in this container, do not activate me
until it is activated and injected into me. If service X is not
provisioned in this container, go ahead and activate me without it."


how about making the dependency: static + greedy + optional.

that way your component will get started always, and restarted once X 
becomes available.




I fully appreciate that this concept is not compatible with the
generally dynamic approach of OSGi in general, and declarative
services in particular. However, I can think of a variation like:

  "I am willing to wait N seconds for service X. If it isn't there by
then, activate me without it."

I am taking a risk here -- it's always possible that some phenomenon
would result in a delay of longer than N. But in my case, the startup
properties of the containing application are such that this would be a
low risk.

Another possible approach would be to focus on provide/require
capability. I don't know how I would get DS to pay attention, but it
seems as if there's not enough information:

Provide-Capability: osgi.service;objectClass:List="com.basiste
 ch.rosette.osgi.RosetteBundleWarmup,com.basistech.rosette.osgi.Rosett
 eComponentService"

Note that any properties are not represented here. So if the
dependency is specific to some filter on properties, you can't use
this data.

At the extreme, I could take very close control of start order, and
then go ahead and use optional references. That's a lot of start order
management.

Finally? I could use configuration admin, by setting the reference
cardinality as part of provisioning. To do this cleanly, I think I'd
want some sort of management layer that generated these 'minimum
cardinality properties'; editing it in something like Karaf's cfg
files would be quite messy.

Is there something I'm missing?
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev



--
Ferry Huberts
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] [RFE] specifications: please add package version history

2016-10-07 Thread Ferry Huberts 

Thanks, helpful.

But I'd like it directly in the specs :-)

On 07/10/16 20:05, Bernd Eckenfels wrote:

Hello,

this might be what you are looking for (but not updated lately)

https://docs.google.com/spreadsheets/d/1C3vC9YHzIxxs1yJvhlGqOr1Vn-SpByfp14MuwtFgqrE/edit?usp=sharing

This is unofficial and covers up to R5.

Gruss
Bernd

Am Fri, 7 Oct 2016 10:49:01 +0200
schrieb Ferry Huberts :


Hi

I recently needed to look up in which OSGi release a certain version
of a package was introduced. This required going through all the
specs of the released OSGi versions, since in the latest
specification only the current version of package is specified.

IMHO it would be quite handy to add the history/changelog of the
package versions at the same place. Please add this :-)





--
Ferry Huberts
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

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

2016-10-07 Thread Christian Schneider 

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

Re: [osgi-dev] [RFE] specifications: please add package version history

2016-10-07 Thread Bernd Eckenfels 
Hello,

this might be what you are looking for (but not updated lately)

https://docs.google.com/spreadsheets/d/1C3vC9YHzIxxs1yJvhlGqOr1Vn-SpByfp14MuwtFgqrE/edit?usp=sharing

This is unofficial and covers up to R5.

Gruss
Bernd

Am Fri, 7 Oct 2016 10:49:01 +0200
schrieb Ferry Huberts :

> Hi
> 
> I recently needed to look up in which OSGi release a certain version
> of a package was introduced. This required going through all the
> specs of the released OSGi versions, since in the latest
> specification only the current version of package is specified.
> 
> IMHO it would be quite handy to add the history/changelog of the
> package versions at the same place. Please add this :-)
> 

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

Re: [osgi-dev] [RFE] specifications: please add package version history

2016-10-07 Thread Elliot Huntington 
+1

On Fri, Oct 7, 2016 at 2:49 AM, Ferry Huberts  wrote:

> Hi
>
> I recently needed to look up in which OSGi release a certain version of a
> package was introduced. This required going through all the specs of the
> released OSGi versions, since in the latest specification only the current
> version of package is specified.
>
> IMHO it would be quite handy to add the history/changelog of the package
> versions at the same place. Please add this :-)
>
> --
> Ferry Huberts
> ___
> 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] OSGI enRoute 2.0

2016-10-07 Thread Peter Kriens 
The OSGi enRoute workspace is build with Gradle so yes …

Kind regards,

Peter Kriens


> On 7 okt. 2016, at 16:05, Matt Sicker  wrote:
> 
> Are you also looking for Gradle testers yet?
> 
> On 7 October 2016 at 07:03, Peter Kriens  > wrote:
> Yesterday I asked for maven only testers but I also need some testers for the 
> new OSGi enRoute release that uses Bndtools.
> 
> The key change is the use of the Bnd Pom Repository. This allows the OSGi 
> enRoute Distro to be specified in a pom so that it can be used both from 
> Bndtools and Maven. Currently the Maven artifacts are in SNAPSHOT so I need 
> some feedback from others that they are ok.
> 
> I also removed JPM from the distro and tutorials since I will deprecate jpm 
> early next year for cost/attention reasons. The JPM functionality is also 
> replaced with the Bnd Pom Repository. Lacks the nice drag and drop but the 
> advantage is that you can just paste the widely spread maven dependency info.
> 
> In the library there have been some bug fixes and especially the web server 
> support has become more powerful thanks to David Leangen. It now supports 
> servlets that are conditional. I.e. you can setup a chain of servlets for a 
> URL. 
> 
> The REST support has some additional features and can generate a swagger file.
> 
> I’ve created a next branch on https://github.com/osgi/workspace 
>  with the updated workspace. You can use 
> this workspace in Bndtools by changing your preferences. Select the Bndtools 
> and then Workspace Template. You can add a new entry or change the existing 
> entry to the next branch by editing it.
> 
> If you have any comments/wishes/requests etc. let me know. The intent is to 
> release in about two weeks so feedback in the next week would be highly 
> appreciated. 
> 
> After this release I will not be able to spend significant time on OSGi 
> enRoute and bnd/Bndtools so get your requests in asap!
> 
> Kind regards,
> 
>   Peter Kriens
> 
> 
> ___
> 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



smime.p7s
Description: S/MIME cryptographic signature
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] OSGI enRoute 2.0

2016-10-07 Thread Matt Sicker 
Are you also looking for Gradle testers yet?

On 7 October 2016 at 07:03, Peter Kriens  wrote:

> Yesterday I asked for maven only testers but I also need some testers for
> the new OSGi enRoute release that uses Bndtools.
>
> The key change is the use of the Bnd Pom Repository. This allows the OSGi
> enRoute Distro to be specified in a pom so that it can be used both from
> Bndtools and Maven. Currently the Maven artifacts are in SNAPSHOT so I need
> some feedback from others that they are ok.
>
> I also removed JPM from the distro and tutorials since I will deprecate
> jpm early next year for cost/attention reasons. The JPM functionality is
> also replaced with the Bnd Pom Repository. Lacks the nice drag and drop but
> the advantage is that you can just paste the widely spread maven dependency
> info.
>
> In the library there have been some bug fixes and especially the web
> server support has become more powerful thanks to David Leangen. It now
> supports servlets that are conditional. I.e. you can setup a chain of
> servlets for a URL.
>
> The REST support has some additional features and can generate a swagger
> file.
>
> I’ve created a next branch on https://github.com/osgi/workspace with the
> updated workspace. You can use this workspace in Bndtools by changing your
> preferences. Select the Bndtools and then Workspace Template. You can add a
> new entry or change the existing entry to the next branch by editing it.
>
> If you have any comments/wishes/requests etc. let me know. The intent is
> to release in about two weeks so feedback in the next week would be highly
> appreciated.
>
> After this release I will not be able to spend significant time on OSGi
> enRoute and bnd/Bndtools so get your requests in asap!
>
> Kind regards,
>
> Peter Kriens
>
>
> ___
> 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-dev] OSGI enRoute 2.0

2016-10-07 Thread Peter Kriens 
Yesterday I asked for maven only testers but I also need some testers for the 
new OSGi enRoute release that uses Bndtools.

The key change is the use of the Bnd Pom Repository. This allows the OSGi 
enRoute Distro to be specified in a pom so that it can be used both from 
Bndtools and Maven. Currently the Maven artifacts are in SNAPSHOT so I need 
some feedback from others that they are ok.

I also removed JPM from the distro and tutorials since I will deprecate jpm 
early next year for cost/attention reasons. The JPM functionality is also 
replaced with the Bnd Pom Repository. Lacks the nice drag and drop but the 
advantage is that you can just paste the widely spread maven dependency info.

In the library there have been some bug fixes and especially the web server 
support has become more powerful thanks to David Leangen. It now supports 
servlets that are conditional. I.e. you can setup a chain of servlets for a 
URL. 

The REST support has some additional features and can generate a swagger file.

I’ve created a next branch on https://github.com/osgi/workspace 
 with the updated workspace. You can use 
this workspace in Bndtools by changing your preferences. Select the Bndtools 
and then Workspace Template. You can add a new entry or change the existing 
entry to the next branch by editing it.

If you have any comments/wishes/requests etc. let me know. The intent is to 
release in about two weeks so feedback in the next week would be highly 
appreciated. 

After this release I will not be able to spend significant time on OSGi enRoute 
and bnd/Bndtools so get your requests in asap!

Kind regards,

Peter Kriens



smime.p7s
Description: S/MIME cryptographic signature
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] [RFE] specifications: please add package version history

2016-10-07 Thread Ferry Huberts 

Hi

I recently needed to look up in which OSGi release a certain version of 
a package was introduced. This required going through all the specs of 
the released OSGi versions, since in the latest specification only the 
current version of package is specified.


IMHO it would be quite handy to add the history/changelog of the package 
versions at the same place. Please add this :-)


--
Ferry Huberts
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev