While developing Nodeclipse, I found that some bugs don't arise immediately but after some time, when combination of updates, restarts happens.
Is plugin update or uninstall/install really clean?
I develop and use installing for update, then use newer version until I got time/idea to improve. However as said above I ran into situation when Eclipse behaves differently after the new feature have been used for several days.
Is there some information that must be read about plugin install life-cycle, that mentions some not so evident behavior.
UPDATE: Some problem were in Autumn 2013 when we were switching to tycho build. Also around that time Eclipse Kepler 4.3.1 was released.
No, they are not "clean". Moreover when you do uninstall, no files are deleted, Eclipse would just prevent plugin from loading on the startup.
If you really want to remove the plugin you need to
Uninstall it via UI
Delete the plugin files in the file system
Remove plugin settings from workspace or create a new one.
Here is some interesting info for you:
There is no mechanism within Eclipse to permanently and physically
uninstall a feature and its plug-ins. The process to physically and
permanently remove an undesirable feature and its plug-ins is a manual
process that should be done when Eclipse is not running. In order to
do, you will have to manually remove the files there associated with
the feature from the eclipse/features directory and its plug-ins from
the eclipse/plugins directory. Be very cautious as to which files you
delete, and always have a backup of your Eclipse directory. If you
remove the wrong files from these directories, you may have quite some
trouble restoring your Eclipse to a stable state. Therefore, unless
your hard disk storage capacity is extraordinarily limited, it is
recommended that you simply leave the physical files in place.
Note that when manually removing plugins as described above, it is
likely that some metadata will still cached by Eclipse. This can lead
to problems later on. Running Eclipse with the -clean option may help
with that, as it causes Eclipse to clean the cached metadata. See the
Running Eclipse help page for details about this option.
Source: http://wiki.eclipse.org/FAQ_How_do_I_remove_a_plug-in%3F
You cannot do this ideally, because the plugins designed for eclipse leave their temp access files even if they are uninstalled, to do so, you will have to follow the steps:
Uninstall the Plugin: You can use the Eclipse UI directly. Go to Help > About Eclipse > Installation Details, select the software you no longer want and click Uninstall.
Delete the Present temp Files in the System, make sure to re-check the dependencies(Note: Removing Dependent Plugins might cause Eclipse to stop Working).
Remove the plugins from the workspace, or in short you can re-configure a new workspace.
This would be removing the plugins, but removing its traces manually.
ref#Link
Related
I have just updated the IDE, plugin version and library dependencies, and now I can't build my project. SBT throws java.lang.NoClassDefFoundError: sbt/TrackLevel when executed. I also can't run ./sbt clean since it attempts to load the project and fails with the same error.
I changed my sbt.version in build.properties to 0.13.17 and ide build my project all fine.
That can happen for various reasons, usually because of some mismatched versions or leftover caches. Surprisingly often, sbt can't gracefully handle updating plugins, let alone itself and it's the reason I waste hours every time I decide to refresh my project and bump up versions.
Attempt 0: Check known version incompatibilities
You know, just in case. Pay attention to the plugin/dependency you've just updated and whether anything is mentioned in its changelog. Keep this in mind while going through the Attempt 1.
Attempt 1: Update dependencies
This is a good chance to update all (other) dependencies and plugins (of course, if that doesn't break your project but it shouldn't be the case unless you're already using deprecated methods). Doing so might resolve the issue, so look up library dependencies you're referencing in your build.sbt, plugins from project/plugins.sbt and sbt version itself in project/build.properties and bring them up to their latest versions (consult Google and appropriate repositories, e.g. http://mvnrepository.com).
If you're still using activator or play commands to build your project, grab the Java/Scala seed or one of the templates from Play donwload page, extract and copy sbt (if you intend building it on Linux), sbt.bat (if you intend running it on Windows) and sbt-dist directory into your project and feel free to delete any references to activator from your project. Try executing ./sbt and see if it works.
Attempt 2: Delete project caches
Since you're still reading this, chances are updating dependencies didn't really do the job. Well, at least now you have a refreshed project.
Remove target/. Remove project/target/. Remove project/project/target/. Curse whomever came up with those cache names and their paths. (Protip: holding shift while hitting delete will skip the recycle bin and delete the files permanently.) Attempt to built the project again and hope everything is okay now.
Attempt 3: Delete global build caches
In case it didn't do the job, as a last resort we're gonna remove all the caches and start fresh. Repeat step 2 in case previous failed build left something behind.
Navigate to your home folder. Remove .ivy and/or .ivy2. Remove .sbt, or in case it contains some configuration you want to retain rename it to e.g. .sbt.old and restore specific files afterwards. It could take a while since those directories could contain dozens of thousands of files. (You could delete all IDE caches here, but I've never encountered that being the issue - it will rebuild the whole project on next launch anyway since you've destroyed most of which it relies on already)
Go back to your project folder and rerun ./sbt. That could take a few minutes since it will download all dependencies (including sbt and Play themselves) and put them in place. After that, you will have fresh project, as if you've build it from source on a clean machine.
In case it still doesn't work, you can safely assume it's either mistake in your build files (triple check them again) or a bug in the build system.
I installed following plugins in eclipse indigo in following order to start spring development
Spring Tools Suite
M2E (Maven)
after these two installations, it was giving error
jira connector not installed, so I installed the following plugin.
Atlassian Jira Connector
After installing Jira Connector, Eclipse Started showing the following error :
Uninstalled Jira Connector. Still Showing these Problems.
Any help would be appreciated.
Eclipse has major structural problems with uninstalls, which aren't really fixed even the latest luna. But don't worry, there are a lot of workarounds.
What you can do now and in similar situations:
1.
If you can even uninstall something, you won't get back its previous state before the install.
Because of it I use Eclipse normally with a trick: I store my main Eclipse install directory in a git repository, and so I can always switch back with a single command. But it is only a trick.
2.
There is a big chance, that only your workspace directory is damaged, and not your Eclipse. In this case you can solve this problem by reinitializing your workspace: make a backup, delete everything, recreate your workspace directory and finally import again your projects.
(For similar reasons it is also an useful trick to save your workspace metadata in a git repository as well.)
3.
In Eclipse, the menu items are created by modules. If an eclipse module is installed, it creates the changes in its internal configurations which create the menu items.
After a restart, Eclipse tries to restore your gui, and thus re-open its panels. But if a module uninstall is also happened, then its panels aren't restorable, resulting exactly your problem.
So, simply close the bad panels and try to reopen them. Sometimes it also works.
In short: recreate your workspace, it will probably help. And next time, use Eclipse with some good and frequent backup (I suggest git).
I'm trying to figure out which files to check in to version control when using Eclipse for Android development. I have a workspace with a single project. I found this which suggested that the .metadata folder did not need to be controlled (minus the comment there about launch params, however I don't mind re-picking those again on a different machine).
If I remove the .metadata folder then open Eclipse the project is no longer shown. I searched for posts on this symptom and they suggest re-importing the project. This solution doesn't make sense here, I'm trying to check in whatever is needed so another developer can open the workspace and see the project and work on it. Having them move the project then re-import it would be a bit messy.
So which files should I be version controlling so that someone else can get the latest and be able to open the project without controlling a bunch of user specific preferences?
I have had similar experience using Eclipse for version control, and decided to quit using it because it is very annoying and buggy. Now, for git, I use SourceTree, which I prefer over eclipse version control. I think you should version control the source code folders, along with configurations, and other files you program needs to function, but never the executable files. If the other person is using Eclipse, for easiness, it is good idea to include the .classpath configuration file. If not, then the other person would need to clone the repository and make the required changes so that it works with his/her IDE.
I think I've settled on the following approach. This seems to work well so far and avoids some of the headaches mentioned in my original question.
1) each developer creates an Eclipse workspace on their machine somewhere, outside of version control; only the project directory is checked into version control - the workspace is completely uncontrolled
2) developers checkout the project directory from version control (in a different directory structure than where the workspace was created) and then use File >> Import, but they leave the "copy into workspace" unchecked.
So with the above, you can checkout from version control and work with the files right where they were checked out. There's no need to move them out then import them back in. When you import with the copy option unchecked, the workspace (which itself is not controlled) is just referencing the files where they're at on disk.
The only minor downside is that any workspace stuff has to be setup individually. Other articles mention controlling the launch params, but so far this hasn't been an issue - pretty easy to pick that once the first time you launch.
So anyway, hopefully this helps someone else :) This seems to be a reasonably smooth way to do it and avoids the issues we ran into initially.
I'm having this problem in eclipse (EE) when I change things in my code (even something as simple as the text I'm printing using println) it doesn't get applied. I'm using JBoss and when I rerun the servlet, nothing happens.
Any idea how I can force JBoss/Eclipse to do this? I can't preview anything so it's really annoying if I want to test some new code.
Thanks!
Eclipse publishes the newer versions of your application periodically (its called the automatic publish feature). Either the interval is too large, or you're not waiting sufficiently long enough for re-deployment, or automatic publishing of the application has been disabled.
Sometimes, despite ensuring the above, Eclipse might still not publish the newer classes, in which case you might want to perform a clean build, which causes the newly built classes to be loaded into JBoss.
Sorry to ask such a basic question: Do you save your changes before testing?
Eclipse uses its own compiler to check for syntax errors while you are editing, but you have to save the file before the edits take effect in the application.
I only ask because this could be confusing if you are new to Eclipse, having changed from a different IDE. File permission settings can also prevent your files from being saved or built.
Working on EJB deployed in JBoss with Eclipse IDE.
We have ANT build file, in which first old project is deleted from JBoss,
then compiling classes, & building proper directory structure & deploy as .ear - .sar again in JBoss directory.
Stop JBoss, run build file, start JBoss.
Its a good practice to have a build file to deploy project.
I have so many projects in workspace. for every one or two weeks i have to search for *.snap file delete them. otherwise my eclipse will take lot of time to come up? So curious to know what are they? are they specific to java? as i have lots of java projects in my workspace?
*.snap files represent the changes in workspace state of the IDE during the runtime. This is mostly for eclipse crash recovery plan. When a crash happens these files are used to recover the state fo eclipse workspace.
It looks like your eclipse platform is crashing quite often. Because otherwise, the snapshot files should not be there while the platform is not running. As the referenced page in roe's comment explains, they are just needed for crash recovery and are deleted during normal shutdown of the platform. Deleting them will make eclipse think, that no crash occurred but then it can't recover and you may have to refresh/rebuild your workspace (which may take the same time).
I'd not delete those files except eclipse won't recover from a crash. Have a look at the eclipse workspace and platform log files if you have troubles with some plugins and fight the problem from this side (updating plugins or sending error reports) instead of deleting those files.
A very good solution for me was to:
Cut and Paste the .snap file in a separate folder
Start and then Close Eclipse (after restarting I've noticed that some of my classes where not there)
Put back the .snap file in the original place
Start again Eclipse