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.
Related
Is there any built-in way (or plug-in) allowing for searching through the whole variable tree without manually expanding nodes?
I can't understand why isn't it done by default, just as I can't understand, why isn't search bar built into Variables view (browser style) and this unhandy, inconvenient dialog is opened instead. It makes my work, which is mainly debugging complex applications, a nightmare.
The Eclipse version is Luna, if it matters.
The watch expression feature is not what I want because it just doesn't work in this case, tried to fix it but none of the common ways to do that help me.
Such a feature has been requested earlier here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=170396
You may want to reopen this bug to state your interest in this enhancement. And if you have experience in developing Eclipse IDE plug-ins, I am sure the maintainers would be happy to review a patch.
I usually use Alt+Shift+Right/Alt+Shift+Left and Ctrl+Shift+I to select and inspect variables and expressions, but this certainly depends on personal preferences.
I've realized that the Eclipse IDE puts all packages in a project (at least in a Java one) at the same level, e.g.:
However, browsing the file system, you can find that packages are treated in the expected multi-leveled way. Does this have any logical explanation?
This is just a presentation feature. You can click on the little down arrow you see on the left of your screen shot and select Package Presentation -> Hierarchical to have it like your filesystem.
You can see this answer for more information.
I asked the same question a couple of times and found the link in above answer helpful in order to change the presentation because it's an option hard to find.
About the Why part, I think it's because of Eclipse being DE-facto standard IDE for Android development and having the packages organized this way is more useful and it forces you to think about a way your classes are organized according to Android project guidelines. It also looks quite like help files on http://developer.android.com/guide to me personally. Also another argument for this might be that in old versions of Eclipse (pre Android time) default view was different.
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.
Is there any benchmarks or study done comparing these two IDEs in terms of
-- stability
-- developer productivity
-- features
-- performance
-- etc.
I am an Eclipse user (not by choice). Not sure about stability, but performance wise NetBeans is far supperior at least with the lates versions that I worked in; personally, I think NetBeans has enough features to make it a good development environment but I can't tell you for sure, it depends on what is the scope of your task. Overall, eclipse is a good IDE, but NetBeans is just a little better...
Mostly working with eclipse nowadays.
All I can say is M2E is a pain.
With no disrespect intended to the developers of m2e ...
This is the simply the absolute worst plugin for maven. It is slow and it is painful to use.
For big maven projects with more than 70 module components, you can forget about having a quick eclipse evironment.
If you use mvn eclipse:eclipse, the deprecated plugin for configuring eclipse, I believe you are faster with eclipse than with netbeans. Especially when it comes to refactoring.
If instead you use the official m2e plugin ...
Oh my god!
I am answering to this question due to the pure shear pain of waiting for eclipse.
" Invoking CDI Builder" because an #Inject collaborator moved around in the class, triggering a massive build wait time delay... god!
Eclipse! Well... Eclipse is a great IDE for getting started, on small projects, but as projects get enterprise level, and if you use m2e ... oh! you will cry!
And wonder ... how can it be this bad.
Netbeans! Perhaps nota any better in the end.
Last time I used Netbeans, i had two major complaints, that were total deal brekers:
(a) Netbeans was simply awful when dealing with massiven class refactoring.
You change a class name on sub module A, that affects modules B, C and D.
And until you class renaming, move over packages is done, you can go take a coffee, and order a cab.
(b) netbeans had a bug in parsing interfaces, namely there was some sort of regular expression that would take the longest time to run.
So if you can use the old deprecated mvn eclipse:eclipse, you would end up being far better of.
With that said.
The Netbeans debugger compared to the eclipse debugger is light years better.
I prefer the graphics of netbeans and I prefer the simplicity of netbeans.
Just try using the "expressions" where the autocomplete does not work, and you ave to go to "display" to get autcomplete to work and copy it bakc over to expressions!
Eclipse is a patch work, with hundreds of thousands of developers making hundreds of different components of the IDE, leading to an overall result of a total inconsistent product.
Eclipse is a never ending set of settings, just open the preferences and ...
Netbeans, UI is always desing for maximum simplicty.
As I wait for my m2e to finish rebuilding prjects based on whatever whim lead eclipse to start a new build, I start considering again if I should not revisit Netbeans and install the eclipse formatter ...
Eclipse is really in bad shape, In my humble oppinion.
Ther performance of eclipse has to improve 100 fold, especiall eclipse + m2e has to get way way better.
Intelli J - i have never tried.
The best IDE have used so far, is wihout any doubt, Microsfot Visual Code for Javascript and TypeScript.
You use Microsoft Visual Code, and just wonder why eclipse is not like that.
If you are doing Angular Js/Typecipt, simply forget about any other IDE out there. Microsoft Visual Code is the best thing there is, it is fantastic and joy to use.
Blazing fast and light and good looking on every platform of your desire.
But for java + maven, the echo system is a bit lacking on good options.
The man is not supposed to wait for the machine.
A human is always supposed to be slower then a machine ... this is not the case with eclipse m2e, this I can tell you.
The furstration!!!!
Unless you have lots of hardware to throw at it, go with Netbeans.
I have a VM running CentOS 7. At this time, I am only able to allocate 2G ram to the VM, and running Eclipse Oxygen for PHP on it is painfully slow. Netbeans runs just fine in this configuration.
I'm sure some Eclipse devotee would suggest giving the VM more ram which might probably resolve the issue, but unfortunately that is not currently possible.
Another thing that ought to be mentioned is that Eclipse is rather unique in its UI. For example, virtually every editor on the planet uses Ctrl-F to "Find", then function key F3 to "Find Next". Ctrl-G is "Goto line number". Netbeans follows this convention. Eclipse, however, uses Ctrl-K to "Find Next" and Ctrl-L for "Line number".
This won't be an issue if you use Eclipse and nothing else, but if you're like the more typical developer, you use Eclipse when appropriate along with some other tool when appropriate. You will get confused sometimes and use the wrong shortcut. This creates unpredictable problems, particularly if you're unsure what the wrong shortcut just did to your file.
It's not a "performance" issue as per the application, but it slows down the developer. To me, that's just as bad.
Again, some Eclipse devotee might suggest that Eclipse shortcuts can be configured any way you like, which is true, but really, does anybody have that kind of time? Eclipse comes with literally thousands of configuration options, and it's an Internet Search to figure out how to change almost anything.
Netbeans doesn't have thousands of configuration options, although there are things you can tweak. It just sorta mostly works the way you expect out of the box.
To conclude, the actual slowness on less-than-most-super-powerful hardware is probably the biggest thing against Eclipse. I don't know what the code is trying to do, but Netbeans is somehow able to do it with less hardware.
Eclipse and Netbeans are both good IDE (Integrated Development Environment) programs. If you are just a Java, C++, C or Fortran programmer you can use any of them.
If you are WEB base developer (For Example: JSF, Serverlet, Applet) in this case NetBeans is much more powerful then Eclipse.
On the other hand, If you are mobile developer for Android OS, in this case Eclipse is much more powerful then Netbeans.
So it depends on your programming league :)))
I want to use the "Web Tools Editor" that is part of the Web Tools Plattform in my own RCP-Application. I think i have got some understanding on the RCP plattform by now, but I still have no clue how to access the functionality of the pagedesigner (org.eclipse.jst.pagedesigner) after adding it as a dependency to my project. Has anyone some experience in adding components of the web tools plattform into an RCP-Application and can give me a hint or something?
There's a difficulty with these sorts of requests (I am, myself, trying to include this or that feature that I saw in the Eclipse IDE, every so often).
The trick is to try and identify the component you want to bring in, and then try and pull it into your project, without bringing in too many dependencies.
The first step used to be quite hard, but since 3.4 it is a matter of using the Plug-In Spy - hold down Alt-Shift-F1 on whilst your desired component is in focus should give you a tooltip showing you the class, the bundle, etc etc.
The second step is altogether more tricky and is where I usuaully fail to get any results:
if you are lucky then you can just include the bundle in the launch configuration/.product of your app. Once you hit Add Required Bundles, you are not left with 3000 bundles (i.e. your RCP is now Eclipse).
usually, this is not the case, because the Eclipse team haven't refactored the bit of code you're interested in out into an RCP safe bundle. If so, then you're going to have to do that yourself.
Again, if you are lucky then that will mean moving some classes out of the eclipse bundle into your own, including internal classes, and that will be the end of it - i.e. the dependencies of your desired functionality are all within the bundle.
If you're unlucky, then you need to isolate/reimplement the bit of functionality that is required, and change your version of the copied code.
It is hard laborious, and pretty difficult to upgrade. I realise that none of this is what you want to hear.