Community
Participate
Working Groups
TeamAction is in an internal package but the javadoc says it is intended to be subclassed by team providers. Could TeamAction be moved into an API package?
My feeling is that the TeamAction class is a bit too messed up in its current form to be made API. Also, there really isn't much there. Was there particular funtionality that you were looking to inherit?
Most of what we (subclipse) do use is indeed the brainded stuff (getShell, getTargetPage, current selection, showView). Probably the only 'team' related thing we use from it at the moment is getProviderMappings (which i think is useful for most team providers). I assume at some point we will also be using the resource mapping stuff that was recently added. Does the CVS team plan to move off all internal Team APIs at some point in the future? Since Subclipse was cloned from the CVS provider we have inherited all of your internal references, which leaves us very exposed to changes in Team (we have already hit at least one recently).
There is no plan to move CVS off the team internal code (it would be too much work). Also, I'm alrady maxed out for this milestone which happens to be the API freeze milestone. So, if you think this is worthwhile, perhaps you could extract out the stuff you think would be useful as API and submit a patch for a new class that could be API. Perhaps you could use the name AbstractActionDelegate as the class name since there is nothing really Team specific in it. If you can do that in the next few weeks, there may be time to get it into M6 (API freeze milestone).
I am not sure that it is 'worthwhile', but it should be done eventually. Even if i do get the patch together before M6 (unlikely), I would be more than happy to wait for the next release for it to become API. Is this the sort of API you were expecting? 1. AbstractActionDelegate : exposes the current selections of the workbench (including views and objects) as well as providing methods to allow subclasses to set the enablement state. 2. TeamAction (or something) : extends AbstractActionDelegate and exposes the provider mappings for the currently selected objects. There isn't much to go in here. All the helper stuff like run and handle methods should be moved up into the providers implementation of TeamAction.
Sounds reasonable. I actually don't mind the error handling being API since all it does is open an error dialog. I just don't think the run methods are the right way to go in general (i.e. they were useful a while ago but have now been replaced by other mechanisms).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
