Symptoms: Large C++ project; I have an extraneous .cpp file in a common directory, listed in a logical subfolder, that I want to remove from the project but not delete on the disk. I right-click on the filename in the projects directory, and select Remove From Project in the popup menu. The name of the file disappears from the Project listing.
However, the .o and .o.d files are not erased from disk; neither is the file listing removed from the project's various netbeans config and Makefiles, etc.
Round 1: Hammer-button recompile. The old .o is still included, and compile fails with its unmet dependencies.
Round 2: Broom-button erase all .o's and recompile. It's still included.
Same effect if I Remove a folder.
Again: File does not appear in the Project table of contents, but is still quietly bound in, causing bloat and unneeded dependencies.
I'm having to go in and update each config and Makefile etc. manually. Is this a known bug? Any workarounds?
Related
I use Eclipse and manually moved my workspace (cut and paste) from /home/user/workspace to /home/user/somefolder/workspace.
I rebooted Eclipse and I get build path errors. I open up the build path of one of the projects with this error and see Build path entry is missing: home/user/workspace/SomeProject/lib/cloning-1.9.0.jar.
This is clearly a bug in eclipse since I told it where my new workspace was located when i rebooted. How do I fix this (without doing it manually for one Jar since it's an error with many).
This can happen if you added it to a Java Buildpath as an External jar--it then recorded on the on-disk location rather than the in-workspace path. The Java Build Path is stored in the .classpath files in each project. If necessary, you can use Search->File to do a search and replace.
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.
Gradle creates a folder called .gradle. Should I track it with my version control (i.e. git)?
More importantly, why / why not?
Should I track the .gradle directory?
No. It can safely be ignored.
Why should I ignore it?
It's purely for caching information, you don't want it in your repo because:
it can get big and be full of binary files
there can be machine specific data in there
there's a lot of churn in there (you'd be constantly committing changes to files in there)
everything in there can be completely re-generated whenever it is needed anyway
It's basically a temp directory that Gradle is dropping in the middle of your source code (why Gradle thinks that's an appropriate thing to do is a different question).
You can tell the "cache directory" nature of the directory by the name of the switch that lets you change where it goes: "--project-cache-dir".
Though I hate having binary files in my source tree, I usually just end up adding the directory to my ignore file because somewhere along the line I'll forget to use the switch from some command line or from my IDE or something and then end up having to deal with the directory anyway.
How do I ignore it?
Git users can add a line with just .gradle to the .gitgnore file and Git will ignore all files in any directory with that name.
Mercurial users will want to look up the .hgignore file.
For other version control systems, refer to the documentation - they all have a feature to support this.
The .gradle folder contains different calculated information about your gradle build (e.g. cached outputs/input information). You definitely shouldn't check that folder into your version control system.
I was new to Gradle and thought that the .gradle folder will contain generic information such as dependency mappings, etc and uploaded it on version control. I then tried setting up a new machine with a different OS flavor and Java version using code from the version control including the .gradle folder and ran into errors. Turned out that the .gradle folder contains machine specific information and is used for caching on local.
Do not include the .gradle folder in version control and try setting up a new machine with the code, the gradle daemon will do the rest.
You don't need to keep the .gradle folder.
Because once you execute gradle build command again, you can make almost the same .gradle folder again.
But when you use the gradle.setting file under .gradle you might need to move it to root folder of the project.
when we start the gradle it create the .gradle folder inside your home directory. It consist of native (information about your system) and caches. Caches further consist of plugins and all other jars dependencies.
When we build the the project first time at that time it download dependencies and plugins and cheched them here. next time when we need them it, it get from here. even when we need them in eclipse to compile the code (=>gradle eclipse), its dependencies are added from cache
As it will keep updating and adding when you run gradle. so i guess we do not added it to version control.
I have lost files mysteriously a few times from my Eclipse workspace folder, and previously I assumed that I must have deleted them, but this time I know for sure that I didn't.
I entered a folder for a Java project. I listed the files. There were several text files. I then opened one in gedit to look at it. As far as I remember, I then did something in libreoffice Calc (to a spreadsheet file in a completely separate location), then I made some changes to the Java file in Eclipse. It would then have been automatically compiled. I then went back to the terminal to execute the program, but it wouldn't run. Listing the files shows that the reason it wouldn't run is that all the text files have disappeared and so has one of the .jar files (called stanford-parser.jar) but not another. I've searched my computer for these files and I can confirm they've gone.
A screenshot from my terminal illustrates this.
Can anyone help me to understand how this is happened, so I can avoid it happening again? Could compilation delete the files?
You seem to be storing source files in the bin directory of your Eclipse project, which is probably the target directory used by Eclipse to put the compiled classes. Store your sources in the source folder. The target folder is completeley deleted by Eclipse each time the project is cleaned up.
Note that non .java files stored in the source directory are automatically copied to the target directory by Eclipse. They're considered as resources that must be available at runtime in the compiled application.
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);