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
|