In NetBeans 6.7.1, I had a Java project in which I renamed some classes. After renaming them, the code completion showed the old names of the classes and not the new names. When I would build a project that depended on this project, I noticed it would even create the .class files for the old classes. If I deleted the renamed classes and created them from scratch, the issue persisted. I could find no references to the old names of the classes in my project folder using grep. I would also get runtime errors where I had code using the new class names. When I would build the project though, it was successful. What could be the issue?
After trying many different things, deleting my NetBeans cache folder and restarting NetBeans was the only remedy for the problem. On Windows, the cache folder is located at C:\Documents and Settings\USERNAME\.netbeans\6.7\var\cache. This seems to be a bug in NetBeans.
This bug seems to still exist in 7.1, same problem with old .class files and removing the cache folder fixed it
Related
My plan is to take an existing project and slowly transform it to something else. To this aim I took the brutal approach and simply copied the folder of the project as it was to a new folder.
When I ran sbt in the new folder, it resolved some dependencies and recompiled all the sources. This is kind of expected, because the project registry may have contained reference to the absolute path where the project resided earlier and sbt may have detected that it changed.
However when I went back to the old project folder, to which I made no modification and ran sbt in that folder, it recompiled all the sources as well in the original project.
This is a puzzle for me. Why did this happen? Is there a magic link between projects residing in different folders that I'm missing?
The simplest explantion might be that compilation was not up-to-date when you copied the original project. If that was the case, copying the project would have updated the file modified dates and triggered a recompilation for the new folder. Similarly, when going back to the old folder again, it would still be out-of-date, and sbt would recompile all sources again.
My problem is best described with a screenshot:
As you can see, there is a org.virtuslab:unicorn-core_2.11 dependency loaded in my SBT/Scala project. The jar file with corresponding sources is available as well. For some reason, Intellij Idea decided to ignore the available source file Table.scala and uses the .class file instead. Clearly, all other files are okay.
Obviously, without the information contained in the .scala file, Intellij is not able to properly analyze my code and I'm getting Cannot resolve symbol BaseIdRepository errors (and similar) all over my project.
I manually checked the source package and the Table.scala file is there and seems alright. Plus this worked flawlessly until two days ago. I don't know why it broke down. I tried to revert my project using git to an earlier version when this was still working, but no luck.
I tried to both downgrade and upgrade the library, I tried to remove it and add it again, I tried create a completely new project based on existing sources, but once again, no luck.
Just for the record, I'm able to compile and run my project. The only thing that might be related is this warning that I get when compiling the project:
[warn] /home/tobik/scala/payola-viz/src/app/model/appgen/repository/UsersRepository.scala:7: Could not find any member to link for "BaseIdRepository".
I got an update for the Scala plugin which seems to fix this issue.
In case you experience similar problems, this temporary solution worked for me: I added the unicorn sources directly to my code base and manually removed it from the project libraries. I got rid of the errors and it still compiles as the library remains as a dependency inside built.sbt. To avoid polluting my project, I added the included sources to .gitignore. The workaround broke after a while but all I had to do was repeat the procedure again.
I had a package structure which I changed, and this lead to the corresponding folders in /bin/ being removed, so now I get a ClassNotFoundException.
More specifically, I had the ususal /src/ and /bin/, and inside /src/ I had /main and /test, and this was presumably mirrored in /bin/. I shuffled the files around a bit and ended up with /main/model/ and /test/model/.
I have tried to manually create the corresponding folders (mirroring the packages in /src/), but this does not seem to help. I managed to compile the classes in one of the packages, but not in the test package, since it uses ScalaTest* and I didn't manage to compile the classes with the scalatest jar file (or something was wrong with the classpath).
So my question is:
How do I fix this within this peoject? (I don't want to simply create a new project and copy the source files over)
I'm guessing that I should learn more about build systems to be more resilient to such annoyances in the future? If so, what should I read up on, specifically to become better at troubleshooting and having more fine grained control over the build in the context of IDEs in the future (making builds independent of IDEs is not a priority for me at this point)?
An answer to one of these questions would be sufficient.
*All the source files are .scala files, if that might matter.
Udate
I did a clean of the project (project -> clean). This seemed to fix the problem: I was able to run the test classes from within Eclipse. All the binary files were in there, too. I made a new package, main.controller, with one class, and when I tried to run it, it said that it couldn't find the class. I tried to run the tests again, but those gave me a ClassNotFoundException, too. When I looked in /bin/ it turned out that all the folders and files were gone. I've tried to clean the project again but to no avail. I don't understand how I was able to clean the project, but now it can't fix it?
Update 2
To test if this was reproducible with a Java project, I made a Java project with two packages; main and test. I had the main class in main, which used a class from test (so there were dependencies across the packages). It ran succesfully. Then I added packages so that I had main.model and test.model and moved the corresponding files there. It also ran. Then I tried to delete all the files and folders in /bin/, and then the main class would not run. But if I did a clean of the project, then it cleaned it succesfully and the Main class was able to run. Then I made a Git repository for it, placing it outside of /workspace/ (in my git folder) and tried to do the same there. Eclipse was able to clean the project succesfully everytime.
So I don't understand why it can't manage to clean my Scala project.
I had errors in the "Problems" tab (Window -> Show View -> Problems). Now that I've made them go away, my /bin/ is correct and I can run both my Main class and my tests. This Question helped find out what the problem was:
Scala project won't compile in Eclipse; "Could not find the main class."
I have a maven project on eclipse with jrebel plugin installed. Hot-deploy used to work perfectly last week but now only xhtml pages are hot-deploy. When a java class is changed it doesn't hot deploy.
What I noticed is when I changed a file and save eclipse will automatically build it. But the output folder file is not updated base on file stamp that's why jrebel doesn't pick it up. When I run maven-install it compiles everything and all the java classes are reloaded which is not efficient.
So the main problem is eclipse newly compiled classes don't go to output folder (project/target/classes), even though it's set in Build Path.
Any idea?
By default, the content of your local Maven repository is cached for a day. This can happen even for bad downloads (as I experienced). See https://stackoverflow.com/a/7421893/44089 for a short description of how to work around that.
After several minutes of testing, I found a warning on a jar file specifically guava being downloaded as dependency. I've delete in repo to be redownloaded and after that jrebel is working again.
So the problem is a corrupted jar that causes everything to be rebuild even if only a single file is changed. But the weird part is there's no corrupted file error.
Ctrl+Shift+G used to find references to the current selection within ALL projects in my Workspace.
Now is seems to only return references within the current Project.
Details:
I have 3 projects in the same database. 1 project is common code. The other 2 projects include the source folder of the common code on the build path. I prefer to link to common source instead of including the common code as a Project on the build path because then when I deploy by exporting WAR each project has its own self-contained version of the common code.
However Ctrl+Shift+G seems to work when I include the common code as a Project. So it looks like I need to do both. I just don't know why the searching results have changed. I did install JBoss Tools and as a result of Jboss needed to install a newer version of Indigo.
Similar issue, but no good answer.
EDIT:
Open two editors with a common class file, one from the linked source folder and one for the actual project folder. When the Ctrl+Shift+G is performed on the linked source, only references with in the project containing the linked folder are found. Ctrl+Shift+G from the actual common project finds references to all projects in the workspace, when those projects have the common project referenced on the build path.
The problem is when I am in a project and I control click a common code method I am taken to the linked source class file. So then when I do a Ctrl+Shift+G on that method, I miss all the other projects that reference this common method, because the editor contains the file from the linked source. This never used behaved this way and used to find all projects that referenced this method regardless of which file (linked or actual) was used.
I find the command..It is
Ctrl+ALT +G // search through out workspace
not
Ctrl +shift +G // searching within class/project
And one tip
Ctrl+shift+L to see all commands in Eclipse
This can occur if you are using Maven and your version numbers do not match. I had a dependent project with <version>1.0.0.RELEASE</version> that was being referenced in another project as <version>1.0.0-SNAPSHOT</version>. Fixing the mismatch so that versions were correct allowed CTRL-SHIFT-G to find the references in the workspace that it could not find before.