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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

+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

Re: [osgi-dev] OSGI enRoute 2.0

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

Re: [osgi-dev] OSGI enRoute 2.0

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

[osgi-dev] OSGI enRoute 2.0

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.

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

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