I am always the first one to jump on any latest Eclipse release thinking that it would solve some of the issue that i have with slowness but i am always disappointed. The DLTK thing that keeps running, memory heap issues, internal error occurred ....
The latest version that I have tried is KEPLER
I know that I can close the projects that i am not using, disable validation, remove projects from the build path, hack into their myriad of codes and change settings but really?
I have to admit my workspace has only 5 projects but more than TWO HUNDRED heavy duty folders. within those folders you have for example, Drupal, Wordpress and so on..
I have used visual studio for years with 5 times as much projects without this kind of slowness but that is besides the point. Let's go back to eclipse.
looking at my settings, some people might say: why don't you create a projects for each of those folders? I tried that but the DLTK indexer keeps on indexing every projects in my workspace unless i close them. WOW!!! Create multiple workspace is out of the questions, if i have to do that i will just ignore Eclipse all together.
My hardware is decent and I have SSD Drive and plenty of RAMs.
What is the largest amount of projects or files can Eclipse safely handle? What about the DLTK what are its limitations?
How large is too large?
What doesn't visual studio seem to suffer from the same slowness? Is the problem java related or with the data structure? Can Eclipse handle that amount of projects?
I know that there are a lot of moving parts and answering these questions is not black and white but why is this thing indexing even the stuffs that i am not using?
I would like to get some opinions on how to use this editor effectively?
While the number of projects/files is not exactly "limited" (beside the resources of the host machine), the number of open editors is.
Eclipse 2019-09 proposes by default 99.
Close editors automatically when reaching 99 open editors
The preference to close editors automatically is now enabled by default.
It will be triggered when you have opened 99 files.
If you continue to open editors, old editors will be closed to protect you from performance problems.
You can modify this setting in the Preferences dialog via the General > Editors > Close editors automatically preference.
IDEs are slow by nature because they do a lot.
I would never use eclipse for webdev stuff like wordpress.
You should be leaving your library files outside of your main project as external folders so that eclipse discounts them. That way you can just have the files you need in your workspace.
Also, try closing the projects you aren't working on by right clicking and choosing "close project"
Personally I use vim and FTP to handle this stuff. Eclipse is nice and integrated but very chunky.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Clone workspace in eclipse
I started a new workspace a couple of weeks ago, and configured eclipse ( Window -> Preferences ). I configured alot of stuff, hotkeys and so on.
Now I have started a new Workspace, but none of the old settings are available.
Is there a way to configure global preferences for eclipse?
I know I can export/import preferences but I have some doubts if that actually takes all of the preferences. Previous experience has told me no, plus it is inconvient as one change in one workspace won't get updated in another and you have this constant non-synchronized properties.
Thank you !
You can have a look at the following plugin : https://github.com/alfsch/workspacemechanic
It's a plugin developed by google which lets you store your preferences and apply them to any workspace automatically.
If you store it in your dropbox (or any other shared storage), you'll be able to share you preferences between all your computers and even between all your team members.
It's the best and most reliable solution for your problem.
No, that´s not possible. All settings are done per workspace.
I write code in several languages (Python, C, C++, and Java) using Eclipse. Is it possible to designate a directory on my machine (say /home/workspace/) as the "primary" workspace for any Eclipse session, but then to have subfolders, /home/workspace/python, /home/workspace/java, etc., in which I can create new Eclipse projects.
I don't want to have to navigate menus and select different workspaces for each session of Eclipse that I start up. I would rather just always have permission to manipulate any projects from a variety of folders at any time, but I can't find a clear answer about whether this can be done and how to do it.
As I understand your question; You want to have one workspace, but be able to code in several different languages without switching workspace but at the same time keep the projects separated?
First I would suggest you consider several workspaces, I find it convenient to keep settings and projects in separate workspaces. I rarely have to switch language that often.
But. I think what you want to do is to keep several working sets. You create one java working set, one C++ set and associate your different projects with a working set. Then you can minimize the java working set when you are running C++. For working sets you dont need any subfolders on the harddrive.
You might also want to look into Mylyn. Its a great tool for those who often are switching context. It saves the context (eclipse perspective, open files, etc) as associated with a task.
How about setting Eclipse to prompt for the workspace at launch? It wouldn't allow you to work in two languages at once, but should do the trick otherwise.
An Eclipse workspace can contain projects slated for different languages and those projects can live anywhere on your hard drive. There are at least two ways to do what you want. When creating a new project, uncheck the Use default location checkbox and browse to or specify the folder where you want your project to live. If a project already exists import the project into the workspace using the File->Import menu option and then select Existing Projects into workspace. In the next screen make sure the checkbox for Copy projects into workspace is not selected. This will leave the source files in the original folder.
In the Project explorer view, all the projects are going to look like they live at the root level. However you can group related projects into working sets. Then select just the working set you're interested in and all the others will disappear from view.
A warning is in order if you make use of eclipse variables in external tools (and possibly elsewhere). The syntax you use for paths needs to be adjusted. For example with projects outside the workspace this syntax ${workspace_loc:/MyProject/MyFile.txt} is no longer the same as this syntax ${workspace_loc}/MyProject/MyFile.txt
I have a similar problem to this guy: Importing/Exporting Project Preferences, but my problem is worse, I need to create a new workspace (i.e. new base directory) for every program or version that I work on. I have some common preferences (formatter, font size, etc) that I have exported to a file, which I then import every time I create a new workspace, but would like to skip the step of manually importing the .epf file. Has anybody seen an easy way to automate this?
EDIT: to help potential respondents answer the question, here is my workflow for handling a bug patch. Perhaps I'm doing something wrong in general that you could correct (since I've only been using Eclipse for a couple of years and tend to prefer emacs so I haven't spent a lot of time learning new Eclipse features)?
Create new directory for the workspace.
Start Eclipse editor and open clean workspace.
Check out a CVS directory containing .psf files for the various programs (necessary because of a pre-existing CVS tree structure that does not play nice with Eclipse).
Use team import on the .psf file associated with the program I'm working on to pull in the necessary projects.
Switch all projects to the branch tag associated with the release in question.
Work...
I think that Workspace Mechanic solves all your problems.
http://code.google.com/a/eclipselabs.org/p/workspacemechanic/
copy your original workspace. Easy, reliable, but will also copy all your projects.
I spend some time customizing the colors for syntax highlighting in Eclipse (Java, JSP, HTML, CSS, etc.) but whenever I try to export these settings via File|Export|General|Preferences and reimport them, the settings never completely get imported back. Some colors are restored and others are left unchanged, leaving me in an 'in between' state - very frustrating.
I'm using Eclipse 3.4 Ganymede, by the way.
Has anyone found a reliable way to save and restore Eclipse syntax highlighting settings?
I finally figured out how to do this.
I just wanted to mention beforehand that I did try to start with a fresh Eclipse install, export the preferences to a .epf file, change just one single setting, export again, and compare the files. To my surprise, trying to import settings from a minimal .epf file did not work reliably either.
The solution that worked for me was to copy these files: {Eclipse workspace directory}/.metadata/.plugins/org.eclipse.core.runtime/.settings/*.prefs
I tried a fresh Eclipse install on another machine and after copying those files over, all my settings were restored perfectly.
The solution was to copy SOME - not all - of the files from {workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings/*.prefs into my other workspace.
In particular (per the https://stackoverflow.com/questions/96981/color-themes-for-eclipse thread):
org.eclipse.jdt.ui.prefs = Syntax Coloring
org.eclipse.ui.editors.prefs = Text Editors
Copying other files caused things to break.
There are a couple of notes to add:
I had to copy the aforementioned pair of files several times before I got the correct syntax coloring.
Be sure to close the workspace, if it's open in Eclipse, before copying the files.
This worked with Eclipse Helios.
If you want to be a little more fine grained on what you migrate, the syntax highlighting rules are the lines starting with semanticHighlighting on workspace-indigo/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.ui.prefs
Doing this, I was able to migrate my syntax highlighting from Helios to Indigo
I'm using JBoss Developer Studio 10 with the Eclipse Neon 4.6 engine.
All .prefs files are inside this path:
/workspace/.metadata/.plugins/org.eclipse.core.runtime/.settings
Update: I found a similar structure on this path too:
\RedHat\JBossDev\studio\configuration\.settings
It's my IDE folder plus \configuration\.settings
I recommend search for org.eclipse.*ui*.prefs instead *.prefs to refine your result.
The principal config files are:
org.eclipse.jdt.ui.prefs
Java Syntax Color Settings
org.eclipse.ui.editors.prefs
Text Editor Settings
org.eclipse.cdt.ui.prefs
Formatter Settings
org.eclipse.wst.jsdt.ui.prefs
JavaScript Syntax Color Settings
org.eclipse.jst.jsp.ui.prefs
org.eclipse.wst.css.ui.prefs
org.eclipse.wst.html.ui.prefs
org.eclipse.wst.json.ui.prefs
org.eclipse.wst.dtd.ui.prefs
org.eclipse.wst.xml.ui.prefs
org.eclipse.wst.xsl.ui.prefs
If have a problematic workspace:
Copy the files above
Create a new workspace
Copy and Replace that files in your new workspace
This will recover perfectly your custom editors color settings. For me worked very well.
Eclipse CDT stores 'Syntax coloring' in the file org.eclipse.cdt.ui.prefs
This is located for example here: C:\eclipse\workspace.metadata.plugins\org.eclipse.core.runtime.settings\
Copy and paste over the top of the one in your new eclipse instance. This worked for me when moving from 3.4 to 3.5
I would export the preference before modifying the color, and then after.
That way, you would be able to isolate the specific rules of an eclipse preference file into one smaller file and:
check if some colors not restored are indeed represented by a rule
the import of a smaller preference has any effect on the previously unchanged settings.
That kind of strategy can be further refined into several small settings files (one for Java, one for JSP, HTML, CSS, ...), in order to better analyzing the potential side-effects when re-importing those settings.
I have had success in importing Eclipse Helios's syntax highlighting rules by copying the file:
.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.ui.prefs
from the source workspace to the target workspace. It seems this file also contains Eclipse's code formatter profiles and code templates.
Environment:
Version: Helios Release
Build id: 20100617-1415
(on linux)
Once Michael Bosworth's answer helped me to some extend and I voted up. But now I see some obligation to answer it myself, because copying these two files are not enough. Let me explain why.
First, these files contains lines irrevelente to syntax coloring.
Second, syntax coloring for other editors are located elsewhere, for example, those of XML files are in
org.eclipse.wst.xml.ui.prefs
and those of HTML files:
org.eclipse.wst.html.ui.prefs
JSP pages?
org.eclipse.jst.jsp.ui.prefs
, etc.
Third, when we change font colors, usually we change background colors, line highlighting colors, etc. to get a clearer view of codes. This involves more files.
If we search *.pref files in path
/workspace/.metadata/.plugins
we can find all preferences files where we can locate all lines of coloring settings. But by copy-pasting all these files to another workspace can also trigger problems, for they are not exclusively syntax-coloring-related. Moreover, when we are switching between two versions of Eclipse, unexpected problems may arise.
So, the safest way is:
Create a new workspace if you don't have one.
Open all *.pref files we find in the workspace one by one,
Copy those lines containing color codes,
Find the same file in your new workspace,
Replace the color part by existing one. Or, set the colors in Eclipse, by assuming the corresponding options according to properties' name. All color codes are RGB based.
EDIT: (2017.02.24)
Eclipse Mars has a plugin Oomph, which can record your preference settings to provide seamless transmission of your preferences. When you activate it, every time you change a value, it prompts to ask you if you want to record it in Oomph, providing you the exact line in the corresponding file where your new value is stored. So, when you install Oomph, you can:
Change the settings of your font face, font size, background color, etc.
In the prompt windows of Oomph, take note of the location of your new settings. (Because if you tell Oomph to remember your settings, it will not prompt never again, so you may only see this windows once.)
I have deleted recently changed *.prefs file from the following dreictory \myworkspace.metadata.plugins\org.eclipse.core.runtime.settings\ and imported existing exported preference.
I am the first person, who answer for this question as per my knowledge :), Cause even I struggled lot.
Thanks
I faced the same problem few days ago.
The easiest way to restore the defaults is to import the default theme again, which you can find under:
http://eclipsecolorthemes.org/?view=theme&id=790