> Mostly because the documentation is the wrong way around. We want to
> make clear from the generic editor user's POV that a whiteboard
> pattern can be used
Actually the nice thing about whiteboardpattern is that the provider of
the service has not to care about its consumers (in contrast to
The annotations idea is very creative but I don't think it is the answer to
Mickaels question.
Mostly because the documentation is the wrong way around. We want to make
clear from the generic editor user's POV that a whiteboard pattern can be
used to inject code, not from the interface. Besides, w
"As its about to document a service interface is intended to be consumed
by the (OSGi) Whiteboard pattern why should it be a bad name?"
Whiteboard is more than just getting services injected. So I would also not
use @Whiteboard for a documentation annotation.
Christoph Läubrich schrieb am Fr., 2
Also maybe the metatype service specification could be used
https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.metatype.html
Dirk Fauth schrieb am Fr., 22. Jan. 2021, 16:38:
> OSGi is making use of annotations in several places to make development
> easier. DS annotations are a good ex
As its about to document a service interface is intended to be consumed
by the (OSGi) Whiteboard pattern why should it be a bad name? :-)
The context is the following:
There is a service interface that is consumed by some other component
using the Whiteboardpattern.
The question was: How can
OSGi is making use of annotations in several places to make development
easier. DS annotations are a good example.
With R7 the bundle annotations were added
https://blog.osgi.org/2018/07/osgi-r7-highlights-bundle-annotations.html?m=1
And there are also component property type annotations that tr
On Fri, Jan 22, 2021 at 4:05 PM Christoph Läubrich
wrote:
> OSGi already defines some annotations for the package level see , OSGi
> DS makes heavy use with great success of annotations.
>
OK, can you please share a link to such example of package-info that's the
good OSGi way. Maybe we can just
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
On Fri, Jan 22, 2021 at 3:42 PM Christoph Läubrich
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 possib
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.
On Fri, Jan 22, 2021 at 2:57 PM Andrey Loskutov wrote:
> What about platform Help? That was invented to document how to use various
> Eclipse APi's together.
>
Yes, obviously. However, Platform Help has a standard way to document
extension points so they're easily discovered and so on; my questi
At a minimum the interface which can be registered as a whiteboard service should have its javadoc updated to indicate the interface is intended for implementers to register their implementations as OSGi services. Any constants that are required in the service registration properties should also h
What about platform Help? That was invented to document how to use various Eclipse APi's together.
Kind regards,
Andrey Loskutov
Спасение утопающих - дело рук самих утопающих
https://www.eclipse.org/user/aloskutov
Gesendet: Freitag, 22. Januar 2021 um 14:08 Uhr
Von: "Mickael Istria"
An:
One way would be to document this at the package-info.java
Maybe it would be worth to have a special annotation that could be
parsed by eclipse and give a hint to the user when a extensionpoint is
used that also supports OSGi services?
another option would be to annotate an interface with a c
Hi all,
In a recent patch, the Generic Editor was improved to enable consumption of
IContentAssistProcessors in the OSGi way (that is by listening to service
tracker).
While we have great ways to document extenson via plugin.xml, do we have a
recommendation about how to document such extensibility
Cool.
I am new to this too. I have activated it (set to 5 (5 jobs?). But a full
java build takes just as long and I do not see multiple build jobs.
I have a 270 project workspace. For normal 99% work, the incremental build
is working fine. It is slow (or rather, it takes a long time) when a full
On Fri, Jan 22, 2021 at 1:04 PM Alex Blewitt wrote:
> Can we update the default to ‘true’ or ‘max processors’ or ‘half
> processors’ or similar, so we can enable it out of the box for every
> project build type? If not, what’s stoppping us from doing so?
>
When this feature was introduced some y
I think if we have a default of ‘max parallel builds: 1’ (or alternatively,
‘parallel builds: false’ and no-one knows about the feature, it’s as good as
non existent to those who use Eclipse.
Can we update the default to ‘true’ or ‘max processors’ or ‘half processors’ or
similar, so we can enab
On Fri, Jan 22, 2021 at 12:03 PM Peter Kriens
wrote:
> That said, practice in my world is that I do not see anybody using it.
> From my perspective it still looks highly experimental in the Java world,
> which for me is the 'this' and it looks like that 'this' could have some
> nudges to move it
> On 21 Jan 2021, at 12:45, Mickael Istria wrote:
> Can you please elaborate about what you mean by "this" and by "forward"? ;)
Well, your description indicates that it is further along than I thought after
trying to find documentation and going through the sources.
That said, practice in my
Hi,
We have M2 contribution on Jan 29, 2021.
Please keep a watch on test failures so that we can submit a good build
for simrel
Thanks
Sravan
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit
http
21 matches
Mail list logo
