I'm coding with different languages (c, python, java, latex and ...)using eclipse on a MacBook(2gb ram, coredou 2.13). This needs to install many plugins for each language along with some other common plugins(mylyn, vrapper, svncontroller), which makes the machine very slow. Since every time I start eclipse, I aim to only use one language, then I really don't need many of the plugins to be loaded. I was thinking if there is any way to bypass loading unwanted plugins, then having a faster eclipse.
You may suggest to have separate eclipses for different languages, but this requires installing the same plugins for all eclipse copies separately, which is very tedious.
thanks for your help in advance
--
green-i
You can specify that some plugins won't be loaded when Eclipse starts. This can be done under the preferences, under General → Startup and Shutdown. Note that most plugins do not properly implement the required API, so they cannot be controlled in that way. Also, they will be loaded if activated, so make sure you close all views from the given plugin in your workspace, so it won't load (go over all the perspectives for that matter).
Another option is to create a single shared installation with multiple configurations. Each configuration will include plugins specific to a given task. For more details, read my answer here.
Related
I have a lot of plugins installed on Eclipse Luna (including Spring, JBoss, Android, Genymobile, Tomcat, Apache, Axis, ...).
However, as you can argue, I don't use them all at the same time. Also, it seems that they slow down Eclipse in many ways.
So, what I'd like to do is to prevent eclipse to load them at the startup and instead only as needed.
Is there any way to achieve this goal?
Eclipse is lazy start by default. It will read all plugins manifest to determine their dependencies and if they add themselves to the UI and things like that. But they will only be started if they are actually used.
Say a plugin adds a view. It will be selectable in the show view dialog, but no code will have been loaded until you choose to use it. I believe it's the same thing with buttons on the toolbar and menu items, but if they require code to determine their enabled state (as many do) that will most likely require a full load of the plugin.
You can install the Plugin functionality in Eclipse to get the Plugin Registry view. From there you can see which plugins are actually active. The list will probably be smaller than you think.
However, to make it even smaller:
Uninstall plugins you never use
Customize your perspective to remove views you never use
Customize toolbar and menu to remove buttons and functionality you never use
Removing plugins from automatic startup is not a good idea, since they may rely on some functionality having executed at startup.
Some plugins have a tendency to completely take over your Eclipse installation and load themselves regardless of what you would be doing. I used Aptana as an Eclipse plugin some years ago, and it did just that. I had to create a separate installation just for it.
If you are using "heavy weight" plugins that adds a lot of functionality it might be a good idea to keep separate Eclipse installations for them.
In Windows->Preferences->General->Startup and Shutdown dialog box, there will be a list of installed plugins,select the plugins you want to activate on startup.
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.
Can go run dynamically in order to be used for a plugin based application ?
In eclipse, we can create some plugins that Eclipse can run dynamically.
Would the same thing be possible in Go ?
I'll argue that those are two separate problems :
having dynamic load
having plugins
The first one is simply no : A Go program is statically linked, which means you can't add code to a running program. And which also means you must compile the program to let it integrate plugins.
Fortunately, you can define a program accepting plugins in Go as in most languages, and Go, with interfaces and fast compilation doesn't make that task hard.
Here are two possible approaches :
Solution 1 : Plugin integrated in the main program
Similarly to Eclipse plugins, we can integrate the "plugins" in the main program memory, by simply recompiling the program. In this sense we can for example say that database drivers are plugins.
This may not feel as simple as in Java, as you must have a recompilation and you must in some point of your code import the "plugin" (see how it's done for database drivers) but, given the standardization of Go regarding directories and imports, it seems easy to handle that with a simple makefile importing the plugin and recompiling the application.
Given the ease and speed of compilation in Go, and the standardization of package structure, this seems to me to be a very viable solution.
Solution 2 : Separate process
It's especially easy in Go to communicate and to handle asynchronous calls. Which means you could define a solution based on many process communicating by named pipes (or any networking solution). Note that there is a rpc package in Go. This would probably be efficient enough for most programs and the main program would be able to start and stop the plugin processes. This could very well feel similar to what you have in Eclipse with the added benefits of memory space protection.
A last note from somebody who wrote several Eclipse plugins : you don't want that mess; keep it simple.
Go 1.8 supports plugins (to be released soon Feb 2017.)
https://tip.golang.org/pkg/plugin/
As dystroy already said, it's not possible to load packages at runtime.
In the future (or today with limitations) it may be possible to have this feature with projects like go-eval, which is "the beginning of an interpreter for Go".
A few packages I found to do this:
https://golang.org/pkg/net/rpc/
https://github.com/hashicorp/go-plugin
https://github.com/natefinch/pie
just changed from Netbeans to Eclipse just for fun (Only developer on the company, So I can code on whatever and with whatever I feel like.) That's why I liked the new version of netBeans over vim, it could load resources or plugins, I am not quite aware of their naming conventions, on demand. For example if you were working on a Grails project it would only load grails related resources.
On Eclipse I have a gazillion plugins installed. Some to emulate Netbeans functionality (Grails, JavaFX, Ruby, PHP, CSS, Python, etc.) And some others Netbeans lacks (Android, Vaadin, SpringRoo, Git and some others) But I am not sure how Eclipse handles this plug in behemothing
Does it load them on demand? Do I have to manually disable the ones I am not using? Do I have to have different installs for each language I work on? Or do I have to learn how to live with this big mess of plugins in order to have everything I need at hand??
Thank you very much for your time.
Basically Eclipse loads the plug-in codes lazily. On the other hand, the menu/toolbar contributions are loaded at the start of the platform.
If the plug-ins are written correctly, they should not interfere with each other, and the unnecessary elements should be few in the context menus.
My suggestion is to try this installation, and look for potential problems. If you have problems with the environment, only then try to identify and remove the plug-ins. But it should be ok.
I use eclipse for quite a lot of work, including:
multiple "utility" projects that include code that most of my java work makes use of
various plugin-related projects that I sync and use periodically (eg: the Git plugin)
plugin projects I'm actually developing
the occasional pydev / non-java project
etc...
It is becoming quite difficult to keep all these things straight, particularly since I never need to use them all at once. I've tried using Mylyn (and I'm trying it again) but in the past it has caused eclipse to run extremely slow, and I am notoriously horrible at remembering to tell mylyn that I've switched tasks, so it tends to learn very odd (and largely useless) sets of resources.
I've considered using multiple workspaces, but that is problematic when multiple projects need to exist in multiple workspaces, and when I need to synchronize the eclipse metadata directories across workspaces.
What is the best way to manage complex working environments in eclipse? Other development environments aren't a viable option because there aren't any sane alternatives when it comes to developing eclipse plugins (and that is a requirement).
(I think a very similar question was asked a month or two ago, but I haven't been able to find it...)
It isn't quite clear to me what your need is. But have you tried using working sets in the Package Explorer?
Open the Package Explorer view, open its menu, and Select Working Set. That lets you give a name to a subset of all the projects loaded in your workspace.
Switch working sets using the package Explorer menu. Use working sets to limit the scope of Search, errors, problems, etc.
Define as many working sets as you need to group your projects. A project can be part of any number of working sets.
Here's a screencast about working sets -- this does look like the right answer.
http://www.peterfriese.de/eclipse-working-sets-part-i/
You want to use "Working Sets".
I would recommend using different workspaces, and then adding the common projects to each workspace (you can specify the location of the project to be outside of the workspace). I believe this will work, but I haven't tried it, so I can't be sure.
As #JesperE and #Dennis S suggested, working sets will help you organize your projects, but they may not make eclipse run any faster, since the projects will all still be loaded into the workspace.