I have a project I checked out with svn at work. It has the following associated with it in Package Explorer view of Eclipse:
project[trunk]
project-adhoctest[trunk/adhoctest]
project-jar[trunk/gazelle]
project-war[trunk/webapp]
Now I have a file in the project jar directory that I have put a breakpoint in. What is weird is that when debugger is launched, it always goes to the project[trunk]. This is really bad because I need to debug changes I make, not the trunk I checked out, but in project-jar.
The only other details is that I used maven to build dependencies when I imported this project. But, to make sure I did that right, I deleted everything and checked out this project again. Still same problem. I goggled quite a bit and asked others at work what could be going wrong, but haven't found a fix yet.
I use Eclipse Juno, 4.2.2
Thanks,
GeekyOmega
The problem is the build path was wrong, for me. It was looking at the entire workplace and choosing the trunk. When I re-installed eclipse, when I first ran debug, it asked me for the build path. I pointed the build path to the project folder project-jar instead. This fixed the issue for me.
You must go to run-->debug configuration and add the branch project in the Source tab
Related
I have cloned my Liferay 7.1 workspace from my Github repository. When I try to get Assistance in Liferay IDE using Control+Space, I get error:
This compilation unit is not on the build path of a java project
This happens on the new module project created in the same workspace(that was cloned from Github).
But when I create/import module from my local workspace that was created by Liferay for first time, this issue is not there.
I feel like there is some extra workspace setting that I am not doing in my Github workspace. Like we had to create build.username.properties in the SDK folder for Liferay 6.2. Totally stuck and no solutions anywhere.
I tried fixing Project Build path and Project Facets but did not help.
The way you did it in your own answer obviously solved it. My take on this is: The problem was most likely the .project file, because it contains all the configuration that eclipse requires, and the error message you post is an indicator that eclipse doesn't know what to do with these files.
The .project file can be regenerated from gradle settings, typically by choosing "gradle / refresh" (from memory, from the context menu of the project/workspace in Project Explorer), which will read the gradle settings and apply them to the eclipse world. This might happen automatically, but it might also need some manual push - next time you might want to try this, because just copying random files rarely is a good idea. You might end up pointing to other directories far outside of your workspace, and wonder why a local change is not picked up.
There were some differences between the workspace that I imported from Github and the one that Liferay was creating on my local. I opened both the workspaces in Beyond Compare. Following are the files that had major differences. I made them same and it started working after Gradle Refresh in Eclipse.
liferay-workspace/gradle/wrapper/gradle-wrapper.properties
liferay-workspace/.project
liferay-workspace/gradle.properties
liferay-workspace/gradlew
liferay-workspace/settings.gradle
I have a project that has lived in my workspace for some time. It is a git project and I use Egit and cygwin git to manage it. Not sure if that's relevant.
I'm not sure what's messing up eclipse but, in the last day, I have noticed that when I start eclipse, my project is marked as closed. When I looked at the project properties, I saw that eclipse is using the wrong path. Instead of:
C:\cygwin64\home\rcoe\git\projectname
it is now pointing at:
C:\cygwin64\home\rcoe\.gitconfig\projectname
However, my .metadata .location file (which is binary) shows that the location is correct. This file is buried in my workspace, which is located in my Windows home directory.
I tried deleting my project and re-importing it, both as a git project and as a general project, and it opens no problem. I can even close and open eclipse right away and the project stays open. However, give it a few minutes and re-open eclipse and the project now thinks it lives under a non-existent .gitconfig directory. I even tried creating a new workspace and importing my project. Same behaviour.
So, I'm not sure whether this is an Eclipse Mars bug, or Egit, or something else. Has anyone seen this kind of behaviour before?
Edit:
I hit new snags trying to share my project using Eclipse 4.4. The Luna git plugin threw errors about the plugin. So I went back to Mars (4.5) and created a new workspace. The .location file looks like this
#±‹#¼ %–磓¾ 2URI//file:/C:/cygwin64/home/rcoe/git/logprocessing ÀXûó#¼ QóŒ{»wÆ
but when I open Eclipse, the properties of the project looks like:
C:\cygwin64\home\rcoe\.gitconfig\logprocessing
I have no idea what Eclipse is using for its location, if not the .location file.
I found what looks to be a solution. I moved the .gitconfig file from my cygwin home, which is where Eclipse was configured to look for it. On starting Eclipse, I was able to import my project without error. And even though Eclipse's previous error messages implied it wanted to write to the project directory beneath a .gitconfig directory (cf. https://bugs.eclipse.org/bugs/show_bug.cgi?id=473782), Eclipse did nothing of the sort.
I am now able to restart Eclipse, run my unit tests, etc., without error. I am also able to interact with my Git repo using Eclipse, even though Eclipse no longer points at my .gitconfig and so does not know my user.name or user.email properties.
On Windows, it would be best to use git for Windows instead of git in Cygwin. It comes with Git 2.4.6 released 5 days ago.
That way, Eclipse doesn't have to manage two different filesystem, and two different HOME (C:\cygwin64\home\rcoe vs. %USERPROFILE%)
I'm using Eclipse Modeling Tools (Version: Indigo Service Release 2 Build id: 20120216-1857).
One of my projects in the workspace has disappeared from the Package Explorer (the View of all projects). Or better said, it is in the list, but it seems closed and when I try to open it, I get this error message: "The project description file (.project) for 'xxxxx' is missing. This file contains important information about the project. The project will not function properly until this file is restored."
What I really worry me: the project folder isn't available on the filesystem either.
I don't know why or how ... the only thing 'different' that I can remember is that I have switched the workspace to a new one, when that project was open.
Any idea to recover the folder/project?
Maybe you moved it by a mistake?
Check the other workspace (on filesystem) or maybe the project is in another project.
You should always do backup's or/and checkin in a VCS.
A recovery-tool can help, if the bit's are still there.
Good luck.
What is the advantage with not having a build path in eclipse? Why is that setting default when it's like something you'd never use? It seems eclipse indigo was developed to make software development as obscure as possible. I just checked out a fresh copy of the project I checked in (called dungeonworld) this afternoon from another computer and automatically nothing works, can't compile, can't choose build path, can't add jre, can't add jdk, can't add that to project properties.
Is my eclipse broken? I can't believe this is happening, such an easy thing not feasible.
Nothing above solutions worked for me so i tried below
Right click on project >> properties >> project facets >> click on java
It looks like you did not add Eclipse project metadata files to your source control system, so Eclipse doesn't know what your build path is or whether it is even a java project. You can see that the little folder on your dungeonworld project is missing the little 'j', which means Eclipse doesn't think it's a java project.
Go back to your other computer and look for the following files in your original project root...
.project
.classpath
.settings/*
Make sure all of the end up in your source control system or nothing will work right.
I have same problem, but i have solved
project right click -> properties -> java build path -> src/main/sources
all remove items on "Excluded", and then that item turn the status "(None)"
I tried below steps and it works for me.
Right click on project >> properties >> project facets >> click on java
Eclipse has a build path.
It's stored in a (by default hidden) .classpath file in your project.
You can also access it through the UI in project properties (right click on your project, properties, java build path).
Well, this is probably not your problem, but similar is happening if you are in Eclipse different perspective (for example for Python).
vs.
There where no entrys after right click on my projekt in Eclipse. How to click something, wenn build path entries are missing. So my Eclpise didn't detect my java project. I used following Maven command and after that I cleaned the project too. Now Projekt works as expected. So...
If you are using Maven, try mvn eclipse:eclipse in cmd console in your project directory! Make sure to use the path to your Maven folder for the command.
For example:
cd C:\yourEclipseProject\
C:\yourPathToMaven\apache-maven-2.2.1\bin\mvn eclipse:eclipse
This was helping me. After unsuccessful web research, a coworker told me this tip.
I just had a similar problem and I figured out that I had been choosing General Project instead of Java Project while creating a project. After I chose Java>Project it solved my problem. Maybe it'll solve yours as well.
After choosing that, eclipse automatically included java libraries as well.
It's not a good practice to commit IDE related files into source control. What if someone in team uses different IDE? It might have been only option at a time when OP asked this question.
New versions on eclipse (4.x) takes care of this automatically. Probably by observing what kind of source and build files you have in your project.
Don't know the reason. But this works for me, so posting it.
Right click on project -> 'Properties' -> 'Java Build Path'.
I recently moved my Eclipse workspace directory and now Subclipse complains every time I open a file, dumping to the console something like:
Path is not a working copy directory
svn: '[original (pre-move) directory path]' is not a working copy
No such file or directory
This also happens when I explicitly try to view the history of a file. This persists across SVN cleanups, closing and re-opening Eclipse, etc.
Update, checkin, checkout and so on all seem to work fine, and Tortoise doesn't complain at all, so clearly it's not the SVN metadata that's screwed up, it's some Subclipse-specific metadata. Can anyone tell me how to blow this broken metadata away?
Edited to add: "Team > Disconnect" followed by "Team > Share" doesn't solve the problem.
Edited again to add: I've grepped through the whole .metadata directory and one of the project directories for a unique element of the old path and can't find it anywhere except in .metadata/.log (the error message itself) and some old Findbugs warnings. Very nice.
You need to delete the .syncinfo files. This is easily done (in most cases) by closing and opening Eclipse, however you can also do so manually as in the following:
To delete the cache, close Eclipse. The cache is stored in:
[workspace]/.metadata/.plugins/org.eclipse.core.resources/.projects/PROJECTNAME/.syncinfo
So you can just find and delete all files named .syncinfo in
[workspace]/.metadata/.plugins/org.eclipse.core.resources/.projects
Quoted from this article: http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=868799
I just did a "Team -> Cleanup" and this exact error went away! I also got this error because I moved between machines and the path wasn't the same.
Using Eclipse 3.6 and the Subversion 1.6 plugin.
Update in 2016: Still works perfectly with Eclipse 4.5.2 and Subclipse 1.10.
Edited to add: Nope, spoke too soon. This doesn't fix it. Some files just seem not to exhibit the problem.
The following seems to solve the problem:
Team > Disconnect.
Quit Eclipse.
Blow away .metadata/.plugins/org.tigris.subversion.subclipse.*.
Restart Eclipse.
Team > Share.
Not sure how the old path was actually being stored in the plugin prefs, but it must have been in there somehwere. It's kind of pathetic of Subclipse to store absolute paths, but apparently it is.
There's a bug filed on this, or at least on the same error message. No context. Fifty cents says it gets rejected.
I'm sure there are many causes with different solutions, but I found the one that worked for me at Dan Wilson's blog. Simply remove the offending folders from the workspace (probably saving them if they have new content), update (letting Subversion recreate the folders), then move the contents back into the fresh folders in your workspace.
I got the error when I tried to rename a class by changing the case from DAO to Dao in Eclipse.
I had to rename it to something like Dao2 and then was able to rename it to Dao.
What worked for me:
Do a "refactor - rename" on the project => after that do it again to rename it back to the original name.
I was having the same error message using subclipse with javahl on a project that is out of the workspace directory. Changing to svnKit has resolved my problem.
Hard to say without further information.
Did you move the whole workspace or just the content?
Also, you can try creating new workspace from scratch and check out the whole project again.
Alternatively, you may try deleting the .metadata directory and relink the project again using File -> import -> existing project into workspace and then relink the SVN data through Team -> Share projects (with an 's'), or maybe just do this last bit after first disconnecting the project from SVN.
Right click the project folder : Team -> Update to Head
This will bring back the directory. Delete it again and Commit
In my case I had the folders of the projects in the Project Explorer and just had to reopen the project
For me, this error message was caused by an out-of-date installation of Subclipse, and the underlying SVNKit and JahaHL libraries. I have been using TortoiseSVN outside of Eclipse to manage my project directories, and my recent upgrade to the 1.8.x series of (Tortoise)SVN tools broke my working copies for Subclipse.
All I had to do to fix, was go to Help->"Install New Software..." and click "Add..." to add a new update site. I picked the latest update site for the latest release on http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA and upgraded Subclipse from there.
Then all my existing projects just worked, and I could reconnect to the one I had already tried disconnecting from without problems.
I have the same problem
I had a new project, added it to SVN. Then everything works as normal, until I try and refactor-rename any java file, I get:
move D:/dev/sk_ws/ge-parent/ge-core/src/main/java/com/skillkash/ge/beans/Skbean.java D:/dev/sk_ws/ge-parent/ge-core/src/main/java/com/skillkash/ge/beans/SkBean.java
Path is not a working copy directory
svn: Path 'D:\dev\sk_ws\ge-parent\ge-core\src\main\java\com\skillkash\ge\beans\SkBean.java' is not a directory
Now the SVN URL is:
svn://qnap/share/MD0_DATA/svn/sk/ge-core/trunk
and the repository root is:
svn://qnap/share/MD0_DATA/svn/sk
Obviously just sharing the project then trying to move a file using subclipe does not work - it must be a bug. I have to do all my refactoring outside eclipse, and hand edit all the files which are affected.
checkout the whole project to a temp dir, then I copied the first level .svn directory and replaced my working copy .svn folder with this.
http://blog.itopia.de/directory-svn-containing-working-copy-admin-area-is-missing/275
It woks for me.
I had added a png file to my project, but I got this error trying to rename or delete it. Cleaning and refreshing the project didn't do anything.
I went into the svn Team Synchronizing perspective, right clicked on the file and deleted it. That solved my problem.
Right click on the project and select Teams -> Switch to another Branch/Tag/Revision.
Select the appropriate Branch/Tag/Revision that the project should be tied to and click OK.
Give Eclipse some time to process the changes.
Restart Eclipse for the changes to take affect.
I just got this error when I was trying to update some .java files. The problem was I was trying to update the files but the folder that contains that files didn't exist in the path so when I sync and update the folder it works at the first try.
So, dont try to sync files, try to sync the folder.
Sometime ago I had a similar issue. Seems that Subclipse (or Eclipse) stores the absolute path of your working copies. The cleanest solution is to export again your repository to the new path.
If you have non-committed code, then you can copy it on top of the clean export (without the .svn folder)
I too had this issue and I simply deleted the project from the workspace (leaving the files on the files system in tact).
I then imported an svn project into the workspace.
Import->SVN->Checkout Project From SVN.
I used my existing repository location to pull the files in.
This issue was caused when I changed Eclipse editions and used a Subclipse plug-in that was a version ahead of what I should have used.
I uninstalled the newer version and installed the correct older version and all worked well.