I recently renamed one of the projects in my workspace. As a result Hibernate is throwing errors on a "ghost" class which no longer exists and is not referenced anywhere in my entire workspace including, source files, hidden files, config files, derived files, and binary files.
See screenshot below for visual people.
Where is the non-existing class name coming from? It is clearly being found by a component-scan.
Every time this happens, I am able to work-around the issue by doing all the following:
Delete the Tomcat server
Delete all my projects from Eclipse
Re-clone projects from git into Eclipse
Re-create new Tomcat server and re-add the projects into them
Is there a better solution?
You never mentioned whether you did a "Project->Clean..." from the menu. That could very well help. It's also not clear whether this is a Maven project. If it is, then doing Maven->UpdateProject from the project context menu could help.
Related
I just want to know if there is a way to duplicate an eclipse workspace including the projects inside.
EDIT : Copying files doesn't work for me, I'm looking for an automated process or a plugin.
I am not aware of any automated solution. The worskpace itself (in the .metadata directory) contains absolute paths and that's the reason why you cannot simply copy it.
I always duplicate workspace by creating a new one. It may be more complicated, but it always works. I have all the eclipse-project files (.settings directory) in a versioning system which makes creating brand new workspace relatively simple. After creating empty workspace, I just use Import -> Existing Projects into Workspace.
Not exactly copying a workspace, but you mentioned what you are looking for is an automated process, so Eclipse Installer (a.k.a. Oomph) might be an option. It allows you to provision developer workspaces including cloning VCS repositories, setting up projects and pre-setting user preferences. The Eclipse Launcher by Yatta, which extends Oomph, might also be interesting to you.
Yes if your eclipse versions match up. You can do it by straight filesystem copy. If its not same then metadata may create loading issue.
Eclipse crashed and deleted all project files, including written by me and XML files from another program which were not related to Eclipse.
Is it possible to force Eclipse or JVM to use trash can, so that if it goes mad and delete everything, files could restored.
UPDATE
Files were definitely wiped out. This was checked with third party file managers. Also entire disc were searched for traces.
Some good news is that Eclipse history remained. This allowed to restore some files I changed from Eclipse. But this project was consisting of multiple other files, that were written not by me (taken from other libraries) or contained some data I was editing not in Eclipse (like XML or raw data).
All these files were wiped out by Eclipse.
If this would not happen to me I would also say it is unlikely. But it has happened.
The problem is somehow related with
(1) Eclipse
(2) Maven (m2e)
(3) Eclipse RCP
(4) Tycho
At some moment Eclipse started to show numerous error windows and I was to kill the process. After that I found files absent.
So I need some extra protection layer.
UPDATE 2
Crash repeated. This is a message during file wiping out:
This time I was not using Maven and Tycho.
UPDATE 3
Third crash.
Crash occurs only after error Application ... could not be found in the registry, which itself buggie.
UPDATE 4
Still unable to reproduce situation from scratch...
UPDATE: I think from this question you were working on an Eclipse RCP plugin or something like that when this happened.
So you probably broke your Eclipse in some fashion. Do not trust anything Eclipse tells you at this point! Look at the actual filesystem!
Eclipse crashed and deleted all project files, including written by me and XML files from another program which were not related to Eclipse.
That's highly unlikely. (Especially if those XML files were not in the workspace. But even if they were, it's very unlikely.) You probably opened a new workspace without realising it, or maybe Eclipse has some bug where it won't show you files that are actually there. Or maybe you accidentally switched to the wrong view (in Java the normal view for files is Package Explorer, if I remember correctly).
Or maybe you were storing your workspace on a USB stick (aka pen drive) or network drive and you accidentally disconnected from it without realising it.
Check in the workspace (the actual workspace you were using at the time, not the workspace you are now using, which, as I said, might not be the same thing), using Windows Explorer (if you are using Windows) or Finder (if you are using a Mac) or using ls (if you are using something else). Are the files really gone?
This Was My Fault
I was setting up a workspace location pointing to project folder and also setting clear workspace checkbox.
::shame::
I recently deleted an account I was using on my Mac (Mavericks if means anything, although it shouldn't). I was using that account to run eclipse and saved all my files on a disc image before deleting. I took all the files and switched them into my current workspace but now they don't show up in the package explorer(although I can access them from My Documents). Can someone please tell how to make them show up in the panel? It's getting very time consuming to constantly have to open them through Docs.
If the files are in projects that Eclipse does not know about you need to do File / Import... / General / Existing Projects into Workspace.
If the files are in existing projects use File / Refresh to get Eclipse to pick up the new files.
If that doesn't work, you can always try recreating your project and then adding all the classes and other files through the file menu, add existing item. This way you can maintain the integrity of your project withouth having to change any of the packages or classes inheritance.
Hope this helps.
I am using eclipse 4.2 and Subclipse 1.8.20.
I am trying to add the contents of /WebContent/WEB-INF/classes to version control (this is also the default output folder of my project).
First let me state that this is possible with TortoiseSVN. I do understand why by default Subclipse ignores this directory, and I tried to change the Team settings, but I am not seeing a relevant entry for *.class files:
Is this at all possible with Subclipse?
More info:
Old an unanswered similar question: http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=473163
Same topic but opposite question: How can I ignore build directory in Subclipse?
It is a horribly bad idea to version your build directory. Every time Eclipse does an auto-build it will cause all of the files to need to be committed again.
To answer your question, all Eclipse team providers automatically ignore any resource that is marked as "Derived" by Eclipse. The Derived flag is set on files that are created by the Eclipse builders. If you select one of these files that are ignored in Eclipse, right click and choose Properties. Navigate to the Eclipse Resource page. There will be a bunch of checkboxes. You should see that one of these is labelled Derived and will likely be checked.
Do not try to change the checkbox value. I am just pointing out where you can see and confirm this.
I've been told that an Eclipse workspace is the equivalent of a Visual Studio solution. But I've also been told that people commonly use a single workspace for all their work. Are these apparently conflicting statements correct? If yes, how do we then create and maintain the equivalent of multiple VS solutions in Eclipse?
Secondly, in the case of VS, I check in my solution (.sln) files, too, into source control. Correspondingly, should I or should I not check in the Eclipse workspace's .metadata folder?
I don't think, the Eclipse workspace is equivalent to the VS solution. An Eclipse workspace stores a lot of meta-information about projects, their physical location (possibly in or outside of the workspace folder), etc., and even workbench settings. It is not a good idea to upload this information into source control, as it is possible that other developer uses other physical locations for the projects, etc.
There is a similar concept in Eclipse to the solutions (similar, not equivalent): Project sets. It is only a GUI option to group your projects into sets. These sets cannot be executed together, and is only visible in the Project navigator.
Another way is to create multiple workspace folders, and you can use them as an alternative to solutions. The drawback of this approach is, that if you customize the IDE (e.g. by using Preferences, or by defining source control locations), these customizations have to be made in every workspace. This issue can be handled using the Workspace Mechanic tool (I haven't tried it, but it can migrate these settings).
The main reason why it is better FOR ME to have a separate workspace for a single project is performance and lucidity. With many projects within one workspace, you'd have to close the other ones because of shared classpaths for editor assistance. Editor uses classpaths of all projects for content assist, class hierarchy lookup etc.
Eclipse anticipates that the open projects are related. And when using project managers like Maven, one maven project is usually divided into many little eclipse projects. It's simply a best practice to have a separate workspace for a project. Second reason is, that usually you'd need to import another related project to see how things are done and it would be terrible mess then having it all in one workspace.
You definitely shouldn't commit the .metadata folder into source control. You commit only the projects inside. Because you and others then will check out the project only into their own workspace. But it is a question whether you should commit the .project file, because it's personalized and eclipse version specific and things like project nature (java, spring, maven nature etc.) can anybody set up by himself. .classpath files in the project should be committed to the source control, because they specify classpaths, it would be very time consuming setting it up again.
You can either group your projects in different workspace or in a particular workspace. Non can be harmful once you manage your settings properly.
In eclipse you can create a new directory for a sub-project under the root project and add to the build path like so: