Community
Participate
Working Groups
Because TaskRepository doesn't implement IAdaptable, the registered adapter for TaskRepository=>IActionFilter doesn't get consulted on Eclipse 3.2, so the "supportsQuery" test doesn't work, so the contributed "New Task...", "New Query...", and "Open Repository Task..." popupMenu items in the Task Repositories view do not get enabled. In Eclipse 3.3, that particular problem goes away because various parts of Eclipse, including the objectState test, now go on to consult the Adapter Manager manually if an object doesn't implement IAdaptable. Nevertheless, it seems wise to me that key Mylyn objects such as TaskRepository should extend PlatformObject (or otherwise implement IAdaptable) to prevent oddities like this from occurring. People expect IAdaptable to be implemented. I have not examined the code to see which other API objects such a change could apply to.
Mylyn contributes org.eclipse.mylyn.internal.tasks.ui.TaskRepositoryAdapterFactory that is used instead of directly implementing IAdaptable. The reason it been done trough the factory is because we can't use classes from tasks.ui plugin (those are needed to implement adapter for IActionFilter) from within tasks.core plugin (where TaskRespository resides). By the way, it is also my understanding that there is no plans to continue support for Eclipse 3.2
My point is that if you extend PlatformObject then the Adapter Manager/factory mechanism works seamlessly. Anyone calling TaskRepository.getAdapter will get access to the TaskRepositoryAdapterFactory. But if you don't extend PlatformObject, then any code that does the traditional if (obj instanceof IAdaptable) IActionFilter filter = (IActionFilter)((IAdaptable)obj).getAdapter(IActionFilter.class); will fail. The original, standard adapter pattern fails, and so only code that goes through the extra rigmarole of interrogating the Adapter Manager manually can get hold of your contributed adapters. That's not how adapters were supposed to work. In the other direction, it's clear why various parts of Eclipse have started interrogating the Adapter Manager - it does allow people to adapt third-party objects that were never originally marked as adaptable. But still, your code is more likely to work correctly in all circumstances if you do implement IAdaptable. The suggested patch is simply to add "extends PlatformObject" to TaskRepository. That's the complete patch. It's binary compatible, and it makes the menu work on Eclipse 3.2. So I've applied that patch to the copy of 2.0 I'm distributing. On the subject of not supporting Eclipse 3.2, that strikes me as a mistake. Eclipse 3.3 has only been out for a few months, and there are third-party IDEs based on Eclipse that take time to update to a new release. So any significant problems with Mylyn 2.0 need to be fixed for people using those IDEs. I'm not claiming this bug is worth a patch, but showstoppers like the problem with Jira 3.10 are. I would have expected maintenance bug fixes for Mylyn on Eclipse 3.2 to continue until Eclipse 3.4 release, not to be dropped dead at the point of 3.3 release.
I updated bug summary to reflect the suggested change. BTW, fixes for the JIRA connector don't require patches in Mylyn 2.0 and new connector builds can be installed on 2.0. Mik even relaxed dependency, so it can be done from the regular "extras" update site.
Steffen, Eugene: I'm fine with the proposal to make Task Repository given the arguments provided. Any reason you can see not to? Kevin: please file a new bug about support 3.2, in case others share your situation. The problem is that we have to support Eclipse 3.3 and 3.4, and only have the resources to support two concurrent Eclipse streams (that already yields a non-trivial overhead, especially a few months into the year). Support 3.2 in addition would be a huge overhead, so we are hoping that most users will be able to work with the 2.0 release on 3.2, and use updated versions of their connectors if needed. But do file the bug in case this needs to be discussed further.
*** Bug 206094 has been marked as a duplicate of this bug. ***
I don't have objections to make TaskRepository extend PlatformObject
Done. In general, I'm happy with things we consider to be adaptable extending PlatformObject, so as we come across other instances of this we can fix them as well.
Created attachment 80726 [details] mylyn/context/zip
(In reply to comment #7) > Done. In general, I'm happy with things we consider to be adaptable extending > PlatformObject, so as we come across other instances of this we can fix them as > well. Note that extending PlatformObject may not be appropriate for the headless stuff we want to allow to run outside of OSGi.
We don't currently support running without org.ecipse.core.runtime, and afaik you can actually run outside of Equinox/OSGi if you don't put that on your classpath, even if we use classes like PlatformObject. But I haven't verified this for a while, and haven't verified this with anything of ours extending PlatformObject. If this prevents anyone from using the API headless we an reconsider this decision.
