Community
Participate
Working Groups
I have no idea where this bug belongs, so it might need to be reclassified. With plain 3.2 M5 or M5A and the latest version of Subclipse (0.9.108) everything works fine. With 3.2M5A and then install WTP 1.5 and its requisites, it stops working. When right-clicking on existing projects in workspace, the Team menu only has the Apply Patch option. When checking out a new project, the same happens. Eclipse clearly knows the project is under source control as the decorators are still there, and the Share Project option is disabled, but the rest of the menu options are not there. If you drop into the folders and files, the options are all there. There is nothing in the error log. This would seem to point to WTP, except I would assume that an unrelated plugin should not be able to affect the relationship between other plugins. In my example, I am using plain Java projects. The CVS plugin does not appear to be suffering from the same problems.
Created attachment 35764 [details] Subclipse plugin.xml Here is the plugin.xml for the Subclipse UI plugin. Perhaps you can spot incorrect or outdated techniques for attaching our menu options.
Subclipse has a method which is using Internal Eclipse classes (because we could find no other way). This would have been compiled against Eclipse 3.0. Could this be the cause of the problem? I have no reason to believe so, other than I know that using internal code is always dangerous. /** * Return the resource type (FILE, FOLDER, PROJECT) of the resource specified by an absolute filesystem path * @param a resource path relative to workspace root as returned by pathForLocation() * @return IResource.FILE, IResource.FOLDER, IResource.PROJECT or IResource.ROOT or 0 if it could not be determined */ public static int getResourceType(IPath aResourcePath) { if (aResourcePath == null) return 0; //TODO This code is using eclipse internal classes ! ResourceInfo resourceInfo = ((Workspace) ResourcesPlugin.getWorkspace()).getResourceInfo(aResourcePath, true, false); return (resourceInfo != null) ? resourceInfo.getType() : 0; }
Hmm, I don't see the problem at first glance. In what view are you selecting resources - Package Explorer, Navigator, or other view? The API equivalent of the internal code in comment #2 is somehting like: IResource r = ResourcesPlugin.getWorkspace().getRoot().findMember(resourcePath); return r == null ? 0 : r.getType();
Michael, CCing you because it may be related to resource mapping work.
Thanks for the API code. I will make that change if nothing else. I saw this problem in all views I checked, which were the Package Explorer and Navigator. OK, here is another weird symptom. If the Resource or Java perspective is the active perspective when I restart, I see this problem. If I change to the J2EE Perspective from WTP, I then can see the menu in all views. Again, these are just Java Projects. I know the person who reported this to me is on the CC list. Maybe he can comment if he observes this same behavior. I was under the impression he was working from WTP, but maybe not? Finally, once the menu is enabled, I notice there are two Disconnect ... options and one of them is disabled. Perhaps another clue, perhaps not?
Are there any errors in your log file?
I do not have any when I create the problem, so let's say No. The person who reported it to me reported seeing this in his log: "!MESSAGE Could not instantiate provider org.tigris.subversion.subclipse.core.svnnature for project com.robco.Acme. org.eclipse.team.core.TeamException: Could not instantiate provider org.tigris.subversion.subclipse.core.svnnature for project com.robco.Acme. " But we were looking at this after the fact, so maybe this came at a different time. I get the same problem as he does and I do not see this message.
Another question for the originator is what build of WTP is being used. WTP 1.5 is reported, but that won't be available until June 2006. It's possible he's using a build of WTP that just doesn't work against 3.2 M5a.
I think we are both using what they are calling 1.5 on the download page. My reported version for JST is 1.0.1.v200602280450--tToQFPPrF and for WST is 1.0.1.v200603022200-0fxbsWqriW. I download this AM from: http://download.eclipse.org/webtools/downloads/drops/S-1.5M5-200603022222/
1.5M5 is what they are calling it, and the download page for it shows M5a as the eclipse build to use.
FWIW, Rob confirms that he sees the same thing that I do in comment #5. Basically, if yopu switch to the J2EE Perspective the menu options are restored and you can then go back to the other views/perspective and they are still there.
Also see Bug 130893 which has been opened in WTP for this problem. Perhaps some from Eclipse Platform could help them figure this out? It seems like there is some more info being gathered.
*** Bug 130893 has been marked as a duplicate of this bug. ***
Here's an update: from the plugin.xml Mark attached, it doesn't look like a subversion plugin. Some possible causes: - WTP is messing with the subversion persistent property (unlikely) - There's a bug in the UI mechanism for building context menus for popupMenu extensions - There's a bug in core.resources involving failure to access persistent properties. Further investigation is needed to narrow it down, and I don't currently have time. One thing someone with both subversion and wtp could try is switching the subversion popupMenus IResource object contributions to the new resource mapping mechanism now used by CVS. This would narrow down the possible source of the bug. I.e., changing this in the subversion plugin.xml <objectContribution objectClass="org.eclipse.core.resources.IResource" adaptable="true" id="org.tigris.subversion.subclipse.ui.ResourceContributions"> <filter name="projectPersistentProperty" value="org.eclipse.team.core.repository=org.tigris.subversion.subclipse.core.svnnature"> </filter> To: <objectContribution objectClass="org.eclipse.core.resources.mapping.ResourceMapping" adaptable="true" id="org.tigris.subversion.subclipse.ui.ResourceContributions"> <enablement> <adapt type="org.eclipse.core.resources.mapping.ResourceMapping"> <test property="org.eclipse.core.resources.projectPersistentProperty" args="org.eclipse.team.core.repository,org.tigris.subversion.subclipse.core.svnnature" /> </adapt> </enablement>
Subclipse is currently supporting Eclipse 3.0. If I make this change, will it work back to Eclipse 3.0? Thanks
I was just suggesting that as a debugging measure to help track down the cause of the problem (whether the bug is in the <filter> mechanism for popupMenus). But yes, if you moved to this it would only work on 3.2.
I can confirm that addig the changing the object contribution does fix the problem. Removing the filter also works.
I can also confirm that removing the filter or adding the enablement allows the menu tiems to work after you execute eclipse with a "-clean" option. With that be said is this a platform issue that broke previously working plugins or a subclipse issue where it needs to use the 3.2 way of doing things?
This suggests to me a problem with the <filter> mechanism in the popupMenus extension point. This is not a Subclipse problem - the old filter mechanism should continue to work.
I think this is Doug...
Bug summary: Subclipse plugin has an popupMenus object contribution on IResource. It uses a <filter> tag on a project persistent property. When WTP is installed, object contributions from Subclipse on projects (IProject) stop working. When the <enablement> mechanism is used instead, but still using a property persistent property, the contributions work.
John: I don't think that the test given in comment #14 is sufficient to indicate a problem in the filter mechanism itself. Not to mention, that code hasn't been touched in a very long time. But, we're probably the best people to be looking at this.
The problem is that the org.eclipse.jst.j2ee.ui plugin is defining an IActionFilter for IProject. This action filter replaces the filter provided by the IDE (i.e. the adaptable mechanism only supports a one-to-one mapping). The Subclipse menus don't show up initially because the J2EE plugin isn't loaded and the adapter mechanism doesn't load plugins during menu filter checking. Two Disconnects show up in the J2EE perspective because the filter returns true as the default behavior for any property that the J2EE filter doesn't know about (so the CVS disconnect is also appearing). The J2EE plugin should not be defining an IActionFilter on IProject. I've taken a look at the code and it appears that the filter is only interested in IFacetedProjects. However, I noticed that another plugin (org.eclipse.wst.common.project.facet.ui) already defines an action filter for facted projects. Either, the offending filter should be removed or it must target something other than IProject or IFacetedProject. If the only use of the IActionFilter is menu enablement, you may want to consider switching to the use of Core/Expressions for menu enablement. This was introduced in 3.2 to overcome some of the limitations of IActionFilters.
*** Bug 133685 has been marked as a duplicate of this bug. ***
The J2EEUI plugin no longer defines an IActionFilter. This is released for the 033006 WTP 1.5 M6 build.
*** Bug 135728 has been marked as a duplicate of this bug. ***
(In reply to comment #25) > The J2EEUI plugin no longer defines an IActionFilter. This is released for the > 033006 WTP 1.5 M6 build. Is this release available for public download? If so, at what location? If not, when will it be available? Thank you, - Venkatesh
M6 was declared today. See http://download.eclipse.org/webtools/downloads/drops/S-1.5M6-200604140226/
I have gotten a couple of emails asking that I verify the bug is fixed. I assume that means it wants me to take the "Mark Bug as Verified" option. Anyway, that is what I am doing. I can verify that this bug is fixed.
OK
*** Bug 133300 has been marked as a duplicate of this bug. ***
