Community
Participate
Working Groups
As soon as all routers are migrated to use Vector instead of Ray, API removal of Ray class should be promoted, so it can be safely removed.
This should make for some good entertainment! Are you actually going to remove a public class that has been around for 10 years in a release candidate?
OK, maybe you're talking about tagging it for removal somehow using the API tooling. However, no one actually uses API tooling outside of the eclipse "train", since it doesn't scale for real-world development.
We cannot remove public API from a minor release of GEF, in this case GEF 3.6. The API provided by Ray in GEF 3.5 still works 100% in GEF 3.6, it is just deprecated. We have not even considered adopting the platforms API removal policy. We have made Ray deprecated, this is sufficient for the time being. Please confirm Alexander and we can resolve this as wontfix for GEF 3.6.
OK, let me clarify this, as I admit it could be very well misunderstood. My intention was of course not to remove Ray as part of 3.6RC1! Actually I wasn't sure whether the API retention policies (http://wiki.eclipse.org/Eclipse/API_Central/Deprecation_Policy#Announcing_API_Removal) would have to be applied to GEF or not. As such I raised this one so that - in case they would do - we would not forget to announce the removal now (by means of a statement within the deprecation comment), so that according to the retention policy it would then be possible to remove the class after the next but two major releases, that is as part of GEF 3.9 (or whatever version we would be releasing then). If we are not bound to API retention policies we may close this as wontfix. I am fine with that.
I'm don't know of any API ever being removed from GEF (since it was open sourced, R2.1), but I'm also not aware of any official policy ever in place at any given time, either. Obviously bug 310723 would be another breakage of binary and source compatibility late in the game. This was a nice read back when I read it: http://wiki.eclipse.org/Evolving_Java-based_APIs I need to go back and re-read it now that it discusses Java 5 concerns, etc.
Ray is used roughly 40 times in the GMF Runtime project. This change has introduced 40 new deprecation warnings to Helios. Not necessarily bad I suppose, just documenting this fact.
As GEF4 will provide an alternative to Draw2d anyway (JavaFX + GEF4 FX), there is no urgent need to break existing Draw2d users. We may thus leave Ray in place (while it should remain deprecated). Resolving as WONTFIX though.
