Community
Participate
Working Groups
Hi: In eclipse 3.7 m4, the class "org.eclipse.core.runtime.adaptor.EclipseLog" in the jar file org.eclipse.osgi_3.7.0.v20101207.jar *DOES* exist, is not deprecated, is not marked with any notes designating it as considering to be deprecated, and has the following javadoc for the class: /** * The FrameworkLog implementation for Eclipse. * <p> * Clients may extend this class. * </p> * @since 3.1 */ In 3.7m5, this class has 100% utterly disappeared. I would argue strongly that the javadoc comments make this class API and ineligible to be removed without the standard deprecation process.
I am curious how you use this class. The complete package is marked as an internal package in the manifest. The javadoc for the org.eclipse.core.runtime.adaptor package states <javadoc> This package specifies API to start the platform. Clients may use the EclipseStarter loader class to start the platform. The EclipseStarter class is the only defined API in this package. </javadoc> We don't publish the javadoc for the EclipseLog class at all and it never should have been in the package to begin with.
We use it to make custom log files using IStatus objects that are segmented from the generic log file, grouped by different uses, etc. It was a convenient class to use for reading and writing IStatus / CoreException log files.
I can see how it would be used to write a log, but I am not sure I understand how you use it to read log files. The class could be added back and "gutted" to basically call the internal classes where the functionality got moved. But a better option would be for you to have your own copy of the class for your own purposes.
Sure, I can copy the file over... Just thought the fact that the API said it could be extended by clients, and the package name did not say "internal" anywhere, that I assumed it'd be public. I did not do a further check in the manifest.mf to check for xinternal flags.
Not going to add the EclipseLog back at this point.
