While debugging a large scale project, I use links in the log printout to jump straight to the relevant file and line. Alas in many cases I get the following pop-up:
XXX is not a valid line number in YYY.java
On the main sub-window there's also the following message:
The JAR file M2_REPO\org\apache\...\some.jar has no source attachment.
Of course I checked that:
M2_REPO (defined under Window\Preferences\Java\Build Path\Classparth Variables) points to the maven repository correctly
the path and filename in the message above is correct and the file exists
YYY.java has line XXX and indeed it is the source of the log message
What could possibly make eclipse mistake in this trivial task?
What other configuration might be set wrong?
Press Ctrl+Shift+R and enter YYY.java. Eclipse will then tell you which YYY.java it can see. Chances are that it sees more or other source files than you expect.
If there is just a single file, make sure it's the correct version. Maybe Eclipse mixes a new bytecode JAR with an old source JAR.
The maven error message means that it's missing M2_REPO\org\apache\...\some-version-sources.jar This file must be in the same directory as some-version.jar for Eclipse to attach the sources to the binary JAR.
If you have the sources, copy it there. If you don't have them, there is a chance that Eclipse can download them for you. Open the context menu for the project -> Maven -> Download sources ... wait ...
I just experienced the same issue. I was using the apache tomcat debugger and had the following line in the output:
SERVER: 2015 Jul 05, 13:11:58.311 (http-nio-8080-exec-4) DEBUG - (ForwardActionBean.java:41) forward
Clicking on the link in the output window gave me the error "41 is not a valid line number in ForwardActionBean.java"
The problem was: I had two projects open and each had a class called ForwardActionBean
The solution was: remove the project I wasn't working on from eclipse.
Hope this helps the next person that comes across this issue.
Also, it's important to make sure line numbers are being generated by the compiler (this is the default behavior so it is probably not the source of the problem). This can be checked by selecting window->preferences->java->compiler
Just simply restore your java compiler settings to default and uninstall your any decompiler add-on in your Eclipse, and the problem is solved!
Related
I've filed a bug by now: 495662 - Source Lookup: Not seeing source code in the debug view.
My issue sounds familiar but it can't be since that issue appears to be fixed. However,
I have set a breakpoint in a class coming from a dependency (via maven). The source code got downloaded but as the program reaches the line all I get to see is
Source not found.
I've tried to add lookup paths by clicking at "Edit Source Lookup Path..." but nothing changed. I don't know what I have to add such that the debugger finds the sources.
It appears that this stopped working for all my dependencies.
How did I break my source lookups and how can I fix it?
Could be important:
I am running my tomcat from a maven build these goals:
tomcat7:run-war -am -pl mz-web-server -Denv=dev
but this hasn't been a problem so far.
Further, none of my maven dependencies e.g. gwt-user*.jar or `spring*.jar or anything are listed in the Source Lookup Path. There is only the "Default" path which doesn't contain it either - shouldn't those jars be somewhat listed there?
After downloading Eclipse Mars 2, removing my project completely and re-importing it without any .settings, .project or .classpath files, I am still seeing this problem. I can't tell if this is really an Eclipse bug but at this point I don't know what else it could be.
I also tried removing C:\Users\<username>\.eclipse and restarted the IDE without different results.
These are the included libraries under Maven Dependencies. As you can see e.g. spring-security-core-*.jar is included and the source is pointing to the local maven repository. Clicking on edit I see the full path C:/Users/Stefan/.m2/repository/org/springframework/security/spring-security-core/4.0.3.RELEASE/spring-security-core-4.0.3.RELEASE-sources.jar and yes, the file is really there.
My Classpath Variables:
I don't know what the actual problem was and why it stopped working. As you can take out of my question I actually downloaded a clean version of Eclipse, checked out the naked project and imported it with maven without results.
However, I found this com.ifedorenko.m2e.sourcelookup plugin. The link was provided in "Java Debugging: Source not found".
Go to Help > Install New Software .. and use
http://ifedorenko.github.com/m2e-extras/
to search for the links. After installing this plugin I was finally able to debug the source code of dependencies.
Tested for Eclipse Neon:
Press 'Edit Source lookup ...', press Add button for 'Java Classpath Variable' in dialog and choose M2_REPO variable and press 'Extend...'.
Then choose source jar file for wanted dependency from file system tree.
After that press 'OK' on all dialogs and relaunch debug process.
Eclipse keeps showing the splash screen and then closing immediately after...I just downloaded it so I haven't had the opportunity to make a work space. I've tried uninstalling and reinstalling, the file has already been unzipped at this point I have no idea as to what I should do about this.
Make sure that you have installed Java JDK properly
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
Whenever it (Eclipse) encounters a problem that does not warrant launching a dialog, Eclipse saves a report in the workspace log file. The log file can be looked at in four alternative ways.
Locate the file yourself, see workspace/.metadata/.log.
Start Eclipse using -consoleLog. This will print the messages
that normally go to the .log file in the enclosing shell/command window. When the Java VM suffers a hard crash, it produces a separate logging file named something like hs_err_pidXXXXX.log. These files are also helpful for diagnosing
problems.
(Other two might not be useful in your case)
Window > Show View > PDE Runtime > Error Log. This gives you a view
with the contents of the .log file.
Help > About Eclipse Platform > Configuration Details. This
prints out a great number of details about the environment and
also concatenates the .log file. Great for including in a bug
report.
Source
Make sure that Java installed properly..
Uninstall Java and install again, this worked for me
I have Eclipse Juno and Force.com IDE. When I try to create new classes they always show: failed to create the part's controls. It worked for the first time, but now they always show this. Same happens if I create them inside the force.com platform.
Error details:
org.eclipse.core.runtime.AssertionFailedException: assertion failed:
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
etc ...
I would appreciate all help.
I had the same error. I fixed it by switching the eclipse workspace. Go to menu File->Switch Workspace->Other, and then select the same workspace you were working with. Eclipse will restart and you should not get the error.
I faced the same issue my default editor for JSP was Web page editor. Which I changed to JSP editor and everything is fine.
PS: To change to JSP editor
Right click on JSP page -->open with jsp .
I got the "failed to create the part's controls" error one day when I opened Eclipse and tried to view a java file I had been working on. When I opened the file I needed, it showed a red X and NullPointerException instead of the code. The error log mentioned "event loop exception" for some reason.
I restarted Eclipse, and the error was still there. I cleaned the project, updated the project, deleted and re-imported the project, deleted and re-imported the file, and the error still was there. As a last resort, I restarted Eclipse again and then the file was fine. So one of the clean/update/delete/import steps worked but I don't know which one.
Use eclipse -clean from command prompt to solve this problem.
I solved my problem like this:
This problem occur because of in eclipse default editor is not able to identify extension of that file. If you right click on file and open it with respective text editor ,problem will be solved
In ecllipse, every file types has some associated default formats and one of the default format set to the particular file type.
You can see this in General -> Editors -> File Associations-
This issue generally occurs when we open any file in the format which is not the default format of the particular types.
I got same issue when I opened one of the Java file in text format in ecllipse and then I started getting the same issue. After research, I observed that AspectJ/Java Editor was setting as default. After reset it to Java Editor, the problem got resolved.
Steps :
1. General -> Editors -> File Associations-
2. Select the content type and choose the default format for it.
3. Restart the ecllipse.
In general, it is some default file format that set in ecllipse causing the same issue.
in my case problem was that the server was resin and I didn't have the resin server extension installed
I solved the problem.
(1)Open the filed with TXT.
(2)Search and Delete the underline between number like:
int a = 10_000;
It works when i compile and run as others used, but it will fail if i save and open again.
I also had for the same problem and fixed it by updating eclipse. Help > Check for Updates.
This worked for me---->
Right click on pom.xml-->open with-->xml editor
Had a similar stacktrace on failed to create the part's controls while trying to open Git repositories view in Git perspective.
My case (cause) is different since I was migrating an Eclipse workspace from an Ubuntu VM to Windows.
Many thing were copied like projects, .git folders, or also .metadata Eclipse folder.
Tried with no success:
uninstall all egit component (installation details, then, install new software
restart eclipse -clean
reset Git repository perspective
I searched and found this invalid UNIX : separator in .metadata\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.egit.core.prefs file.
GitRepositoriesView.GitDirectories=/path1/.git\:/path2/.git
Here, the : is invalid path separator on Windows.
I simply removed the value in this line, saved file, and restarted Eclipse:
GitRepositoriesView.GitDirectories=
(alternative: if needed, try to migrate those linux paths to their Windows equivalent too)
Git repositories view is back.
I have installed Eclipse Indigo for C/C++ Linux developers on Ubuntu 10.04 x86.
When I use common predefined macro __BASE_FILE__ Eclipse says Symbol '__BASE_FILE__' could not be resolved, but compilation is OK. I have to use it so often in my code and Eclipse fills my screen with red lines and bug icons :)
How can I fix this?
Not sure if this addresses your specific problem, but I also had semantic errors. They just came out of the blue after having a working project.
Anyway, I fixed it with a single option in workspace settings by setting:
"Build configuration for indexer: Use active build configuration"
The other option was "Use the build configuration specified in the project's indexer settings" and this is the one that wasn't working. I think it may have been corrupted after an eclipse crash.
Window -> Preferences -> C/C++ -> Code Analysis -> Syntax and Semantic Errors: OFF
This won't solve the cause of the problem but at least will stop the false errors from being shown.
The simplest solution is to reset the indexer:
Window / Preferences / C/C++ / Indexer.
uncheck "Enable indexer" ->>OK
rebuild all, may show lots of errors
check "Enable indexer" ->>OK
rebuild all
This error can be produced by forced closing of eclipse by power failure.
You need to rebuild the index of your project.
Right-click on the project, then Index->Rebuild.
Deleting the .metadata folder , and then Import project .
This way is OK!
Updated:
You have to add proper paths to Project->Propoerties->C/C++ General->Paths and Symbols. If it does not help, you can configure Eclipse Code Analyser (which generates the 'errors') in Project->Properties->C/C++ General->Code Analysis. Under the error description you have problem with, try Customize Selected->Scope->Exclusion Patterns.
IMO the correct solution is to define the symbol in Project -> Properties->C/C++ General -> Paths and Symbols -> Symbols tab. Since you can assume the symbol will always be supplied by the compiler, you just tell Eclipse to consider it defined.
I had the same problem just recently, where Eclipse complained about undefined macro, that i always supply using -D<MACRO_NAME> compiler option.
I think it has something to do with the workspace/.metadata.
I had the problem of semantic errors reported but Hello World compiles and runs.
I deleted the project, created another one, same error reporting. Reinstalled CDT, same thing. Deleted the workspace, shut down Eclipse, restarted, created new hello world, same thing. Deleted the workspace again, shut down Eclipse again, this time noticed that Eclipse had recreated the workspace folder during shutdown when it couldn't find it. Deleted the workspace with Eclipse shut down. Restarted Eclipse, created HW project, errors show for about a second and then gone. Deleted project, created another one, errors show for a sec, then poof.
If you actually had projects in your workspace (mine was a clean install), I bet that you could just delete the .metadata folder within the workspace, and it would fix it.
I personally agree with compostus' answer.
It's good to solve the real problem that eclipse's code analyzer have.
But when I try this steps:
define the symbol in Project -> Properties->C/C++ General -> Paths and Symbols
I don't find symbol tab or any place to add a symbol. what I want to do is putting macros like -DANDROID or #define ANDROID 1 to eclipse so that the code analyzer can find this definition.
I'm under Mac OSX mountain lion.
adding as another answer, hopefully this will help someone.
I have a ~simple workspace (1 c++ shared-object (linux's version of a DLL, 3 c++ executables, and a pydev python project)
I checked out all the code to a new machine, and it builds fine but had numerous 'semantic errors' on std-c and std-C++ code and includes.. I went through all the discovery / indexer setting to no avail.
==> deleting the entire .metadata folder fixed this.
Since i had nothing non-trivial set up in the workspace (all in the project files / makefiles), eclipse happily created a fresh workspace, and i simply had to do a file->import-> existing projects
If on Ubuntu, go to Window > Preferences > In Search box type "Indexer" > Select Indexer in left column.
Under heading "Indexer Options" tick the following options (all but those involving the skipping of files):
Index files source files not included in project
Index unused Headers Index all header variants
Index source and header files openend in editor
Allow heuristic resolution of includes
Under heading "Indexing Strategy" tick both options which are:
Automatically update the index
Update index immediately after every file-save
Under heading "Build Configuration for the indexer" select the following option:
User active build configuration
try this:
Preferences --> c/c++ --> Indexer --> Index all header variants
check this option.
This is a file indexing issue.
Solution - Right click on the project, Index->Freshen all files.
(Applies to Eclipse CDT.Oxygen)
In my case, I eventually discovered that the indexer was having problems because a colleague had “helpfully” duplicated a whole load of declarations in two header files that were only included together in a small subset of C files in the project. Removing the duplications (and making one header include the other) allowed the indexer to function correctly again.
It was particularly a problem with duplicated enumerations, for some reason. I do not know why this is so.
I used #pragma once in my code. This configuration caused me to have the problem:
---fileA.h---
#pragma once
#define MYMACRO(X) func(X)
---fileB.h---
#include "fileA.h"
---fileB.cpp---
#include "fileB.h"
MYMACRO(5) <---- warning here
I replaced #pragma once with #ifndef #define HEADER_FILE_H #endif, and that fixed the problem.
Not sure if this works for the OPs issue, but I had semantic errors in eclipse Luna and was able to resolve them by following instructions in this thread: Eclipse shows unresolved inclusion but it compiles
The compiler finds the header, but Eclipse not.
You could help Eclipse and set the path to the header files under:
Project -> Properties -> C/C++ Build -> Settings -> Compiler ->
Includes
In my situation, eclipse had determined one of my include directories, but did not determine that there were sub-include directories within it.
I had a similar issue but my compile was fine but Eclipse showed errors on lines that used a #define from another include file. I fixed by checking "Index all header variants". I think the classis #ifndef FILENAME in include file was process multiple times in Indexer and so 2nd time the FILENAME was defined so all #defines in .h file were not "seen" by the preprocessor. Go to Window | Preferences | C/C++ | Indexer.
I have the same problem. Compiler preprocesses ok, but static analyzer doesn't. In my source file:
#define PLATFORM_INC_FILES
#include <platform.h>
int coflags=O_BINARY; // Undefined symbol
In platform.h (an OS dependent header to help creating portable code):
#ifdef PLATFORM_INC_FILES
#include <stdio.h>
...
It looks like static analyzer doesn't take the .c #define statements into account when preprocessing included headers. By defining it at the symbols dialog, errors dissapear, but that is a project scope symbol definition, resulting in every source to include every system header in my case.
Hope it gets fixed soon...
Using Eclipse Mars and MinGW on MSIS2.
The problem occurs this way: I insert a new variable name into the code somewhere e.g. "newone" in this example:
int a;
foo()
{
a=17;
newone=23;
}
The file is saved (so the indexer is reindexing).
Then I added the definition:
int a, newone;
foo1()
{
newone=0;
}
foo()
{
a=17;
newone=23;
}
The indexer will still shows the error at the line " newone=23;" but not at the other lines of code containing "newone".
Solution: first define your variables, then use it.
M.
In the past, I would define the ANDROID symbol in:
Project -> Properties->C/C++ General -> Paths and Symbols -> #Symbols tab
However, the latest version of Eclipse no longer has a # Symbols there, or anywhere else.
It seems there is no longer any way of defining symbols in Eclipse.
Eclipse has so many bugs and problems.
I finally gave up and switched to using Gedit and the terminal to compile.
The obvious thing to do would be to:
Right-click on the folder that you wish to format.
Source > Format
Expected results:
- All java code in the directory and subdirectories are formatted (using the project specific formatting settings)
Actual results:
- None of the java is formatted.
While we're at it, how can we do a batch clean up operation in Eclipse?
From editor, I Right-click > Source > Clean Up, but I can only do one file at a time.
I faced the same issue. I had to switch to packaged Explorer to use the formatter. Under Navigator it does not work. Hope this help.
As mentioned in this thread, this (format all Java source files within a folder) should work since eclipse3.0.
Do you see some kind of error message in the "errors view" ?
I did exactly as you suggested you would like to do, and it did exactly what you suggested was expected. I selected Source | Format for a directory in my src tree and it reformatted all the units within.
EDIT: ...with 3.4.1 Ganymede.
If your code isn't checked out from source control or isn't writable, doing a group operation like this won't check them out or make them writable.
I have the same problem using SpringSource Tool Suite 2.5.1
I am using the package explorer
The project is in a SVN repository that is checked out
In the progress dialog I can see that only the XML files are modified
When I press Ctrl+Shift+F into a file, it gets reformatted (therefore is writable) but when after a reverse I do a right-click Source > Format on its folder nothing happens
I know it's been 2 years but I was wondering if #LES2 has found a workaround to correct this
EDIT :
Okay, despite I was really in the package explorer as written before, my java code was interpreted only as text files. I re-ran the full repository check-out of my project and a package-tree (squares for packages instead of folders) appeared giving me the ability to mass-format even Java files.