You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Thomas Watson <tj...@gmail.com> on 2021/08/04 16:47:07 UTC
OSGi Working Group Specification Compatible Implementation
Hi,
Now that the OSGi specification development has resumed under the Eclipse
OSGi Working Group we need to discuss how the OSGi Working Group will
consume compatible implementations done within the Apache Felix project.
For the immediate discussion I have been developing the OSGi R8 Declarative
Services implementation in the scrR8 branch [1]. The Apache Felix SCR
implementation has been used as the reference implementation for past
releases of the OSGi specification. This process has changed somewhat now
that the specification is being developed at the Eclipse OSGi Working
Group. There no longer will be something called a "reference"
implementation. Instead there will be one or more implementations that are
"compatible" implementations. In order for the OSGI specification to have
a final release vote there must be one or more (non-snapshot) compatible
implementations publically available from an open source project.
As far as I know, the Apache Felix project has a policy of never having a
release of an artifact that contains non-final OSGi specification classes.
This leaves the OSGi Working Group with a circularity issue because it
cannot have a final release vote of the R8 Declarative Services
specification until there is a publically available (non-snapshot)
compatible implementation but Apache Felix will not publish a non-snapshot
version of SCR R8 implementation to maven central until there is are final
spec API JARs available for the SCR R8 specification.
The proposed process from the OSGi working group is to have open source
projects providing a compatible implementation that is used for the
specification voting would provide a milestone version (M1, M2, etc.) or
release candidate version (RC1, RC2, etc.) to maven central. These
implementations would build against available release candidate OSGI API
JARs from maven central. Then the OSGi Specification project build would
use the compatible implementation's milestone or release candidate from
maven central to build its final version for voting and releasing the final
specification artifacts.
I propose the Felix project allow releases of milestones and/or release
candidates with relaxed rules for including non-final OSGi APIs. Such a
milestone or RC release may depend on release candidate API JARs published
to maven central by the OSGi Specification project. After the OSGi
specification goes final we can then do a final release of the
implementation at our leisure. Is this something we can do in the Apache
Felix project?
Tom
[1] https://github.com/apache/felix-dev/tree/scrR8
Re: OSGi Working Group Specification Compatible Implementation
Posted by JB Onofré <jb...@nanthrax.net>.
Catcha. It makes sense then.
Thanks for details.
Regards
JB
> Le 5 août 2021 à 14:36, davidb@apache.org a écrit :
>
> +1 from me on Tom's proposal too.
>
> Kind regards,
>
> David
>
>> On Thu, 5 Aug 2021 at 13:22, Thomas Watson <tj...@gmail.com> wrote:
>>
>> Hi JB,
>>
>> The spec itself will publish release candidate artifacts. At that time the
>> Felix project can publish its own release candidate based off the OSGi
>> specification release candidate.
>>
>> Assuming all the OSGi Specification project tests pass with the published
>> Felix release candidate implementation then the OSGi working group will be
>> able to proceed with the final voting and publishing of the release final
>> artifacts for the new OSGi specification version. Only after that will
>> Felix then be able to proceed with publishing a final release of the
>> implementation artifact (SCR bundle).
>>
>> Hope that makes things clear.
>>
>> Thanks
>>
>> Tom
>>
>>
>> On Wed, Aug 4, 2021 at 11:53 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>
>>> Hi,
>>>
>>> I agree to release RC or Milestone.
>>>
>>> Now, will the spec release before the impl ? If so, we can cut
>>> "official" release with the impl.
>>> If not, then, agree for RC releases.
>>>
>>> Regards
>>> JB
>>>
>>> On 04/08/2021 18:47, Thomas Watson wrote:
>>>> Hi,
>>>>
>>>> Now that the OSGi specification development has resumed under the
>> Eclipse
>>>> OSGi Working Group we need to discuss how the OSGi Working Group will
>>>> consume compatible implementations done within the Apache Felix
>> project.
>>>>
>>>> For the immediate discussion I have been developing the OSGi R8
>>> Declarative
>>>> Services implementation in the scrR8 branch [1]. The Apache Felix SCR
>>>> implementation has been used as the reference implementation for past
>>>> releases of the OSGi specification. This process has changed somewhat
>>> now
>>>> that the specification is being developed at the Eclipse OSGi Working
>>>> Group. There no longer will be something called a "reference"
>>>> implementation. Instead there will be one or more implementations that
>>> are
>>>> "compatible" implementations. In order for the OSGI specification to
>>> have
>>>> a final release vote there must be one or more (non-snapshot)
>> compatible
>>>> implementations publically available from an open source project.
>>>>
>>>> As far as I know, the Apache Felix project has a policy of never
>> having a
>>>> release of an artifact that contains non-final OSGi specification
>>> classes.
>>>> This leaves the OSGi Working Group with a circularity issue because it
>>>> cannot have a final release vote of the R8 Declarative Services
>>>> specification until there is a publically available (non-snapshot)
>>>> compatible implementation but Apache Felix will not publish a
>>> non-snapshot
>>>> version of SCR R8 implementation to maven central until there is are
>>> final
>>>> spec API JARs available for the SCR R8 specification.
>>>>
>>>> The proposed process from the OSGi working group is to have open source
>>>> projects providing a compatible implementation that is used for the
>>>> specification voting would provide a milestone version (M1, M2, etc.)
>> or
>>>> release candidate version (RC1, RC2, etc.) to maven central. These
>>>> implementations would build against available release candidate OSGI
>> API
>>>> JARs from maven central. Then the OSGi Specification project build
>> would
>>>> use the compatible implementation's milestone or release candidate from
>>>> maven central to build its final version for voting and releasing the
>>> final
>>>> specification artifacts.
>>>>
>>>> I propose the Felix project allow releases of milestones and/or release
>>>> candidates with relaxed rules for including non-final OSGi APIs. Such
>> a
>>>> milestone or RC release may depend on release candidate API JARs
>>> published
>>>> to maven central by the OSGi Specification project. After the OSGi
>>>> specification goes final we can then do a final release of the
>>>> implementation at our leisure. Is this something we can do in the
>> Apache
>>>> Felix project?
>>>>
>>>> Tom
>>>>
>>>> [1] https://github.com/apache/felix-dev/tree/scrR8
>>>>
>>>
>>
Re: OSGi Working Group Specification Compatible Implementation
Posted by da...@apache.org.
+1 from me on Tom's proposal too.
Kind regards,
David
On Thu, 5 Aug 2021 at 13:22, Thomas Watson <tj...@gmail.com> wrote:
> Hi JB,
>
> The spec itself will publish release candidate artifacts. At that time the
> Felix project can publish its own release candidate based off the OSGi
> specification release candidate.
>
> Assuming all the OSGi Specification project tests pass with the published
> Felix release candidate implementation then the OSGi working group will be
> able to proceed with the final voting and publishing of the release final
> artifacts for the new OSGi specification version. Only after that will
> Felix then be able to proceed with publishing a final release of the
> implementation artifact (SCR bundle).
>
> Hope that makes things clear.
>
> Thanks
>
> Tom
>
>
> On Wed, Aug 4, 2021 at 11:53 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
> > Hi,
> >
> > I agree to release RC or Milestone.
> >
> > Now, will the spec release before the impl ? If so, we can cut
> > "official" release with the impl.
> > If not, then, agree for RC releases.
> >
> > Regards
> > JB
> >
> > On 04/08/2021 18:47, Thomas Watson wrote:
> > > Hi,
> > >
> > > Now that the OSGi specification development has resumed under the
> Eclipse
> > > OSGi Working Group we need to discuss how the OSGi Working Group will
> > > consume compatible implementations done within the Apache Felix
> project.
> > >
> > > For the immediate discussion I have been developing the OSGi R8
> > Declarative
> > > Services implementation in the scrR8 branch [1]. The Apache Felix SCR
> > > implementation has been used as the reference implementation for past
> > > releases of the OSGi specification. This process has changed somewhat
> > now
> > > that the specification is being developed at the Eclipse OSGi Working
> > > Group. There no longer will be something called a "reference"
> > > implementation. Instead there will be one or more implementations that
> > are
> > > "compatible" implementations. In order for the OSGI specification to
> > have
> > > a final release vote there must be one or more (non-snapshot)
> compatible
> > > implementations publically available from an open source project.
> > >
> > > As far as I know, the Apache Felix project has a policy of never
> having a
> > > release of an artifact that contains non-final OSGi specification
> > classes.
> > > This leaves the OSGi Working Group with a circularity issue because it
> > > cannot have a final release vote of the R8 Declarative Services
> > > specification until there is a publically available (non-snapshot)
> > > compatible implementation but Apache Felix will not publish a
> > non-snapshot
> > > version of SCR R8 implementation to maven central until there is are
> > final
> > > spec API JARs available for the SCR R8 specification.
> > >
> > > The proposed process from the OSGi working group is to have open source
> > > projects providing a compatible implementation that is used for the
> > > specification voting would provide a milestone version (M1, M2, etc.)
> or
> > > release candidate version (RC1, RC2, etc.) to maven central. These
> > > implementations would build against available release candidate OSGI
> API
> > > JARs from maven central. Then the OSGi Specification project build
> would
> > > use the compatible implementation's milestone or release candidate from
> > > maven central to build its final version for voting and releasing the
> > final
> > > specification artifacts.
> > >
> > > I propose the Felix project allow releases of milestones and/or release
> > > candidates with relaxed rules for including non-final OSGi APIs. Such
> a
> > > milestone or RC release may depend on release candidate API JARs
> > published
> > > to maven central by the OSGi Specification project. After the OSGi
> > > specification goes final we can then do a final release of the
> > > implementation at our leisure. Is this something we can do in the
> Apache
> > > Felix project?
> > >
> > > Tom
> > >
> > > [1] https://github.com/apache/felix-dev/tree/scrR8
> > >
> >
>
Re: OSGi Working Group Specification Compatible Implementation
Posted by Thomas Watson <tj...@gmail.com>.
Hi JB,
The spec itself will publish release candidate artifacts. At that time the
Felix project can publish its own release candidate based off the OSGi
specification release candidate.
Assuming all the OSGi Specification project tests pass with the published
Felix release candidate implementation then the OSGi working group will be
able to proceed with the final voting and publishing of the release final
artifacts for the new OSGi specification version. Only after that will
Felix then be able to proceed with publishing a final release of the
implementation artifact (SCR bundle).
Hope that makes things clear.
Thanks
Tom
On Wed, Aug 4, 2021 at 11:53 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Hi,
>
> I agree to release RC or Milestone.
>
> Now, will the spec release before the impl ? If so, we can cut
> "official" release with the impl.
> If not, then, agree for RC releases.
>
> Regards
> JB
>
> On 04/08/2021 18:47, Thomas Watson wrote:
> > Hi,
> >
> > Now that the OSGi specification development has resumed under the Eclipse
> > OSGi Working Group we need to discuss how the OSGi Working Group will
> > consume compatible implementations done within the Apache Felix project.
> >
> > For the immediate discussion I have been developing the OSGi R8
> Declarative
> > Services implementation in the scrR8 branch [1]. The Apache Felix SCR
> > implementation has been used as the reference implementation for past
> > releases of the OSGi specification. This process has changed somewhat
> now
> > that the specification is being developed at the Eclipse OSGi Working
> > Group. There no longer will be something called a "reference"
> > implementation. Instead there will be one or more implementations that
> are
> > "compatible" implementations. In order for the OSGI specification to
> have
> > a final release vote there must be one or more (non-snapshot) compatible
> > implementations publically available from an open source project.
> >
> > As far as I know, the Apache Felix project has a policy of never having a
> > release of an artifact that contains non-final OSGi specification
> classes.
> > This leaves the OSGi Working Group with a circularity issue because it
> > cannot have a final release vote of the R8 Declarative Services
> > specification until there is a publically available (non-snapshot)
> > compatible implementation but Apache Felix will not publish a
> non-snapshot
> > version of SCR R8 implementation to maven central until there is are
> final
> > spec API JARs available for the SCR R8 specification.
> >
> > The proposed process from the OSGi working group is to have open source
> > projects providing a compatible implementation that is used for the
> > specification voting would provide a milestone version (M1, M2, etc.) or
> > release candidate version (RC1, RC2, etc.) to maven central. These
> > implementations would build against available release candidate OSGI API
> > JARs from maven central. Then the OSGi Specification project build would
> > use the compatible implementation's milestone or release candidate from
> > maven central to build its final version for voting and releasing the
> final
> > specification artifacts.
> >
> > I propose the Felix project allow releases of milestones and/or release
> > candidates with relaxed rules for including non-final OSGi APIs. Such a
> > milestone or RC release may depend on release candidate API JARs
> published
> > to maven central by the OSGi Specification project. After the OSGi
> > specification goes final we can then do a final release of the
> > implementation at our leisure. Is this something we can do in the Apache
> > Felix project?
> >
> > Tom
> >
> > [1] https://github.com/apache/felix-dev/tree/scrR8
> >
>
Re: OSGi Working Group Specification Compatible Implementation
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
I agree to release RC or Milestone.
Now, will the spec release before the impl ? If so, we can cut
"official" release with the impl.
If not, then, agree for RC releases.
Regards
JB
On 04/08/2021 18:47, Thomas Watson wrote:
> Hi,
>
> Now that the OSGi specification development has resumed under the Eclipse
> OSGi Working Group we need to discuss how the OSGi Working Group will
> consume compatible implementations done within the Apache Felix project.
>
> For the immediate discussion I have been developing the OSGi R8 Declarative
> Services implementation in the scrR8 branch [1]. The Apache Felix SCR
> implementation has been used as the reference implementation for past
> releases of the OSGi specification. This process has changed somewhat now
> that the specification is being developed at the Eclipse OSGi Working
> Group. There no longer will be something called a "reference"
> implementation. Instead there will be one or more implementations that are
> "compatible" implementations. In order for the OSGI specification to have
> a final release vote there must be one or more (non-snapshot) compatible
> implementations publically available from an open source project.
>
> As far as I know, the Apache Felix project has a policy of never having a
> release of an artifact that contains non-final OSGi specification classes.
> This leaves the OSGi Working Group with a circularity issue because it
> cannot have a final release vote of the R8 Declarative Services
> specification until there is a publically available (non-snapshot)
> compatible implementation but Apache Felix will not publish a non-snapshot
> version of SCR R8 implementation to maven central until there is are final
> spec API JARs available for the SCR R8 specification.
>
> The proposed process from the OSGi working group is to have open source
> projects providing a compatible implementation that is used for the
> specification voting would provide a milestone version (M1, M2, etc.) or
> release candidate version (RC1, RC2, etc.) to maven central. These
> implementations would build against available release candidate OSGI API
> JARs from maven central. Then the OSGi Specification project build would
> use the compatible implementation's milestone or release candidate from
> maven central to build its final version for voting and releasing the final
> specification artifacts.
>
> I propose the Felix project allow releases of milestones and/or release
> candidates with relaxed rules for including non-final OSGi APIs. Such a
> milestone or RC release may depend on release candidate API JARs published
> to maven central by the OSGi Specification project. After the OSGi
> specification goes final we can then do a final release of the
> implementation at our leisure. Is this something we can do in the Apache
> Felix project?
>
> Tom
>
> [1] https://github.com/apache/felix-dev/tree/scrR8
>
Re: OSGi Working Group Specification Compatible Implementation
Posted by Karl Pauls <ka...@gmail.com>.
Right, let me add: a major part of the reason for the policy was that
previously, OSGi wouldn't make the API publicly available in the first
place. That was problematic as effectively, the felix release would
have been the de-facto official version with all the potential
confusion around that. Assuming that we now would just _consume_ the
API from public places (i.e., maven central) I don't think the policy
applies anymore (or at least has to be that strict). Let me put it
another way: If OSGi is pushing a org.osgi.foo.api.0.0.1-RC1 jar to
maven central - then, that is a release and as such, can be used in a
Felix release already.
That said, there is a valid concern around that because even if we get
the api from a public release, it still is possible that the
implementation has to change because of the spec that is not yet
final. That was the reason we made the policy say: released
specification is required. I think that is still a concern but I would
argue we should allow it provided the release version makes it
reasonable clear that it is a milestone/rc release.
In other words, I'd be fine with Tom's proposal to make it ok to use
api from osgi from maven central and release the implementation with
a version that has an "RC" or "Provisional" or whatever qualifier that
is descriptive enough.
regards,
Karl
On Wed, Aug 4, 2021 at 8:46 PM Raymond Augé
<ra...@liferay.com.invalid> wrote:
>
> +1 My vote would be to follow Tom's recommendation.
>
> For reference here is the Apache Felix policy [1] in question.
>
> Ray
>
> [1]
> https://felix.apache.org/documentation/development/provisional-osgi-api-policy.html
>
> On Wed, Aug 4, 2021 at 12:47 PM Thomas Watson <tj...@gmail.com> wrote:
>
> > Hi,
> >
> > Now that the OSGi specification development has resumed under the Eclipse
> > OSGi Working Group we need to discuss how the OSGi Working Group will
> > consume compatible implementations done within the Apache Felix project.
> >
> > For the immediate discussion I have been developing the OSGi R8 Declarative
> > Services implementation in the scrR8 branch [1]. The Apache Felix SCR
> > implementation has been used as the reference implementation for past
> > releases of the OSGi specification. This process has changed somewhat now
> > that the specification is being developed at the Eclipse OSGi Working
> > Group. There no longer will be something called a "reference"
> > implementation. Instead there will be one or more implementations that are
> > "compatible" implementations. In order for the OSGI specification to have
> > a final release vote there must be one or more (non-snapshot) compatible
> > implementations publically available from an open source project.
> >
> > As far as I know, the Apache Felix project has a policy of never having a
> > release of an artifact that contains non-final OSGi specification classes.
> > This leaves the OSGi Working Group with a circularity issue because it
> > cannot have a final release vote of the R8 Declarative Services
> > specification until there is a publically available (non-snapshot)
> > compatible implementation but Apache Felix will not publish a non-snapshot
> > version of SCR R8 implementation to maven central until there is are final
> > spec API JARs available for the SCR R8 specification.
> >
> > The proposed process from the OSGi working group is to have open source
> > projects providing a compatible implementation that is used for the
> > specification voting would provide a milestone version (M1, M2, etc.) or
> > release candidate version (RC1, RC2, etc.) to maven central. These
> > implementations would build against available release candidate OSGI API
> > JARs from maven central. Then the OSGi Specification project build would
> > use the compatible implementation's milestone or release candidate from
> > maven central to build its final version for voting and releasing the final
> > specification artifacts.
> >
> > I propose the Felix project allow releases of milestones and/or release
> > candidates with relaxed rules for including non-final OSGi APIs. Such a
> > milestone or RC release may depend on release candidate API JARs published
> > to maven central by the OSGi Specification project. After the OSGi
> > specification goes final we can then do a final release of the
> > implementation at our leisure. Is this something we can do in the Apache
> > Felix project?
> >
> > Tom
> >
> > [1] https://github.com/apache/felix-dev/tree/scrR8
> >
>
>
> --
> *Raymond Augé* (@rotty3000)
> Senior Software Architect *Liferay, Inc.* (@Liferay)
> OSGi Fellow, Java Champion
--
Karl Pauls
karlpauls@gmail.com
Re: OSGi Working Group Specification Compatible Implementation
Posted by Raymond Augé <ra...@liferay.com.INVALID>.
+1 My vote would be to follow Tom's recommendation.
For reference here is the Apache Felix policy [1] in question.
Ray
[1]
https://felix.apache.org/documentation/development/provisional-osgi-api-policy.html
On Wed, Aug 4, 2021 at 12:47 PM Thomas Watson <tj...@gmail.com> wrote:
> Hi,
>
> Now that the OSGi specification development has resumed under the Eclipse
> OSGi Working Group we need to discuss how the OSGi Working Group will
> consume compatible implementations done within the Apache Felix project.
>
> For the immediate discussion I have been developing the OSGi R8 Declarative
> Services implementation in the scrR8 branch [1]. The Apache Felix SCR
> implementation has been used as the reference implementation for past
> releases of the OSGi specification. This process has changed somewhat now
> that the specification is being developed at the Eclipse OSGi Working
> Group. There no longer will be something called a "reference"
> implementation. Instead there will be one or more implementations that are
> "compatible" implementations. In order for the OSGI specification to have
> a final release vote there must be one or more (non-snapshot) compatible
> implementations publically available from an open source project.
>
> As far as I know, the Apache Felix project has a policy of never having a
> release of an artifact that contains non-final OSGi specification classes.
> This leaves the OSGi Working Group with a circularity issue because it
> cannot have a final release vote of the R8 Declarative Services
> specification until there is a publically available (non-snapshot)
> compatible implementation but Apache Felix will not publish a non-snapshot
> version of SCR R8 implementation to maven central until there is are final
> spec API JARs available for the SCR R8 specification.
>
> The proposed process from the OSGi working group is to have open source
> projects providing a compatible implementation that is used for the
> specification voting would provide a milestone version (M1, M2, etc.) or
> release candidate version (RC1, RC2, etc.) to maven central. These
> implementations would build against available release candidate OSGI API
> JARs from maven central. Then the OSGi Specification project build would
> use the compatible implementation's milestone or release candidate from
> maven central to build its final version for voting and releasing the final
> specification artifacts.
>
> I propose the Felix project allow releases of milestones and/or release
> candidates with relaxed rules for including non-final OSGi APIs. Such a
> milestone or RC release may depend on release candidate API JARs published
> to maven central by the OSGi Specification project. After the OSGi
> specification goes final we can then do a final release of the
> implementation at our leisure. Is this something we can do in the Apache
> Felix project?
>
> Tom
>
> [1] https://github.com/apache/felix-dev/tree/scrR8
>
--
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow, Java Champion