| Re: [cross-project-issues-dev] TableTreeViewer removed (please comment in bug 434575) |
Eike,
Can you please share more details on the issues with SubProcess monitor on https://bugs.eclipse.org/bugs/show_bug.cgi?id=475767?
Best regards, Lars
Am 13.09.2015 um 18:56 schrieb David M Williams:
Thanks for letting us know of the unexpected impact, Ed. I'll talk to the team, and coordinate our response.I've found this issue when working with EMF Compare. Their compare/merge editor logs a ClassDefNotFoundError when I close it. The really bad thing is that the entire IDE becomes totally corrupt after this point, to the extent that it must be restarted. After this error I can not open *any* new editor, not even a simple text editor. And in some cases it seems that even traces of the not completely closed compare editors are kept invisibly in the editor area after a restart.
For a number of reasons, this may take several days, so in the mean time ... are there any other projects effected by this?
+1 for announcing such breaking changes on cross-project-issues-dev (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=436505#c22 , item 2)
I'd also like to suggest that the @deprecated Javadoc tags be enriched with information about:
a) when deprecation became effective, e.g., "@deprecated as of 4.5 no longer supported, please use Xyz instead."
b) when removal is scheduled, e.g., "... Removal of Xyz is scheduled for 4.6."
BTW. I would also love to see a more detailed description of how to replace the usage of the deprecated API in cases where more than a simple Find/Replace is required. A good example (for not enough infos) is the recent deprecation of SubProgressMonitor. When the Problems views in my workspaces filled up with hundreds of deprecation warnings I followed the Javadoc advice "@deprecated use {@link SubMonitor} instead" and did a mass Find/Replace from "new SubProgressMonitor" to "SubMonitor.convert", which fixed all the warnings. But when I tested the resulting code it no longer worked correctly. Progress indicators are always either stuck at 0% or climb up to 100% immediately. I had to revert all my own adjustments and go back to a workspaces full of deprecation warnings, which, of course, is not a permanent solution, either...
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
You should be able to tell, other than brute force searching for the family of classes, by building against our latest I-build, I20150908-0800,
or using it as a PDE target. If you are effected, please comment in bug 434575 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=434575>.
Also, in the mean time, for those of you that "migrated" (e.g. Doug/CDT, for one) can you briefly write-up what changes were needed? Or, point to some Git commits that show the changes?
I'll confess my ignorance here, but I'm trying to determine if there is an "easy pattern" to migrating, or if something that would be highly variable?
Again, a brief comment in bug 434575 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=434575>would be the best place to put these, so easier to find in future.
Thanks again, and my personal apologies for the churn,
From: Ed Merks <ed.merks@xxxxxxxxx>
To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>,
Date: 09/12/2015 04:06 AM
Subject: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
------------------------------------------------------------------------------------------------------------------------
Hi,
It was brought to my attention that
org.eclipse.jface.viewers.TableTreeViewer has been deleted. Yes, I know
it's deprecated, but nevertheless it was once API before being
deprecated so deleting it is a breaking change. I don't recall there
being an announcement to begin deleting arbitrary deprecated API.
In any case, I can't necessarily commit to making the necessary
changes. As such I can't commit to contributing EMF Core to Neon.
I would suggest reconsidering the strategy of breaking APIs and most
certainly suggest any such actions ought to be announced and discussed
before such actions are taken.
Regards,
Ed
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev