I am trying to free some disk space. I found out that files related to Eclipse take up a lot of space. I would like to know which of them I can remove without harming the operation of Eclipse. In particular:
The folder ~/.p2 takes 1 GB. Most weight is in .p2/pools/plugins. Is it the real code of the plugins or only a cache that can be deleted?
The eclipse-installer takes about 60 MB. Do I need it after instasllation or can I delete it?
Are there any other cached files that can be deleted?
(I have Eclipse Oxygen on Ubuntu 16.04, if that matters).
You can safely delete the eclipse-installer. It's components are embedded into your installation and therefore there is no dependency on it anymore.
As for ~/.p2, this is the main code of your Eclipse installation. The good thing about it is that multiple instances installed via the eclipse-installer share the P2 pool.
The bad thing about it is that it does not clean up any unnecessary bundles after updates automatically, so there might be old and unused versions of bundles in that folder. You can use the Cleanup Agent of the Eclipse Installer to clean up the bundle pool (kudos to howlger for the cleanup hint!)
If you are doing Eclipse development (PDE), the .metadata\.plugins\org.eclipse.pde.core folder might be one of the most effective places to free disk space, because launch configurations and target platforms store their configuration and caches there. But this only makes sense if you do not plan to use Eclipse for a while...
Related
I have a question about local packages and gulp using them. The problem is, I have a packages.json in my working directory of my IDE with a lot of dependencies which also have dependencies. Now that wouldnt be much of a problem, but when I install them through npm, I get the directory node_modules.
The problem is that I have to build often but since the modules are getting installed in my local directory, my IDE starts to scan them and build the workspace. It hangs every time probably due to the complex dependencies. Apparently I need those packages locally because the gulpfile require('')s them.
I wonder if anyone else has stumbled upon this problem and what their strategy was for excluding the dependencies of their workspace. Eclipse (or in fact Zend Studio which I use, derived from it) doesn't seem to have its own exclude for it.
PS: I tried copying all to my global directory (where all packages are installed with the --global flag set) but there are that many dependencies within depedencies that the path becomes too long for Windows to handle (yeah I know, Windows). That didn't became a suitable solution either.
This sounds similar to big Node.js projects in Eclipse issue https://github.com/Nodeclipse/nodeclipse-1/issues/159
The solution would be disabling JSDT nature for there project (see Nodeclipse not recognizing generator functions answer)
See http://www.nodeclipse.org/history
Is it possible to create an Eclipse installation package, that contains a bunch of bundles and plugins? If so, how? (Like the ones that are already being offered by Eclipse.org and also from different vendors with their own projects)
The reason I am asking is, that I find it very time-consuming to install a bunch of software into development environment every time I need a clean installation of Eclipse (based on various reasons, corruptions etc.).
So I would like to install all the software I need at once, and save it somewhere else before working with it (as a backup) and if something goes wrong I can install the entire base installation again without being have to handle all the extra software in it.
Thanks!
Eclipse is downloadable as a zip or tar file, so you can dezip it in a folder, add your favorites plugins (their will be store in the eclipse folder in plugins subfolder) and create a new archive with your modified environment (your eclipse folder).
I think It's the simple way to create a backup.
I hope it may help you,
Have a nice day
One option is to use Yoxos, which allows you to create your own package of Eclipse and easily share it (including with yourself).
I'm working with a decent sized application (300-350MBs) in my Eclipse IDE. All is well, but when I modify a source file (i.e. MyServlet.java), I can't see any changes until I clean the project, which in turn runs a project build. Due to the size of my project, this build takes about 3-5 minutes.
I guess what I'm asking is if there's a faster way to update changes made to my source files, so that whenever I need to debug, I don't have to wait 5 minutes for every minor change.
What I've tried so far:
Restarting the server
Refreshing the project
Restarting Eclipse
Committing to the SVN
Clearing my browser cache
There is a dedicated tool for that: JRebel. Problem is that you need a licence.
But what you really need to do is to recompile changed class. In your case if this is a Servlet you also need to deploy it to server (+some servers support 'hot-deploy' and some don't, I.e. do you have to restart the server)
I want to create an automated installer for an Eclipse plugin (i.e. not through the "Update Manager"). My scenario is simple: the user closes Eclipse, drops a downloaded JAR into the dropins folder, starts Eclipse and the rest of the process is automated.
In older Eclipse versions, before the era of P2, Eclipse had (still has) a class called InstallCommand which could be used to install pluings into the currently running platform.
While this still works in Eclipse 3.4 & 3.5, it is not behaving properly: most noticeably, plugins installed that way cannot be automatically uninstalled (it is dimmed).
The JavaDoc claims the InstallCommand is deprecated and should be replaced by a P2 alternative. However, I couldn't find the right tool for the job. There is the P2 director, but it is built for running as a separate application from the command line. It is possible to invoke it from within Eclipse but it is really not cut out for that. For example, progress monitoring and error reporting are not working well.
Does anybody know of a good alternative for that?
Thanks,
Zviki
Dropins seems very close to what you want, especially if they are just downloading jars without the associated metadata (ie the metadata will need to be auto-generated).
You could consider defining a second dropins area to manage yourself. Take a look at ProfileSynchronizer in org.eclipse.equinox.p2.reconciler.dropins, in particular the method createProfileChangeRequest. I expect the uninstall behaviour you don't like is a result of the IInstallableUnit.PROP_PROFILE_LOCKED_IU property being added.
The dropins are reconciled at startup, see the p2.reconciler.dropins Activator.watchDropins(), you can likely do the same from your own bundle to watch another folder.
I suggest to deploy your plugin as an executable JAR. The installer in the JAR should ask for the Eclipse install directory and unpack the plugin in the right place (plus some more checks as needed).
Optionally include a little "watchdog" plugin which doesn't depend on much and just checks that your main plugin loads correctly and displays a useful error message which the user can email to you for support.
According to information in bug 311590 1 which is referenced in the deprecation comment of InstallCommand an alternative is possibly to use P2 operations 2, 3.
I have a static Web project added to an Apache server. Whenever I make a change to the project, regardless of how small the change is, the entire project republishes instead of the individual file. I was under the impression that the publishing process was supposed to keep a delta and only republish the files that have been marked as changed in the delta.
I wouldn't mind if the project were small, but it's a large project (200+ MB) and the connection to the server I'm publishing to is a bit slow. A republish takes anywhere between 15 minutes and a half hour.
Does anybody know if my install of Eclipse is working as expected?
Environment Specifics:
Eclipse Galileo
Aptana Studio Plug-in 1.5.1
Maybe you've found a bug. Try rsync instead.
There was a bug about delta publishing, but it should be fixed by now. And from other Eclipse projects, I assume that they added a test case for this, so it shouldn't happen again. But maybe your circumstances trigger a new bug.
Are you manually changing the files or do you use some script outside of Eclipse? Anything that makes Eclipse think the whole project has changed, will trigger a full redeploy.