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 14.09.2015 7:37 vorm. schrieb "Eike Stepper" <step...@esc-net.de>: > 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. >> >> For a number of reasons, this may take several days, so in the mean time >> ... are there any other projects effected by this? >> > 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. > > +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.me...@gmail.com> >> To: Cross project issues <cross-project-issues-dev@eclipse.org>, >> Date: 09/12/2015 04:06 AM >> Subject: [cross-project-issues-dev] Unannounced Changes Have Unforeseen >> Consequences >> Sent by: cross-project-issues-dev-boun...@eclipse.org >> >> ------------------------------------------------------------------------------------------------------------------------ >> >> >> >> 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@eclipse.org >> 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@eclipse.org >> 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@eclipse.org > 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@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
