Community
Participate
Working Groups
3.3.M1 test pass From some plugin project in the workspace 1. Expand Plug-In Dependencies 2. Expand a project 3. Open its plugin.xml Is: The editor tab hover only shows 'plugin.xml' Should: Indicate to which project the plugin.xml belongs to (Problem occures if you found this plugin.xml through a plugin search)
To reproduce ensure that the selected plugin.xml is not from a project which is in the workspace. I've opened the plugin.xml with the pde editor.
Created attachment 47551 [details] screenshot I'm a bit confused as I can't reproduce this issue... see screenshot... maybe I don't understand what you're talking about ;) Screenshots help when talking about problems like this :)
Created attachment 47598 [details] screenshot :-) Yes, sorry, this was a 'bit' confusing... It must be a plugin.xml from a project which is not avilable as source in the workspace, see screenshot... Maybe the hover should state something like 'org.eclipse.u_3.3.0.I.../plugin.xml'
thoughts on this one Wassim? I'm getting lost in debugging this one.
So I traced this one to us getting a JDT JarEntryEditorInput versus a PDE JarEntryEditorInput. The JDT implementation has no way to get to the actual zipfile which we need in order to properly display the tooltip. Thoughts Wassim? Also, it seems we should just open a text editor, similar to how we do MANIFEST.MF
right. the problem described in comment 0 is due to a limiation in JDT's JarEntryEditorInput. Chris, you should open a separate bug report against PDE to fix our implementation of the jar input, which occurs when you double-click on a blue icon in the Plug-ins view.
The summary is incorrect: the editor input gets an IStorage from which the JarEntryEditorInput uses getFullPath() for the tool tip text and for its full path. So nothing to blame the JarEntryEditorInput for. Unfortunately JDT Core's JarEntryFile does not provide the full path. Adapting summary and moving to JDT Core.
After discussing about this issue with Dani, we agreed that JDT/Core cannot modify JarFileEntry#getFullPath() as this would have side effects on PackageExplorer while displaying jar file contents => move back to JDT/Text
Will have to hack the editor input's tool tip.
Sorry I have to mark this as WONTFIX because JDT Core decide not to provide the parent of a JarEntryFile as I requested a long time ago, see bug 22376.
Suggest to reopen since bug 22376 is now resolved (dup of bug 148944 which is now fixed)
I think we should fix IJarEntryResource.getFullPath(). IStorage.getFullPath() does not specify the exact format of the returned path, so clients already have to handle unexpected results. The easiest fix would be to change JarEntryResource.getEntryName() to just prepend IPackageFragmentRoot#getPath(). Thus, all clients that just use getFullPath() to render an editor tooltip would be happy (this is the most common scenario).
Agreed. IJarEntryResource.getFullPath() should be cleanly speced and return the full path. Comment 8 is no longer an issue as we now render the folders.
I agree to spec IJarEntryResource#getFullPath(). However I don't think this should spec that the full path of the IPackageFragmentRoot is prepend. If we did that it would be hard for a client to extract the root relative path of the entry resource. Consider it as IResource#getFullPath(). It doesn't prepend the workspace path. To get the file system relative path, one should use IResource#getLocation(). Moreover have getFullPath() be a jar relative path corresponds to what a user sees when opening the .jar with a zip viewer (such as WinZip). So you can either do the prepend in your code, or if you consider it to be important, ask for a getLocation() on IJarEntryResource.
getFullPath() is really not speced anywhere for IStorage and as Markus pointed out the most common/expected result of getFullPath() would be to get full path relative to the workspace root. That's what we normally get when using getFullPath().
BTW: getLocation() would be wrong as we do not want to show the location but rather the path rel. to the workspace root.
(In reply to comment #15) > getFullPath() is really not speced anywhere for IStorage Agreed, that why I propose to spec it on IJarEntryResource. (In reply to comment #16) > BTW: getLocation() would be wrong as we do not want to show the location but > rather the path rel. to the workspace root. What about external archives ? For internal archives, getLocation() might not be a food name. Maybe getWorkspaceRelativePath() would be a better name ?
Instead getFullPath() could be speced as returning the - workspace root relative path for JARs inside the workspace - location for external jars
I also don't like prepending that much, unless we for example use '!' to separate JAR path from the path inside the JAR. I would suggest to continue with getFullPath to return the path inside the JAR (/plugin.xml) but add new API on IJarEntryResource getParentJar() : IPackageFragmentRoot
comment 19 sounds good.
Added IJarEntryResource#getFullPath() to specify the full path is relative to the jar and added IJarEntryResource#getPackageFragmentRoot() to return the package fragement root the entry belongs too. Also added regression tests JavaProjectTests#testPackageFragmentNonJavaResources09/11 and testPackageFragmentRootNonJavaResources5/7. Released for 3.3M6 in HEAD.
Adopted this change in JarEntryEditorInput for I20070313-0800.
Verified for 3.3 M6 using build I20070319-1335. Two remarks: - I would align getPackageFragmentRoot's doc (talks about files) upon the doc for getFullPath and getParent (talk about resources), except if this is due to a subtlety I did not get; - I could not make sure from getFullPath's doc whether the returned IPath would start with a leading '/' (as suggested by 'absolute' - and confirmed by tests contents) or not; maybe this is the remark about the result never bearing a trailing '/' that raised doubts in my mind, or the presence of 'absolute' and 'relative to' in a single sentence, or even the comments on this bug; or else maybe the doc would deserve an explicit statement that the returned path starts with '/'.
Thanks Maxime. Entered bug 178226 to capture these issues.
I realize this is an old post, but I'm hoping someone can help me anyway. I need to be able to get the jar file name and path from an IStorageEditorInput (which has type JarEntryEditorInput) as you have discussed below. However the solution you've come up with requires a dependency on JDT, and I absolutely cannot have a dependency on JDT. Is there any possible way to get the path to the jar without the dependency on JDT (as IStorage.getFullPath() just returns the file name within the jar).
(In reply to comment #25) > Is there any possible way to get the path to the jar without the dependency on > JDT (as IStorage.getFullPath() just returns the file name within the jar). There's currently no clean way. IJarEntryResource is only available in JDT Core, so anything you'd do with it depends on JDT. A way to implement this would be to offer something like org.eclipse.debug.core.sourcelookup.containers.ZipEntryStorage in org.eclipse.core.resources and then let JDT's IJarEntryResource implementations use that new ZipEntryStorage. This would need new enhancement requests in JDT/Core and Platform/Resources. Maybe some reflection hacks could also work, but this would still make you depend on JDT (albeit not in your bundle manifest).
