On 19 May 2014 10:54, Marcel Offermans <[email protected]> wrote: > Hello David, > > On 19 May 2014, at 10:22 , David Bosschaert <[email protected]> > wrote: > >> On 5/16/14, 20:43 , David Jencks wrote: >>> for instance, debugging the conformance test suite will be more or less >>> impossible, >> >> Yep, if you're writing an RI in Felix and this RI needs to run as part >> of the OSGi CT, it will only work if it uses the official OSGi API. >> As an example take an OSGi CT that looks for a whiteboard service that >> implements the org.osgi.service.http.runtime.HttpServiceRuntime >> interface. >> The CT will not find the implementation if it's renamed to >> org.apache.felix...something. So at least to test the RI as part of >> the CT you need the real API. > > You do, but as far as I know you do not need a release (in the Apache sense > of the word, meaning source code) for that as the OSGi CT only requires you > to submit a binary artifact. And that can easily be produced without doing > any kind of release (and should, because it’s not for public consumption > usually).
Yep, correct. When OSGi releases the RIs and CTs they do want to be able to correlate an RI binary to a commit in the source code tree (e.g. by mentioning a tag or commit ID in the manifest), but it doesn't have to be an official release. >> BTW I think it would be good if this policy could also apply to new >> versions of an existing API. E.g. it should also be usable when we >> move the Core API from 1.7 to 1.8 for Core R6. Thought anyone? > > This policy already applies to new versions of an existing API, right? Great. Cheers, David
