Community
Participate
Working Groups
The content assist is not available for me on an freshly installed "Neon.3". I have a feeling that t might be related to using the "Set as Target Platfrom" functionality, since using the same eclipse on an fresh workspace seems to work. What I did: git clone https://github.com/jupnp/jupnp.git cd jupnp mvn clean install Import "Projects from Git" After some working on the project there is the content assist ist not available anymore. The root cause seems to originate from a borked .prefs file (attached) beaucse in the editor (after restart) and the log viewer I can see: "For input string: "0${0x0}org.eclipse.jdt.ui.javaTypeProposalCategory" Deleting "jupnp-workspace/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.ui.prefs" restores content assist.
Created attachment 267721 [details] The .prefs leading to the error This files makes the content assist unavailable. THe strange thing is, that content assist types are to even visible under Java -> Editor -> Content Assist -> Advanced
Noopur, any idea what's going on?
BTW, jUPnP was just an example. Had it also with Eclipse SmartHome... My wild guess is, it might be related to the "Set as Target Platfrom".
My guess is that you previously installed Code Recommenders and now it's not there in your new installation. 1. Go to Window > Preferences | Java > Editor > Content Assist > Advanced 2. Click 'Restore Defaults' 3. Click OK If that doesn't work, attach the .log.
Created attachment 267727 [details] Log of restore defaults. "Restore Defaults" did work for me but only after a restart... What I did: 1. Clear the log 2. Restart eclipse 3. Go to Window > Preferences | Java > Editor > Content Assist > Advanced 4. Click 'Restore Defaults' => The dialog is unchanged (no entries) 5. Click OK 6. Go to Window > Preferences | Java > Editor > Content Assist > Advanced => The dialog is unchanged (no entries) 7. Restart eclipse 8. Go to Window > Preferences | Java > Editor > Content Assist > Advanced => The dialog looks good now (relevant entries shown)
Thanks for the update. We can't (or won't) do much here. If the same workspace is used with a different install with different installed plug-ins it's hard to recover.
I have unique workspaces for different projects, eg. JUPnP has its own workspace, ESH has its own workspace... As said, my wild guess is, it might be related to the "Set as Target Platfrom" functionality although I cannot directly point it there. But this is something these workspace have in common... I would be more than happy to provide you more analytical data if I would know how.
(In reply to Victor Toni from comment #7) > I have unique workspaces for different projects, eg. JUPnP has its own > workspace, ESH has its own workspace... What I meant is, that if you have a certain install and then move to a newer version without installing the same plug-ins as before, things can get lost. What exactly happens when it's not available? A dialog? An empty code assist popup? Is something written to the .log?
What I usually do is to setup eclipse with a new blank workspace. (setup as in download a fresh eclipse, extract, start, install plugins as needed, my previous expierience with in place updates are "mixed") Then I clone the project ABC to /git/ABC start eclipseand when asked about the wokspace point it to /workspaces/ABC (which didn't exist before, I dond't even copy settings from one workspace to another...) So my expectation is that I should be more on the safe side. BTW, thanks a lot to pointing me to the "Restore Defaults"! I wouldn't have bothered to hit OK before because nothing (visible) happend... It works for me with a restart so at least it's a fast workaround.
Created attachment 267770 [details] Target platform settings. The file seems clean however the "Perform setup tasks..." action seems to have some problems with it (or generally with the task to be executed. See next attachment.)
Created attachment 267771 [details] Screenshot showing the malformed properties The screenshot shows the properties which are set and which cannot be parsed into a sane configuration. It's not clear to me where these values are originating from... Is this something which I can fix myself in my setup or is this a bug in the "Perform Setup Tasks..."?
(In reply to Victor Toni from comment #10) > Created attachment 267770 [details] > Target platform settings. > > The file seems clean however the "Perform setup tasks..." action AFAIK this doesn't come from the Eclipse SDK. Could be from Ooomph / Installer.
So should this be moved to Ooomph then?
(In reply to Victor Toni from comment #13) > So should this be moved to Ooomph then? Oomph was a guess you can use the menu spy (Alt+Shift+F2) on the 'Perform Setup Tasks...' menu item to find out who contributes it.
(In reply to Dani Megert from comment #14) > (In reply to Victor Toni from comment #13) > > So should this be moved to Ooomph then? > > Oomph was a guess you can use the menu spy (Alt+Shift+F2) on the 'Perform > Setup Tasks...' menu item to find out who contributes it. The result was The active contribution item identifier: org.eclipse.oomph.setup.editor.perform Learned somenthing new today! Thanks! Will move it to Oomph!
Reassigned to Oomph instead of JDT.
Can you attach your ~/.eclipse/org.eclipse.oomph.setup/setups/user.setup
Created attachment 268081 [details] user.setup It contains the same characters as in the error message $${0x0}
Actually, it contains $${0x0} whereas it should contain ${0x0}. Any pattern of the form \${.*} is a variable, and 0x0 is a built-in character that expands to the "null/0" character. A most unfortunate choice of JDT was to use such a null/0 character in a string because such a character cannot be serialized in XML 1.0 nor even XML 1.1 (which allows all control characters except "null/0" to be serialized), so we must escape it somehow, and escaping it as a variable is the logical choice. Of course as soon as you define an escape mechanism, you must define a mechanism to allow the literal form as well, so $$ is the escape for the escape pattern which expands to $ during variable substitution. As such $${0x0} is evaluated to ${0x0}, which is of course what you see when you apply the value of this preference task. You should edit this in your user.setup to change every $${0x0} to ${0x0} and confirm that this works properly. When I test with the latest version of Ooomp, I see it records properly: org.eclipse.jdt.ui.templateProposalCategory:0${0x0}org.eclipse.jdt.ui.swtProposalCategory:1${0x0}org.eclipse.jdt.ui.javaNoTypeProposalCategory:65537${0x0}org.eclipse.jdt.ui.javaTypeProposalCategory:3${0x0}org.eclipse.jdt.ui.textProposalCategory:65539${0x0}org.eclipse.jdt.ui.javaAllProposalCategory:65540${0x0}net.jeeeyul.pdetoos.java.proposal:6${0x0}org.eclipse.e4.tools.jdt.templates.e4ProposalCategory:7${0x0}org.eclipse.mylyn.java.ui.javaAllProposalCategory:8${0x0}org.eclipse.pde.api.tools.ui.apitools_proposal_category:9${0x0}org.eclipse.recommenders.calls.rcp.proposalCategory.templates:10${0x0}org.eclipse.recommenders.chain.rcp.proposalCategory.chain:11${0x0}org.eclipse.recommenders.completion.rcp.proposalCategory.intelligent:12${0x0}. So this appears to be working correctly for me with the latest code. In your version, you can open the preferences, enable the preference recorder, and change this preference to be how you want it, and record that to confirm that its properly recorded ${0x0} and not $${0x0}.
