On different dev machines (some Win, some Mac) my JREs are in different places. On my Mac, every time I fetch or switch branches I seem to have to reset my JRE paths to System default from an explicit JDK version. Where is this information stored and how do I keep this out of git, or deal with it in a better fashion?
That information, when specified on a project level, is stored in the .classpath file. You should either tell git to ignore that file (it's quite common to ignore "dot resource" files) or you should change the classpath file to use the default JVM.
Do the latter by selecting the project and selecting "Build Path -> Configure Build Path" in the context menu. Go to the Libraries tab, select the JVM listed and click "remove". Next click on "Add Library..." and choose "JRE System Library". After clicking "Next" choose the default JVM and click "OK".
One more related comment. If you were to use maven, a lot of these build configuration issues would go away. Of course, there's a bit of a learning curve cost to that, too.
Related
we have started a project versioned with ClearCase (sadly).
We also use Maven and ClearCase eclipse plug-in. Each time I build a project, a popup shows up (which says Add items in target folder to source control) and drives me mad. It pauses the build process so I have to check frequently to resume process.
Is there a way to ignore and unversion this folder like with SVN? I've added target folder to ignored sources on eclipse but pop-up still appears
If you are referring to the "Add Elements to Source Control" dialog box:
(Source: "Using ClearCase with Rational Performance Tester")
The workaround is:
On the main menu, click Windows > Preferences.
In the left pane, expand Team and then select ClearCase SCM Adapter
Change the preference for When new resources are added to Do nothing (from the default value of Prompt to add to source control).
I have a C/C++ project which has some normal and some linked/virtual folders and it has been building just fine. Now that I've put it into perforce over VPN (the path of which I cannot modify), there is an ampersand in the path of the project that causes eclipse to fail when it gets to building the files in the linked folders (it appears eclipse builds an entire pathname for linked folder's files from the environment variables and passes that to the gnu compiler). I don't know if Perforce allows aliasing of workspaces (to get rid of the ampersand) but I can't find one. I've tried alt root but that doesn't seem to do anything useful. I've found that using the DOS command prompt subst F:
C:\perforce\pathwithampersand will allow the project to build in eclipse but now I loose the ability to utilize the Perforce plugin features. Although I can still manually check files in/out using the P4 client, it would be very useful if the ampersand problem was taken care of by eclipse. I've searched and searched but can't find anything about eclipse having a problem (or solution) with ampersand in the folder path. I'm using eclipse platform 4.2.1 and CDT 8.1.1 but cannot update to any later version(s) than those because they are part of a tool suite a vendor controls. Perforce plugin is 2013.1/server is 2009.1.
Go to the P4 Client Connection->Edit Current Workspace
Expand the depot tree until you see your project. Right mouse click on it and choose Include Special.
Click Files radio button and click the Save button.
That will cause a path name to be displayed next to your project under Client Expression. Click to the right of this path which will cause it to become editable. Cursor over to the part that includes the ampersand and delete it. Click the OK button.
P4 will then (eventually) ask if you want to update files to the new location (or something like that). Choose update and it will take some time to create the new folder and move the files there. It is unclear whether you need to log out of P4 for it to be completely enforced so the best solution is to do so (Connection->Log Off). It might leave the old directory so you can delete it at will and it will not appear the next time you start P4.
Some users found this sequence did not work this way so they had to click the "View workspace mapping as text" button on the workspace edit dialog and delete the ampersand. Click apply.
I am using a quite large project in Eclipse, composed by different libraries which can be build independently thanks to dedicated "Make Target" elements.
When compiling one of this libraries, the compilation works fine, but afterwards, Eclipse keeps busy by doing "Building Targets. Updating projects..." (as named in the Progress View). As my project is rather large, this action takes several minutes, preventing me to start new compilations or change Eclipse settings.
Is there any way to disable this automatic update in Eclipse?
I have observed this behaviour in Eclipse Helios and Eclipse Juno.
I have tried to remove my "Make target" objects, and give an invalid C/C++ Build configuration (e.g., provide an invalid make command).
As expected, when building the project, Eclipse tries to execute the invalid make command (which fails), but then keeps doing this "Updating projects..." anyway...
After build Eclipse is looking for newly created executables. If your project is Makefile-based Eclipse cannot be sure where to search and browses the whole source tree.
Assuming your executable are all go into a folder bin-XXX, you can reduce these searches as following:
Select the top project (say "src") and go to the right-menu dialog “Properties” (alternatively: top menu Project-Properties). Then go to “C++ build”-“Refresh policy”. Here select the folder “src” and press “Add Exception”. Then add all folders except “bin-XXX” as an exception.
Select the top project “src” and go to the right-menu dialog “Properties” (alternatively: top menu Project-Properties). Then go to “C++ General – Paths and Symbols – Output Location”. Add folder “bin-XXX” and remove the folder “src”
I set my java runtime options in Eclipse's Window > Prefs > Java > Installed JREs > Default VM Arguments. Since this setting is sufficient for all my main() entry points, I do not bother with customizing the "run configurations". It looks like nice flexibility but I probably will never need it. I was worried that I would have to repeat my VM arguments in the run configurations and so I started to copy my VM arguments but after an experiment it seems that I do not have to. Now I will have the opposite worry that I have some unintended customizations.
To eliminate the second worry, is there a way to eliminate the clutter visible in the Run drop down menu? What about the "Launch configurations" visible in the JAR export dialog? Is a run configuration the same thing as a launch configuration? How do I eliminate the multiple launch configurations?
I am on Eclipse Indigo on Ubuntu.
Edit After I manually delete all the run configurations, and proceed to do an export, buttons are greyed-out so I can't proceed. When I select the launch configuration drop-down, I end up with only one choice, from an unrelated project. I then created a run configuration for the real main entry point for the current project. I expect the clutter will return as I continue to use Eclipse.
One simple way would be to organize your projects by Eclipse workspace, which would limit the "run configurations" list only to the project referenced in a given workspace.
Switching workspaces would reset that list to the ones recorded for the projects of the new workspace.
Note: the OP's answer regarding launches file location isn't the only location possible.
The official one is:
${WORKSPACE}/.metadata/.plugins/org.eclipse.debug.core/.launches
But you can copy them enywhere else you want (as explained in "How do I save Eclipse launch profiles across workspaces?"), either by manually copying those files or by sharing them:
See "Which eclipse files belong under Version Control".
Once you know where they are saved, a simple delete is enough to make them disappear from the launcher menu.
The answer comes from #Francisco Puga
Experimental evidence shows that deleting "launches" seems to make run configurations disappear so it would seem that they might be synonymous.
I have configured some VM arguments inside the Debug Configuration. However, these settings are saved in .metadata\.plugins\org.eclipse.debug.core\.launches\Program.launch, which is outside the version control. Indeed, the whole .metadata folder is.
But this is something I wish to be shared amongst all the devs working on the project. In other words, I want per project Debug/Run Configuration.
Is it possible?
The launcher (.launch file) can be stored outside of .metadata: go to "Run → Run Configurations...", choose your launcher, and in its "Common" tab choose "Save as: Shared file". This will save the .launch file in the chosen folder, and then it can be committed to your version control system.