| FWIW, regarding Logger APIs:
We have several different logging frameworks working at eclipse and every plugin comes with it's own logging configuration. There is no central way of specifying logging outputs, i.e., generally configuring the logging outputs. In particular we have a problem when two projects use slf4j with different configurations. There is a bug [1] describing the issue in more detail.
Ways how to solve this have been taken to the architecture council. Not sure whether there is a solution going on, but to me it may make sense to (i) decide to use or define one logging framework for all eclipse plugins, (ii) provide API to edit/change a shared configuration in order to solve issues seen in bug 400027.
Best, Marcel
I agree, I would also vote for not implementing something Eclipse specific...
Am 07.03.2013 09:18, schrieb Tom Schindl:
The Logger stuff is in a very poor state! I would vote for marking it
deprecated and replace it in Kepler+1 (was it Luna?) with a better
implementation.
Tom
Am 06.03.13 15:52, schrieb Brian de Alwis:
I'm using the Adapter/EclipseAdapter — no need to implement. The
default implementation (EclipseAdapter) saves a lot of boilerplate since
the IAdapterManager doesn't do an IAdaptable check. I personally can't
think of anything else to add to its interface.
Re: Logger: agreed. The world doesn't need yet another logger interface.
I wouldn't say IContributionFactory is ready as it doesn't have a story
for extension points.
Brian.
On 5-Mar-2013, at 4:50 PM, John Arthorne wrote:
Eric Moffatt wrote on 03/05/2013 04:13:56 PM:
Tomorrow I expect to have something on the Services; this is an area
that I'll likely need input on since I only use the EModelService
and EPartService. Tom, we're not going to declare the various
presentation / rendering API now correct ?
FWIW, I scanned through the "core" services in
org.eclipse.e4.core.services today. From what I can see, only
IEventBroker is truly fleshed out and ready to be treated as API.
Logger is probably used enough at this point that we'll need to keep
it, although if I could do things over I'd pick the heavily used SLF4J
Logger API for better interop with existing code. Many of the other
services are used internally but I'm not sure we have proved they are
valuable abstractions or just incomplete replacements for existing 3.x
API. If any consumers are implementing their own IContributionFactory,
Adapter, StatusReporter, or TranslationService I would be curious to
know about them. If there are no strong use cases for making them API
I suggest just leaving them as internal/provisional for this release.
John_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx <mailto:e4-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
|
