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
Related
Every time I boot Eclipse I get the error "The project description file (.project) for my project is missing".
As other StackOverflow answers have show, this is easy enough to fix: delete package from Eclipse and import it again. However, if I close and reopen Eclipse the error will be back. I have not found a permanent solution yet.
I have my workspace in my Dropbox, but at some point I decided it was time to start using Git. I don't really get Git but they say you have to put the .project file in your .gitignore because it is computer specific.
This I feel is the origin of the problem, but if I don't do any git related activities (push, commit, etc.) I still get this error.
How do I fix this once and for all?
A .project is a Eclipse-specific file that tells Eclipse about how the project's struture is placed in the project's hierarchy.
It's normal for this file (and other Eclipse specific files) to not be committed because other people participating on the same project may use other IDEs of their choices (intellij, and so on), so the content committed in your VCS is 'neutral' for IDEs.
When you create a project from inside Eclipse, the .project file shall be created along. But when you import into Eclipse an existing project, there are ways to generate locally the .project , .classpath and other Eclipse-required files. Maven, Gradle and Ant are some examples of tools that do this.
Finally, I recommend to keep these files in .gitignore so the project's contents in VCS will remain neutral to IDEs. So you will not bother other people using other IDEs.
So, the steps are:
Check out the project
Generate the eclipse files using maven, ant or gradle. If your project already uses a tool such as these, thats nice
Check if the project is OK inside eclipse (compiling, no errors)
Add the newly generated eclipse files to .gitignore
commit and push the .gitignore.
.project is not machine-specific as long as everyone on your team has the plug-ins installed for that kind of project. .classpath might be if you don't do things right. This is your project, though, so commit your .project.
Keeping .classpath clean largely revolves around keeping machine-specific paths and references out of it:
Set the project's JRE using an Execution Environment. It is an indirect way of saying what version you need, then the IDE figures it out for that machine. The stored value defaults to using the name of your default Installed JRE in the preferences, which is very machine-specific.
Put the jar files you need into the project, or into another project that this one can refer to. They go into source control as well for the sake of repeatability, unless you're using a tool like Maven, in which case be specific about the version you require where ever you state that dependency and make sure the relevant M2E plug-ins are installed.
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.
My Eclipse recently broke completely and I have upgraded to Galileo. I have created a fresh workspace (say foo/workspace) and created a trivial project. I have then copied an old project from (bar/workspace/myproject) to foo/workspace/myproject. It is mavenised and has a pom.xml. How do I tell Eclipse to build it (it does not seem to recognise it is mavenised). Do I have to install the maven plugin?
In general what is the smoothest way to reinstall Eclipse (i.e. what else do I need to think about?)
I never create or checkout a project directly under the Workspace but rather use something like ~/Projects for all my projects. This allows me to remain IDE independent. Actually, I never use any IDE to create a project.
I share my workspace location across several Eclipse install (specified at startup or using -data). If anything goes wrong, I don't mind deleting and loosing my workspace, it doesn't contain anything really important anyway.
Use the m2eclipse Eclipse plugin to Import > Maven Projects into Eclipse. Another option is to use the maven eclipse plugin to generate the .project and .classpath from the command line and then to Import > Existing Projects into Workspace from Eclipse.
It is better to reference directly your old workspace when starting your new eclipse installation: see this eclipse.ini
-data
c:/a/path/to/your/old/workspace
That way, you get back all your projects.
You can install the m2eclipse maven plugin by adding its update site to the list of sites examined by the eclipse p2 provisioning mechanism
http://m2eclipse.sonatype.org/update/
If the metadata associated with your workspace is messed up, and it sounds like it is, the easiest thing to do is simply delete the .metadata folder from the workspace (or rename it to something else). Start up Eclipse, it will show an empty workspace, and then use File -> Import to import existing projects back into your workspace. Just point it to the folder of the existing project and it will do the right thing, leaving the project in place.
For the maven stuff, the Import Maven projects mentioned above seems right and probably does some other stuff to have maven work out.
I've got a working copy checked out with svn; furthermore, I've created a new project in Eclipse that has the root of the working copy as the project's location. I want to be able to do stuff like compare versions from Eclipse. I have Subclipse 1.4.8, but that doesn't seem to give me what I want. Am I doing something wrong?
i have an svn working copy that also is a project in eclipse. after installing the subclipse plugin i had the same problem, the working copy was not recognized as such.
i just managed by chance to get it recognized as an svn working copy by renaming the project in question and then renaming it back to its old name. not very nice, but it did the trick :-)
There is an option when creating a new project, to use an existing source directory:
New project/ new Java Project / Create project from existing source.
Use that, tell it where your source lives, and it should automatically detect if it's a SVN working copy.
I guess this is not possible with Subclipse as it's given in its documentation that, you can only import an existing svn-managed folder under one condition, according to the doc:
"The only requirement is that your
working copy has to also be a valid
Eclipse project."
So, if you have a working copy that is not a complete eclipse project, Subclipse will not connect it to SVN.
You can right click on the root node of your project and select: Team / Share project
Then you choose SVN, let the default settings and it should work fine!
I am answering this after a long time of the question being asked. I ended up here because I was facing the same problem.
My solution was to create an empty .svn folder at the root folder of the project (in the latest version of svn client tortoise all meta-data is at the root folder). Then did an eclipse refresh and voila it did the trick. I am running subclipse core - 1.8.4.
One step that seemed to work for me, that no one has explicitly mentioned yet: I closed and then re-opened the project. I tried the "rename" trick, above, and that didn't work, but perhaps the poster of that answer also closed the project - they didn't detail exactly what steps they went thru to rename it. (I found you don't have to close the project to rename it, but perhaps they did.)
< /rob>
In my case, I couldn't use an existing copy because I checked out the code using a newer version of Subversion on the command-line and Subclipse 1.4 couldn't recognize it. Upgrading and going through the improved "Share Project" menu resolved the problem.
I got this tip from the forums here:
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2380064
I had the same issue and here are the details of the fix.
My Eclipse is "Helios Service Release 1".
I had an SVN checkout on my filesystem, I went to New Java Project, unchecked Use default location, chose the location, went to next step, chose the source folder and said Finish.
The project came up with no disk icon on it. As per few forum posts, right-clicked on the project, went to Team > Share Project, chose SVN, clicked Next, and the option was only to share the files to the SVN Repository for the first time.
I said Cancel, and the option is to make changes to the SVN plug-in settings. Went to Window menu, chose Preferences, browsed Team> SVN. Chose the SVN Connector tab, changed the SVNKit 1.2.3 to SVNKit 1.3.5 and said OK.
Then, right clicked on the project, said Team> SVN, on the next screen, chose the option Use Project Settings and clicked Finish. The disk button came to the project and the SVN URL got displayed on it.
Add the repository to your list of repositories in subclipse by choosing Window->Show View->Other... and choose SVN->SVN Repositories. Put in all the necessary info to connect to the repository.
Next, right click the repository and choose "checkout". If the project doesn't already have an eclipse .project file, you can create a new project from the source. If it already has a .project file, it will import that .project and use that as your eclipse project locally.
It will definitively not work if you use a different version of svn to checkout, that the one that is supported by Eclipse. I had this problem as I used svn 1.6 to checkout but I had an older eclipse version that had only 1.5. Subclipse has its own build-in svn client (Actually, in two flavors if I am not mistaken).
Check that the subclipse version matches the svn client that you used to checkout. You can check the plugin version number for subclipse (Help -> About -> Click on subversion logo) and match it against svn --version
This worked for me:
1) Go to the 'SVN Repository Exploring' perspective and add a folder somewhere above your working copy
2) Close and open the Eclipse projects.
This should then be enough to get them recognized by Subclipse.
I have encountered a similar situation were existing projects would not get associated with the Subversive plugin. Unfortunately, none of the previous suggestions helped (renaming projects etc.). What has helped is removing projects from Eclipse by deleting them -- just the projects from Package Explorer and not the actual directories and files on disc (the deletion prompt has a special checkbox for that, which is unchecked by default) -- and reimporting the deleted projects as existing projects back.
Of course, as mentioned in some of the answers here, the relevant SVN repositories need to be registered with Eclipse before reimporting the projects. Otherwise, there would no repositories to re-associate the projects with.
When you open a versioned project (i.e., a project in SVN working copy) in Eclipse, that was never previously used with Subclipse, you need to perform these steps:
Right-click the project in Project Explorer.
Select Team | Share Project.
At this point Subclipse will tell you that "The project is already configured with SVN repository information". Click Next.
Subclipse automatically recognizes this project as versioned and all the features of the SVN plug-in should become available.