Community
Participate
Working Groups
Refer to bug #361356. We have to be able to specify encoding for classpath entries, which can be used for source attachments. The encoding will be stored on the classpath using an extra classpath attribute. For more details, look at bug 361356.
Any chance of this going for M5? As Dani mentioned here (bug 361356, comment #14), this also sort of blocks bug 361356.
Deepak, please also review/verify the Core part.
Created attachment 209686 [details] screenshot of new design - 1 I am almost done with the UI (testing things now) and just need a quick feedback on the layout of various controls in the UI. Dani, what do you think?
Created attachment 209687 [details] screenshot of new design - 2
Created attachment 209731 [details] fix The patch should be good to go. The UI allows specifying the encoding for source attachments which are not in workspace or the corresponding classpath entry is of type IClasspathEntry.CPE_VARIABLE.
Created attachment 209737 [details] screenshot of new design - 1 Updated screenshot.
Created attachment 209738 [details] screenshot of new design - 1 Something went wrong the last time.
Looks good overall. Tested the known paths. Two things I noticed: - The encoding field is empty for the rt.jar's source. Should be the OS encoding. - When editing the rt.jar's source I'd expect that src.jar is selected and I can hit 'Open' in the dialog.
Ah, and please update the doc.
(In reply to comment #8) > Looks good overall. Tested the known paths. Two things I noticed: > - The encoding field is empty for the rt.jar's source. Should be the OS > encoding. Will it always be 'OS encoding'? If yes, should the combo control for encoding be disabled in this case? I guess the same behavior should apply to jars from plug-in container or any other container for that matter, no? > - When editing the rt.jar's source I'd expect that src.jar is selected and I > can > hit 'Open' in the dialog. This is old behavior :-) Should not be difficult to fix though.
(In reply to comment #10) > (In reply to comment #8) > > Looks good overall. Tested the known paths. Two things I noticed: > > - The encoding field is empty for the rt.jar's source. Should be the OS > > encoding. > Will it always be 'OS encoding'? What else do you expect? > If yes, should the combo control for encoding > be disabled in this case? ??? Not really, right? The key is to allow to change this. But the default should be shown.
(In reply to comment #11) > > Will it always be 'OS encoding'? > What else do you expect? I guess you want that in case the user has not specified the encoding for a jar we show the default encoding just like the encoding for a resource. () Inherited from container (zzzz) () Other [_____] Also a bit more work is required to support jars in the JRE container, for example see org.eclipse.jdt.internal.launching.JREContainerInitializer.requestClasspathContainerUpdate(IPath, IJavaProject, IClasspathContainer) I don't know yet if anything would be required for PDE container.
> Also a bit more work is required to support jars in the JRE container, for > example see I am trying to create a patch for JDT/Debug, let's see how that goes.
(In reply to comment #12) org.eclipse.jdt.internal.launching.JREContainerInitializer.requestClasspathContainerUpdate(IPath, > IJavaProject, IClasspathContainer) > > I don't know yet if anything would be required for PDE container. PDE container seems to be alright. But user libraries are having a bit of problem in keeping the encoding value entered.
(In reply to comment #12) > (In reply to comment #11) > > > Will it always be 'OS encoding'? > > What else do you expect? > I guess you want that in case the user has not specified the encoding for a jar > we show the default encoding just like the encoding for a resource. > > () Inherited from container (zzzz) > () Other [_____] > Nope, just set default into your existing widget (but don't persist it).
(In reply to comment #13) > > Also a bit more work is required to support jars in the JRE container, for > > example see > I am trying to create a patch for JDT/Debug, let's see how that goes. This is quite a bit of work. Hence, I have filed bug 369188 and for now will disable in the UI encoding editing for container classpath entries.
Created attachment 209856 [details] additional fix - work in progress > disable in the UI encoding editing for container classpath entries. I am almost there. - Editing is disabled for JRE container - Editing is enabled for User Library container - Problems with user libraries as mentioned in comment 14 are fixed. Essentially I now check if a classpath container supports editing of encoding. Hence, when JRE container (or any other container) begins to support it, things should just work seamlessly. Currently only User Library container supports it. TODOs: - Show used encoding value when the user has not specified it - Enable encoding editing via 'Attach Source' action - Testing
Everything should work nicely with this pushed commit - e7c4b9c222d5aea7f6613838bdb5851672306793 Note: There is one new API - org.eclipse.jdt.ui.wizards.BuildPathDialogAccess.configureSourceAttachment(Shell, IClasspathEntry, boolean) (In reply to comment #8) > - When editing the rt.jar's source I'd expect that src.jar is selected and I > can hit 'Open' in the dialog. Initially the source can be an external file or folder, and then the user can click either external file or folder buttons. Trying to implement the above leads to too much complexity for too little gain. Hence I have left things as is. (In reply to comment #9) > Ah, and please update the doc. I will work on this now.
Updated the doc as well - http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=05d428b264c4fa91e64ebc029a18c876536ee0c8
The UI needs some more polish: - Browse button misses ... - The sub-options should be indented, see "Javadoc Location" properties page. - Only show the Encoding label and combo if editing the encoding is supported. Don't show disabled controls that can never be enabled in a given instance of the dialog.
(In reply to comment #20) > The UI needs some more polish: > - Browse button misses ... > - The sub-options should be indented, see "Javadoc Location" properties page. Fixed in master - 84637a701752506c342f3d2dc0ba5b2d72564795 > - Only show the Encoding label and combo if editing the encoding is supported. > Don't show disabled controls that can never be enabled in a given instance of > the dialog. Dani had wanted to show the default encoding in disabled state for rt.jar. Hence, I have left this as is for now. We can discuss this in our call tomorrow.
> Dani had wanted to show the default encoding in disabled state for rt.jar. OK, that makes sense. However, I currently only see the encoding if the rt.jar already has a source attachment. It should also be shown if no source attachment is set. Same problem if the encoding is editable: The combo only comes up with a value if there was already a source attachment initially.
(In reply to comment #22) Reopening.
(In reply to comment #22) > OK, that makes sense. However, I currently only see the encoding if the rt.jar > already has a source attachment. It should also be shown if no source > attachment is set. Same problem if the encoding is editable: The combo only > comes up with a value if there was already a source attachment initially. Fixed in master - b73f6b19b673f8d2286e79ea6d7166cfaa8770f7.
