Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [osgi-wg] [platform-dev] How to document OSGi extensibility?

I don't think osgi-wg is the proper forum for design discussions :-)
Lets wait until we get the OSGi Specification Project [1] bootstrapped and have it there.

BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and OSGi Specification Project lead // mobile: +1 386 848 3788
----- Original message -----
From: "Jürgen Albert" <j.albert@xxxxxxxxxxxxxxxxxx>
Sent by: "osgi-wg" <osgi-wg-bounces@xxxxxxxxxxx>
To: osgi-wg@xxxxxxxxxxx, platform-dev@xxxxxxxxxxx
Subject: [EXTERNAL] Re: [osgi-wg] [platform-dev] How to document OSGi extensibility?
Date: Fri, Jan 22, 2021 10:39
Providing some kind of Service and/or annotation to provide
documentation aether at runtime or at development time crossed my mind
as well and could be a good Idea.

It seems that I miss a bit of context here however. What are you
actually proposing?

BTW: With the little context I have, @Whiteboard would be a bad name
choice, because the Whiteboard concept is a bit loaded in the OSGi Context.



Am 22/01/2021 um 16:04 schrieb Christoph Läubrich:
> OSGi Alliance was moved to Eclipse last year... :-)
> OSGi already defines some annotations for the package level see , OSGi
> DS makes heavy use with great success of annotations.
> The problem is more that the Eclipse way of thinking is sometimes
> incompatible with standard OSGi ;-)
> But I think if a draft for a @Whiteboard annotation could be provided
> in Eclipse it might become the reference-implementation of an official
> Eclipse specification later on :-)
> [1]
> Am 22.01.21 um 15:56 schrieb Mickael Istria:
>> On Fri, Jan 22, 2021 at 3:42 PM Christoph Läubrich
>> <laeubi@xxxxxxxxxxxxxx <mailto:laeubi@xxxxxxxxxxxxxx>> wrote:
>>     Good point! I'd like to enhance my annotation idea in the
>> following way:
>>     @Whiteboard(extensions = {
>>          "org.eclipse.ui.genericeditor.contentAssistProcessors"
>>        }
>>        properties = {"xyz"}
>>        }
>>     )
>>     that way it would be possible to automatically read the meta-data
>> and
>>     transform them into help or whatever...
>> Eclipse Platform should avoid the funk of building and relying on
>> Eclipse-specific documentation annotations for OSGi. It looks like in
>> this case, it's more interesting to just bring the idea to the OSGi
>> Alliance so it can become specified or shared with other OSGi
>> projects to identify the best solution in a standard-ish way; and
>> then Eclipse Platform could start using them.
>> Concretely, generating documentation is a difficult task, see how
>> javadoc or PDE extension point doc-gen are complex; we don't want to
>> start dealing with such extra complex new problem in Platform.
>> Note that 1 issue introduced by the idea of documenting on the
>> interface is that it kinds of break the layers: the
>> IContentAssistProcessor interface is not aware of Generic Editor, so
>> it looks like we'd suddenly have to make it kind of aware of it, at
>> least in the doc, creating a (very soft, not technically binding)
>> dependency cycle. That seems undesired to me.
>> _______________________________________________
>> platform-dev mailing list
>> platform-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visit
> _______________________________________________
> osgi-wg mailing list
> osgi-wg@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit

Jürgen Albert

Data In Motion Consulting GmbH

Kahlaische Str. 4
07745 Jena

Mobil:  0157-72521634
E-Mail: j.albert@xxxxxxxxxxxxxxx



Jena HBR 513025

osgi-wg mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit


Back to the top