Okay, this has been bugging me for quite some time today : Eclipse's Project Explorer adds a prefix "P/" to some of my projects' name. It happens only in the explorer, as everywhere else the project name appears normally.
I didn't manage to find anything relevant on the subject in the doc' and I don't really know how to google it.
I just reinstalled Eclipse's Platform Binary 3.7.2 along with the CDT and Texlipse plugins on Precise. The prefix "P/" appears only with texlipse projects, or when I open a .tex file inside any project.
So my question is : do you know what it means ? How to get rid or it ?
When you call toString() on a Project you get this. The leading P/ indicates it's a project (it's a convention of all of the Eclipse resources, F/ for file for example). This is probably a problem in the Texlipse plugin where the label provider that they provide to the Project Explorer (Common Nagivgator) is wrong, it's using just the project, instead of project.getName(). You should file a bug with them. There is nothing that you can do about it as a user.
Related
I was given a working Eclipse project in Java. If I open it in some version of Eclipse then I get numerous errors. I get them because my version of Eclipse differs (it is not web developer) and vaadin and ivy plugins were used to create the project. How can I understand which version of Eclipse and which plugins are needed? I can get some sense by looking in .setting folder. There are a lot of files with names as namespaces related to plugins. Is there more direct or automatic/semi automatic way to find which plugins and Eclipse version are needed?
No. The Eclipse developers expect you to know your tools and if you take over a project from someone else or join a project, that someone explains to you how to install and configure Eclipse.
To find out which Eclipse plugins you need, look into the file .project and the folder .settings. Google for the file names and plugin IDs to see what they might mean. Usually, the third word of the name is the project (org.eclipse.jdt.* -> JDT project).
For missing classes, you need to look at the classpath. The easiest way to do that is to right-click on your project name and then select "Properties" from the menu. There is an entry "Build Path" which contains all the dependencies. Click through the tabs to see what you need.
For plugin projects, look into the file META-INF/MANIFEST.MF; Eclipse should open a special editor when you open it which has a tab for dependencies.
I'm using the Android Developer Tools wrapper of Eclipse, and the EGit git plugin for Eclipse. I'm having a problem where I'm generating Javadoc, but I can't find it in the package explorer.
I go to Project->Generate Javadoc.
I'm using C:\Program Files\Java\jdk1.7.0_51\bin\javadoc.exe as my Javadoc command, and I select the package I want to generate Javadoc for.
I select the standard doclet with the following destination, where ReverseSentence is my package.
C:\Users\myname\workspace\ReverseSentence\doc
I check "open generated index file in browser", and generate the javadoc. It generates the Javadoc with no errors, and the index shows up in the main section of eclipse. However, the files don't show up in the package explorer.
I searched in the workspace through opening up the folder, and inside workspace\ReverseSentence there is a folder doc, which contains the proper Javadoc. However it isn't showing up in the package explorer.
How do I make it show up in the package explorer? When I used the regular version of Eclipse in the past (not the android developer tools wrapper), the Javadocs showed up there automatically.
What I've tried:
refreshing the project
closing and restarting eclipse
generating the Javadoc with an older version of the Javadoc command, which was what I was using in the other version of eclipse last time it worked (jdk1.6.0_43)
deleting the doc folder, recreating it, then trying to generate the javadoc in it (it generated in it but did not show up)
unchecking the filters which hide some things in the package explorer, (as shown how to do here: How can I get Eclipse to show .* files?)
I think that the problem is the destination folder/directory for your Javadoc files once they are generated. I encountered this same problem and discovered (finally) that the Javadocs were getting sent to a different folder than my package files were in. They went to the workspace folder I thought held all of my code also, but the code was going into a different repository. Maybe try looking for your code's location and then seeing if the generated Javadocs are landing somewhere else when they are generated. If this is the case, then the fix is to regenerate and send to the code's directory. This way, Package Explorer should be able to find and display them. Hope this helps!
Did you try by refreshing the workspace or re-opening the eclipse !?
Check the filters in the settings of the explorer. If something does not show up, usually the filter hides it. The filter can be accessed in the drop down menu of Package Explorer.
I had a problem with finding Java docs in Eclipse. I seem to have fixed the problem, but I'm posting this for two reasons: I would like to know why I had the problem in the first place and perhaps my method of fixing it might be useful to someone else having a similar problem.
I created a simple Java project in Eclipse (Helios on Windows 7) and selected the JavaSE-1.6 JRE. Then I created a source file and imported java.util.GregorianCalendar. When I hovered over GregorianCalendar, I was getting the message:
This element has no attached source and the Javadoc could not be found in the attached Javadoc
None of the methods of GregorianCalendar seemed to have any Javadoc, either. Other standard Java classes (even others in java.util, like ArrayList) didn't have this problem; only GregorianCalendar. Everything seemed set up properly in the project settings. The Javadoc location set in the Java Build Path was http://java.sun.com/javase/6/docs/api/.
I managed to restore correct behavior by temporarily switching to JavaSE-1.7 and then back. Evidently something got reset and all is well. While I'm happy that things are now working, I don't like being clueless as to how they got messed up in the first place.
Can anyone provide any insights into this?
I think general support relies on the presence of a src.zip in your JDK directory, which is detected when you autosearch a directory for Java installations. It could be missing. Not sure if online Javadocs are used.
I'm using Eclipse Juno on a Windows 7 64-bit (with a 32-bit JDK) but i think it will also apply to your Eclipse version:
Download JDK docs zip file to your Desktop folder;
Right-click on the file, choose Properties and unblock it;
Move the file to a location of your choice. I normally move it to the JDK folder;
Open Eclipse and go to Window->Preferences->Java->Installed JREs;
Select your JDK installation and press Edit;
Select the rt.jar file and click "Javadoc Location..." button;
Select the "Javadoc in archive" radio button;
Set the archive path by browsing to the JDK docs zip file;
Set the "Path within archive" to "docs/api" (without the quotes).
Enjoy! ;)
I have a problem with Netbeans simply not recognizing Javadocs in external libraries. I've gone into the library path and specified a valid javadoc path (Netbeans accepts the path without error). But even after re-building/opening closing Netbeans, I still get the "Javadoc not found" error for all items in the library.
I'm stuck on where to go since there is no error message, and I can browse the docs using a web-browser. Any ideas?
The version of NEtbeans is 6.5.1
The files are uncompressed in a directory that has been added to the the Javadoc tab of the properties for the library. The library works as expected.
I've tried clearing the Netbeans cache to no effect.
I got it working. I deleted the library, the re-created it added the Javadocs. Now it works perfectly.
Could you please be more specific: What is your version of NetBeans? Where are those javadocs located? Are they unpacked in a separate folder, in a zip file, in jar file?
Here is a working solution for NetBeans 6.5 for an example:
Go to Project Properties > Libraries dialog
On "Compile" tab press the "Add JAR/Folder" button and locate your library
On "Compile" tab press the "Edit" button with your library selected
Add path to either: a) docs folder of that library, containing index.html and the rest of the files; b) zip file, containing that libraries docs folder;
It should work without re-building your project or restarting NetBeans.
If you have created a custom library, it can be edited in a very similar fashion through "Tools > Libraries"
Sounds similar to a problem i had recently, turned out all i had to do was delete the cache to force NetBeans to rebuild.
If #slink84's suggestion fails to help, you might try #dr Hanibbal Lecter's method from my question on stackoverflow
I have a C project that is built using a makefile, Eclipse constantly warns about "Invalid project path: Duplicate path entries", but I cannot figure out what the hell it wants me to do. I would like to disable this warning and continue with my life.
My application compiles and runs fine, with not a single warning except this one. Being a conscientious developer I am keen to fix this problem so I have the warm fuzzies only a clean build can bring.
This worked for me with Eclipse 3.7.2 and CDT 8.0.2:
Open the project properties | C/C++ Build | Discovery Options.
Click the button by Clear discovered entries now:.
Rebuild.
It is seems to be a new feature in CDT 8. I have had this "Invalid project path: Duplicate path entries" problem for years, and this is apparently the newly provided solution.
Before doing this there were duplicate paths under C/C++ General | Paths and Symbols | Includes tab. I could not get rid of these. They only appear when Show built-in values is checked, so they are apparently generated somehow. After doing the above they were replaced with a set that did not have duplicates. The only difference is that the same settings appeared under Assembly, GNU C, and GNU C++. Previously they were different sets. The ones for Assembly were empty, for example.
So far the problem has not returned.
This problem is a real pain to deal with. It doesn't work very well.
This is applicable to Eclipse 3.4.1 / CDT 5.0.1
From what I can tell, when you create a "C/C++ Project" within CDT, it will try to auto-detect your include paths. Great idea, but the implementation is horrid.
If you delete or rename a directory, the old directory is leftover. If you rename the project, the old directory is leftover. When Eclipse can't find that old directory, it gives you that warning.
My solution is turning the automated discovery off entirely and managing my include paths manually. You need this list of include paths for things like ctrl-click (auto-navigate to defines/functions/files/etc) and shading out #define blocks. It builds the index off this list.
Here's what you need to do:
Right click on your project in the project explorer and go to properties.
Go to C/C++ Build -> Discovery Options
Uncheck "Automate discovery of paths and symbols"
Now go to C/C++ General -> Paths and Symbols
You'll see under the Includes tab Assembly, C and C++ languages with corresponding auto-discovered include directories.
Go to all 3 languages and delete everything.
Open your makefile and transcribe your includes into the corresponding language.
A project rename will still cause the indexer to break. ${project_name} and other globals do not seem to work. If you're having trouble, use the "Workspace" button to browse to the directory you want to include, as that seems to always work but entering it manually does NOT.
Hit apply, then OK.
Right click your project, go to index->rebuild
Restart eclipse.
This should fix things forever. Any time something improperly is shaded out due to a #define or #ifdef block, it's because that list of files is outdated. You'll also know that list is outdated if you get "unresolved inclusions" on #include lines.
Doug Schaefer, hopefully Google indexes this, you find your name, and you fix this awful implementation. =)
I found this bug report to help my problem. I had moved some include paths and couldn't get rid of the old paths.
I've seen this problem too, old paths
are never deleted. To manually fix the
file you need to move/delete the
${projectname}.sc file found under
${workspace}/.metadata/.plugins/org.eclipse.cdt.make.core
https://bugs.eclipse.org/bugs/show_bug.cgi?id=206372
Using Eclipse Luna and CDT 8.5
I fixed the issue by
Open the project properties | C/C++ General | Paths and Symbols
Look at the Source Location tab, I had renamed a directory and it was not updated in this list.
Rebuild
Here I just found another way to re-detect the path automatically:
Open "Workspace Settings-> C/C++ -> Build -> Settings -> Discovery"
Find "CDT Build-in Compiler Settings [Shard]"
Click "Clear Entries" and "Reset" button on the right
Rebuild projects and Done
Hope this will help.
Reference:
http://qing.blog.sina.com.cn/1802712302/6b7334ee33004def.html
It seems like a bug in CDT.
If you really want to get rid of it, you should try getting rid of the spaces in the project path; this was suggested in a search result for the error. If that doesn't work, you can try to open the .cproject file -it's where all the CDT settings lie- and check for an actual path with duplicate entries.
You should check if you have manually defined a symbol that eclipse can figure out from your makefile. I have a project that has a manually written makefile and the problem was solved by removing symbols that I had manually added to C/C++ General -> Paths and Symbols -> Symbols.
No needs to remove .metadata guys, just delete all path located in C/C++ General -> Paths and Symbols -> Symbols and replace them on using click buttom but don't give the path manually
Here's a late answer for Eclipse 4.4 (which does not have a Discovery option).
Delete the project's infoPath file. Eclipse or the ADT plugin (not sure which) will recreate it, and populate it with the correct paths.
You can find the project's infoPath file at <Eclipse workspace>/.metadata/.plugins/com.android.ide.eclipse.ndk/<project>.pathInfo.
I think Eclipse or the ADT plugin determines the new paths from two places: (1) the NDK directory set under Eclipse preferences, and (2) paths in Application.mk. All those paths become "Built-in" paths under Eclipse.
Also see How to change built-in C/C++ paths pointing to a deleted android-ndk-r9 installation?