In order to speed up the eclipse, we can disable one or more validators in Eclipse IDE. It actually speeds up the loading of eclipse.
My question is not how to disable those validators. I know how to do that.
My question is What do those validators do? Why do we need them? What is the danger of disabling those validators? If we do not want them, why does eclipse comes with them?
If we use a build tool like ant to build our project, does disabling those validators still have any effect?
Quoting the offcial docs for juno
The validators used depend on the global and project validation settings. When you validate a project manually, the global settings are used unless both of the following are true:
The Allow projects to override these preference settings check box is selected on the global validation preferences page.
The Override validation preferences check box is selected on the project's validation preferences page.
What does that actually mean?
Validators are a feature of the Web Tools component of Eclipse. They provide a mechanism for checking the correctness of various file types (such as HTML, CSS, XML, JavaScript).
For file types such as Java the correctness of the file is determined when it is compiled, but there is no compiler for file types such as HTML so a different mechanism is need to check the files are correct. The validators provide this mechanism.
So if you turn of a validator you will longer get some messages about errors in files.
I have seen, read and thought of different ways of using Workspaces (per project, per application (multi-asseted or not), per program language, per target (web-development, plugins,..), and so on) and I am still doubting what the best approach is.
Can anyone give a detailed, but not a page long insight into this?
This involves a lot of sub-questions, so to speak, and I don't know all the specific sub-questions I should ask, as I am sure I don't know all aspects of Eclipse (and Workspaces), but I'll try to give an example of what I am looking for:
What for?
What did the Eclipse development team expect it to be used for?
What do other/most people think?
What do you think?
... ?
Why?
Are there configuration conflicts vs. sharing merits?
Any filespace reasons?
Performance?
... ?
I am speaking of the minimum use-case for a developer that uses different languages and protocols, not necessarily all of them in one project (E.g. Php, Javascript and XML for some projects, C# for others, Java and SQL for still others, etc..)
Edit 2012-11-27: Don't get me wrong. I don't doubt the use of
Workspaces, I just want to use it as it is meant to be or otherwise if
anyone would think it better. So "what for?" means: What's the best use? And
"why?" actually targets on the "what for?", in other words: tell me the reasons
for your answer.
I'll provide you with my vision of somebody who feels very uncomfortable in the Java world, which I assume is also your case.
What it is
A workspace is a concept of grouping together:
a set of (somehow) related projects
some configuration pertaining to all these projects
some settings for Eclipse itself
This happens by creating a directory and putting inside it (you don't have to do it, it's done for you) files that manage to tell Eclipse these information. All you have to do explicitly is to select the folder where these files will be placed. And this folder doesn't need to be the same where you put your source code - preferentially it won't be.
Exploring each item above:
a set of (somehow) related projects
Eclipse seems to always be opened in association with a particular workspace, i.e., if you are in a workspace A and decide to switch to workspace B (File > Switch Workspaces), Eclipse will close itself and reopen. All projects that were associated with workspace A (and were appearing in the Project Explorer) won't appear anymore and projects associated with workspace B will now appear. So it seems that a project, to be open in Eclipse, MUST be associated to a workspace.
Notice that this doesn't mean that the project source code must be inside the workspace. The workspace will, somehow, have a relation to the physical path of your projects in your disk (anybody knows how? I've looked inside the workspace searching for some file pointing to the projects paths, without success).
This way, a project can be inside more than 1 workspace at a time. So it seems good to keep your workspace and your source code separated.
some configuration pertaining to all these projects
I heard that something, like the Java compiler version (like 1.7, e.g - I don't know if 'version' is the word here), is a workspace-level configuration. If you have several projects inside your workspace, and compile them inside of Eclipse, all of them will be compiled with the same Java compiler.
some settings for Eclipse itself
Some things like your key bindings are stored at a workspace-level, also. So, if you define that ctrl+tab will switch tabs in a smart way (not stacking them), this will only be bound to your current workspace. If you want to use the same key binding in another workspace (and I think you want!), it seems that you have to export/import them between workspaces (if that's true, this IDE was built over some really strange premises). Here is a link on this.
It also seems that workspaces are not necessarily compatible between different Eclipse versions. This article suggests that you name your workspaces containing the name of the Eclipse version.
And, more important, once you pick a folder to be your workspace, don't touch any file inside there or you are in for some trouble.
How I think is a good way to use it
(actually, as I'm writing this, I don't know how to use this in a good way, that's why I was looking for an answer – that I'm trying to assemble here)
Create a folder for your projects:
/projects
Create a folder for each project and group the projects' sub-projects inside of it:
/projects/proj1/subproj1_1
/projects/proj1/subproj1_2
/projects/proj2/subproj2_1
Create a separate folder for your workspaces:
/eclipse-workspaces
Create workspaces for your projects:
/eclipse-workspaces/proj1
/eclipse-workspaces/proj2
The whole point of a workspace is to group a set of related projects together that usually make up an application. The workspace framework comes down to the eclipse.core.resources plugin and it naturally by design makes sense.
Projects have natures, builders are attached to specific projects and as you change resources in one project you can see in real time compile or other issues in projects that are in the same workspace. So the strategy I suggest is have different workspaces for different projects you work on but without a workspace in eclipse there would be no concept of a collection of projects and configurations and after all it's an IDE tool.
If that does not make sense ask how Net Beans or Visual Studio addresses this? It's the same theme. Maven is a good example, checking out a group of related maven projects into a workspace lets you develop and see errors in real time. If not a workspace what else would you suggest? An RCP application can be a different beast depending on what its used for but in the true IDE sense I don't know what would be a better solution than a workspace or context of projects. Just my thoughts. - Duncan
Basically the scope of workspace(s) is divided in two points.
First point (and primary) is the eclipse it self and is related with the settings and metadata configurations (plugin ctr). Each time you create a project, eclipse collects all the configurations and stores them on that workspace and if somehow in the same workspace a conflicting project is present you might loose some functionality or even stability of eclipse it self.
And second (secondary) the point of development strategy one can adopt.
Once the primary scope is met (and mastered) and there's need for further adjustments regarding project relations (as libraries, perspectives ctr) then initiate separate workspace(s) could be appropriate based on development habits or possible language/frameworks "behaviors".
DLTK for examples is a beast that should be contained in a separate cage.
Lots of complains at forums for it stopped working (properly or not at all) and suggested solution was to clean the settings of the equivalent plugin from the current workspace.
Personally, I found myself lean more to language distinction when it comes to separate workspaces which is relevant to known issues that comes with the current state of the plugins are used. Preferably I keep them in the minimum numbers as this is leads to less frustration when the projects are become... plenty and version control is not the only version you keep your projects.
Finally, loading speed and performance is an issue that might come up if lots of (unnecessary) plugins are loaded due to presents of irrelevant projects.
Bottom line; there is no one solution to every one, no master blue print that solves the issue. It's something that grows with experience,
Less is more though!
Although I've used Eclipse for years, this "answer" is only conjecture (which I'm going to try tonight). If it gets down-voted out of existence, then obviously I'm wrong.
Oracle relies on CMake to generate a Visual Studio "Solution" for their MySQL Connector C source code. Within the Solution are "Projects" that can be compiled individually or collectively (by the Solution). Each Project has its own makefile, compiling its portion of the Solution with settings that are different than the other Projects.
Similarly, I'm hoping an Eclipse Workspace can hold my related makefile Projects (Eclipse), with a master Project whose dependencies compile the various unique-makefile Projects as pre-requesites to building its "Solution". (My folder structure would be as #Rafael describes).
So I'm hoping a good way to use Workspaces is to emulate Visual Studio's ability to combine dissimilar Projects into a Solution.
It's just a feature for structuring projects.
Obviously Eclipse designers tried to avoid having global settings for Eclipse and decided to put them into workspace.
Each Eclipse app depends on each workspace settings.
Is it a good decision? I think it's not so.
It lacks flexibility. It was naive to expect that global settings can be avoided.
It doesn't allow you to have single projects (it can be a surprise for Eclipse designers but it happens quite often).
But it still works.
Many people use it. Sometimes they suffer but more frequently everything is ok.
Suppose that you have a bunch of projects in your Eclipse workspace. Some are Java projects, some may be CDT projects, others may come from third party plugins such as TeXlipse or EPIC. You strive long and hard to produce quality code, yet in one specific project you have a couple of warnings, through no fault of your own - warnings that propagate up the chain to your working set and poke you in the eye.
Is there a general way in Eclipse 3.7 to tell the IDE that it should ignore (and be quiet about) all warnings from a specific project, regardless of whatever support the responsible plugin may or may not provide?
From what I can tell, Eclipse 3.8 (or is it 4.2?) will have a better handle of warnings. Would waiting a couple of days for it to come out help at all with this specific issues?
Supernecro, but if it is still relevant, and you want to block errors because you are editing another project, right click the project and click 'close project'.
For Java the only thing I could find is the Project Preferences -> Java Compiler -> Errors/Warnings Page. If you set all settings to "Ignore" that project should be quiet. However it is quite cumbersome. Maybe other compilers have similar settings, too.
Best I can suggest is to click on the little downward-pointing triangle on the right side of the Problems View title bar. From that drop down menu select Configure Contents. I don't think you can filter out errors for a specific project, but you can filter out kinds of errors.
I'm using SVN (Subversive) for some projects and git (EGit) for others, so I've configured two different perspectives for each type of project. I'd like to know if there's a way to associate a perspective for each project, so that when I open them the perspective is changed automatically.
Is there a way, native or via a plugin, to accomplish this?
I believe, it is very hard, if not impossible to do this. At project creation sometimes a perspective change is triggered (e.g. the creation of a plug-in project opens the PDE view). Otherwise, no general perspective opening method is used.
If you write your own plug-in, it could provide the required switch: either by listening to the opening of the project, or by adding a different Open project command, it is possible to write code that changes the current perspective. On the other hand, I don't know any of those plug-ins available.
I have an Xcode project (for an iPhone application) that uses cocos2d. I have cocos2d set up as a dependent project, so it builds alongside my project.
Now I need to set a compiler flag to Cocos, and I can't find where to do it.
I tried setting the compiler flag in my build settings, but it doesn't propagate to the dependent projects. I checked the different Get Info panels, but I cannot find where to do it.
It seems to me that this should be possible, since the dependent projects come from svn:externals and it makes no sense to have to change the build settings in these projects.
Any hint?
There is no way to have your project settings automatically propagate to a dependent project (you probably wouldn't want that usually anyways).
You have to set it in the dependent project (either for the entire project or a specific target).
I.e., double click the dependent project to open it then change the compiler flags as you would in any project.