Hi Marcel, Yes you are right about what is needed here. In the immediate term our goal was to understand whether E4's logger should be API. It solves none of the problems you describe so I think pretty clearly the answer is that we will not promote it to API in Kepler. It can still be used internally in the Platform UI code until a better story comes along. Here is a more general bug on the subject with links to other discussions:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=358968 John From: Marcel Bruch <[email protected]> To: E4 Project developer mailing list <[email protected]>, Date: 03/07/2013 03:56 AM Subject: Re: [e4-dev] E4 Formal API Part 2: UI Model Sent by: [email protected] 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 [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=400027 -- Codetrails.com – The knowledge transfer company On Mar 7, 2013, at 9:19 AM, Jonas Helming <[email protected]> wrote: 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 [email protected] <mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/e4-dev _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
