What does the red exclamation point icon in Eclipse mean? There are lots of different search results on the Internet about "red exclamation point icons" and "red exclamation mark decorators" and "red bang icons," no doubt because lots of plugins and programming-related tools use red exclamation point icons. So, to be clear, this is the one I mean:
It appears as a decorator on projects in the Package Explorer view.
In my case, the icon went away when a missing build path variable was filled in. I'm using MyEclipse 9.0, but I don't think this is MyEclipse-specific. Other people on the Internet have reported that it has to do with other issues, including Subclipse, the .svn folder and moving files between working copies.
According to the documentation:
Decorates Java projects and working
sets that contain build path errors
In practice, I've found that a "build path error" may be caused by any number of reasons, depending on what plugins are active. Check the "Problems" view for more information.
It means there is a problem with the build path in your project. If it is an android project then it mostly means the target value specified in project.properties file cannot be found. This can also be caused because of other kinds of built problems. But it is shown mostly for built problems only. See here for more details. It is about built error decorater seen in eclipse.
An extract from that page:
Build path problems are sometimes easy to miss among other problems in a project. The Package Explorer and Project Explorer views now show a new decorator on Java projects and working sets that contain build path errors:
The concrete errors can be seen in the Problems view, and if you open the view menu and select Group By > Java Problem Type, they all show up in the Build Path category:
I also faced a similar problem when i tried to import Source file and JAR file from one machine to another machine. The path of the JAR was different on new machine compared to old machine. I resolved it as belows
Right click on the "Project name"
Select "Build path"
Then select "Configure Build Path"
Click on "Libraries"
Remove all the libraries which were referring to old path
Then, the exclamation symbol on the "Project name" was removed.
There can be several reasons. Most of the times it may be some of the below reasons ,
You have deleted some of the .jar files from your /lib folder
You have added new .jar files
you have added new .jar files which may be conflict with others
So what to do is we have to resolve those missing / updating / newly_added jar files.
right click on the project and go to properties
Select Java Build Path
go to the Libraries tab
Remove the jar file references which you have removed already. There will be a red mark near them so you can identify them easily.
Add the references to the newly added .jar files by using Add JARs
Refresh the project
This will solve the problem if it's because one of the above reasons.
I found another scenario in which the red exclamation mark might appear. I copied a directory from one project to another. This directory included a hidden .svn directory (the original project had been committed to version control). When I checked my new project into SVN, the copied directory still contained the old SVN information, incorrectly identifying itself as an element in its original project.
I discovered the problem by looking at the Properties for the directory, selecting SVN Info, and reviewing the Resource URL. I fixed the problem by deleting the hidden .svn directory for my copied directory and refreshing my project. The red exclamation mark disappeared, and I was able to check in the directory and its contents correctly.
What I did was peculiar but somehow it fixed the problem. Pick any project and perform a fake edit of the build.properties file (e.g., add and remove a space and then save the file). Clean and rebuild the projects in your workspace.
Hope this solve some of your problems.
Make sure you don't have any undefined classpath variables (like M2_REPO).
I had the same problem and Andrew is correct. Check your classpath variable "M2_REPO". It probably points to an invalid location of your local maven repo.
In my case I was using mvn eclipse:eclipse on the command line and this plugin was setting the M2_REPO classpath variable. Eclipse couldn't find my maven settings.xml in my home directory and as a result was incorrectly the M2_REPO classpath variable. My solution was to restart eclipse and it picked up my settings.xml and removed the red exclamation on my projects.
I got some more information from this guy:
http://www.mkyong.com/maven/how-to-configure-m2_repo-variable-in-eclipse-ide/
The solution that worked for me is the following one given by Steve Hansen Smythe. I am just pasting it here. Thanks Steve.
"I found another scenario in which the red exclamation mark might appear. I copied a directory from one project to another. This directory included a hidden .svn directory (the original project had been committed to version control). When I checked my new project into SVN, the copied directory still contained the old SVN information, incorrectly identifying itself as an element in its original project.
I discovered the problem by looking at the Properties for the directory, selecting SVN Info, and reviewing the Resource URL. I fixed the problem by deleting the hidden .svn directory for my copied directory and refreshing my project. The red exclamation mark disappeared, and I was able to check in the directory and its contents correctly."
Also be sure you dont have any closed project in the Projects tab ->
https://i.stack.imgur.com/StGEu.png
The solution that worked for me is the following one given..
I selected the particular project> right click >Build path>configure Build path> Libraries> I noticed that JRE system Library was showing(Unbound) hence..
selected that Library>click on Remove>click on Apply>click on add Library>JRE system Library>next>workspace default JRE>click on Finish>Apply>ok.
now you will not see these exclamation icon in your project.
Related
I hope it's OK to ask this here. Netbeans forums isn't responding. If not, I'll delete this or ask for it to be deleted. I'm desperate so I'll face the wrath, if any.
I moved my Netbeans projects folder from one directory node to another to make backing up all my stuff easier. BAD MOVE.
Now when I open a project using Files | Open project (ctrl-shift-O) NO source files appear because there is no "+Source Packages" node to expand.
It looks like this for all projects, e.g. one named GBL:
Projects
-GBL
+Libraries
It doesn't look like this anymore:
Projects
-GBL
+Source Packages (How do I get this back?)
+Libraries
The Netbeans Properties for each project shows me the path it's using. Windows 7 Explorer shows me that the src, build, and nbproject folders contain files and ALL the source files are in the src folder for that path.
What have I done and more importantly what should I do to get back to being able to open a project normally?
(I've tried recreating the original Netbeans folder and using Windows Explorer to copy an entire project folder into it but: same result--all I see is the Libraries node under the project's name node.)
I just tried to Clean (and also Build) to see what would happen. Error:
ant -f C:\\Users\\Dov\\Documents\\NetBeansProjects\\BasicShirt -Dnb.internal.action.name=build jar
C:\Users\Dov\Documents\NetBeansProjects\BasicShirt\nbproject\build-impl.xml:[u]231[/u]:
Must set src.dir
I just Set Configuration by right-clicking the project's name and provided a path to the src folder.
NOW I SEE MY SOURCE FILES BUT NOW THIS line in the .xml file is flagged with similar message:
<fail unless="[u][b]test[/b][/u].src.dir">Must set test.src.dir</fail>
NOW what do I do? (Netbeans 7.4.)
If I could get rid of the 7.4 automatic creation of +Test Packages, I might be OK.
If you can help, I'd be very happy.
(I'm considering re-installing 7.3 if available or removing and reinstalling 7.4 and try to avoid the "testing" requirement, but there goes all my many tweaks of 7.4.)
Well, after considerable frustration with the problem, I solved it, essentially.
It's here, in total. My synopsis plus how it helped me follows. In short, I had to set up a new java project based on existing sources using the New Project Wiz and simply direct Netbeans to the sources.
File > New Project
Choose Java Project with Existing Sources.
Type a (new) project name and ...
... make the Project Folder contains the path to where you want the new project to be stored. (For me, this is the folder where Netbeans has been able to find my sources.)
Click Next for the Existing Sources page of the wizard and ...
5a. ... in the Source Packages Folder pane, click Add Folder and ...
5b. ... navigate to your sources and select the source root folder.
Clicking Next goes to the Includes/Excludes pane, which I didn't need to use.
I am using eclipse 4.2 and Subclipse 1.8.20.
I am trying to add the contents of /WebContent/WEB-INF/classes to version control (this is also the default output folder of my project).
First let me state that this is possible with TortoiseSVN. I do understand why by default Subclipse ignores this directory, and I tried to change the Team settings, but I am not seeing a relevant entry for *.class files:
Is this at all possible with Subclipse?
More info:
Old an unanswered similar question: http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=473163
Same topic but opposite question: How can I ignore build directory in Subclipse?
It is a horribly bad idea to version your build directory. Every time Eclipse does an auto-build it will cause all of the files to need to be committed again.
To answer your question, all Eclipse team providers automatically ignore any resource that is marked as "Derived" by Eclipse. The Derived flag is set on files that are created by the Eclipse builders. If you select one of these files that are ignored in Eclipse, right click and choose Properties. Navigate to the Eclipse Resource page. There will be a bunch of checkboxes. You should see that one of these is labelled Derived and will likely be checked.
Do not try to change the checkbox value. I am just pointing out where you can see and confirm this.
In my project there is a symlink to a folder from another project.
The name of this folder is in .cvsignore
But this folder (symlink) contains cvs metadata (CVS folders) from the other project.
The cvs command has no problem with this and ignores the folder.
But eclipse wants to synchronize it.
The question is, can ecplise ignore a folder at synchronize time, or how to make eclipse respect .cvsignore files?
the folder (symlink) name is shared and in my .cvsignore contains a line with it's name
We use the symlink trick to share sources between our software and its plugins which are built separately (separate autotools projects).
The issue here is an explicitly shared folder overriding the .cvsignore entry.
You can find the exact details as explained by the previous Eclipse CVS component lead within bug 169710. This bug is marked as a duplicate of another defect which is still open, meaning this is a known issue.
As Michael pointed out, your choice is to use an Eclipse link for development:
Add new folder to Eclipse project
Select Advanced > Link to alternate location (Linked Folder)
Select the workspace variable (i.e. WORKSPACE_LOC) and point to the other project on your workspace (i.e. WORKSPACE_LOC/other_project/foo)
This will get you a linked resource that developers don't have to worry about mistakenly checking-in. For your automated builds you'll need an extra post-checkout step where you create the symlink.
This is not ideal but it's a sensible alternative, short of fixing the Eclipse issue.
I've used Clint Harris' tutorial to set up code sharing between projects, and everything works just as expected on my computer. But on my co-worker's machine, it seems the compiler doesn't find the header file from the static library project when he builds.
My co-worker got my project by cloning a git repository. We've gone through all relevant build flags and XCode settings n times, but the project simply refuses to compile on his machine.
This is what I asked my co-worker to do, mostly copied and pasted from the tutorial:
Make sure there is NO blank space in the complete path to the projects' directory.
Inside the projects directory, create another folder called "build_output".
In XCode, under “XCode > Preferences" choose the "Building” tab and set “Place Build Projects in” to “Customized location” and specify the path to the common build directory you created.
Set “Place Intermediate Build Files in” to “With build products.”
Choose the “Source Trees” tab and create a new Source Tree variable by clicking on the “+” button and filling in the columns. In both "Setting Name" and "Display Name", put
[the name of the shared project which created the static library]. In path, you put the full path to the framework folder.
Following these steps, the project that uses the static library should compile the same on his machine as on mine. But it doesn't. Basically, the error he gets is:
error: TheFrameworkHeader.h: No such file or directory
and then a string of other errors caused by the missing header.
Any strategies for trouble-shooting this? Or anyone who had a similar experience and could share some hard-earned knowledge? Is anything missing from the instructions I've summarized? Do I need to set the roles of headers in the Copy Headers build phase when compiling a static library?
Despite some helpful advice, I never figured this one out, but here's a little info for anyone in a similar situation. I created the library and dependent project by splitting an original project into two. At first, the library and application were just two targets within the same project. Later, I moved the app to a separate project. Everything seemed to work, and I pushed both projects to remote git repositories. When these were cloned on other computers, however, the library headers were not found.
Later, I discover that the same error occurred when I cloned the projects on the original computer. After a lot of struggle, I pinned it down to one scary detail: the name of the dependent project's folder! (That is, the project with the application, not the library.) Not the name of the .xcodeproject package, not the application identifier, but the name of the containing folder. As soon as I change that, everything works. If I change it back to the original name (on any computer), again the headers are not found.
If anyone has any insight on this, please post an answer!
EDIT: Since I posted this, the same problem occured with another project, and again, merely renaming the folder that contains the .xcodeproject folder fixed the problem.
I don't think it is Git, I think it's xcode. I got a very similar problem here, where xcode / xcodebuild resolves an include path falsely (making it a simple .) With the exactly the same library project and xcconfig files (clean checkout from svn repo) but another containing folder - it works. So, thanx for the solution and don't blame Git anymore ;-)
I often forget to check this: are you sure that the missing file (i.e., TheFrameWorkHeader.h" is in the git repository? It may well be that your build settings are correct, but the file somehow did not get added to git correctly.
If you're having trouble building on a particular machine, then the problem likely is a machine or user setting. Such as an environment variable (perhaps INCLUDE_PATH or one of its relatives -- XCode uses GCC). You may have a "." in one of these variables.
The best way to fix this would be to add the needed folder path to the -I switch in the build script.
Double check that the "Search Paths->User Header Search Paths" build setting (for all configurations) points to the directory containing the shared Xcode project (you can use the new Source Tree variable you created).
I have a rather large project which contains a number of third-party dependencies which are linked via svn:externals. These include tomcat and blazeDS, which are packaged by our installer via ant. The problem is that these projects contain dozens of sample JSP pages, and eclipse chokes on them when trying to build the project, producing hundreds of errors.
Our project setup is something like this:
src/
main/
test/
third-party/
blazeDS/
tomcat/
etc.
Now, in eclipse, my project's build path is set to only include subfolders in src/main and src/test. Yet, for some reason, it still tries to build everything beneath third-party. I have clicked on third-party and selected "remove from build path", but this had no effect. I even tried adding the third-party folder to the build path, and then excluding "", "/*", and "**/*.jsp", but again, to no effect.
What is going on here?
Edit: Thanks for the suggestions, though unfortunately, they don't seem to fix the issue. I don't have the CheckStyle plugin installed (I'm using Eclipse 3.4.1 with the only custom plugins being subclipse and flex builder), and I tried disabling all extra builders except for Java, but the errors are still being thrown.
I usually have this kind of issue with CheckStyle plugin, where you need to specify in its properties (right-click on project -> Properties -> CheckStyle):
"Exclude from check Files non located in a source directory"
Otherwise it does analyze (and reports warning/errors on) files which are not candidate to be compiled in the first place.
Couple of other suggestions:
try restarting your eclipse with the -clean option (eclipse software version of 'did you reboot it ?' ;) ). Beware it can reset your workspace perspectives, so you may want to try that with a copy of your workspace instead.
try deleting your project (your workspace reference of your project, not its actual content), and reimporting it (beware of your custom launchers, they may get removed in the process).
check if you do not have any linked directory within src or test, which would point to thirdparty(/**): that would explain the unwanted compilation.
It could be that your eclipse project is configured to have extra Builders. You can check that in the project's properties (right-click on project -> Properties -> Builders).
In my case it was because there was a reference to the file (which I had excluded from the build path) in another file which was in the build path. I wanted to exclude SegModel.hpp from the build path, but in another file, I had specified template short K::KEstimate<SegModel>(SegModel& m, short stepCode);