[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
| Re: [platform-dev] How to document OSGi extensibility? | 
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] https://blog.osgi.org/2018/07/osgi-r7-highlights-bundle-annotations.html
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 https://www.eclipse.org/mailman/listinfo/platform-dev