I have a checked-out version of the Redmine-Mylyn connector open-source project. There are eight Eclipse plug-in projects plus two Eclipse features projects plus .git/ as their sibling in the local file system. It turns out that after importing them as Plug-ins and Fragments (with options Projects with source folders) Eclipse recognizes all plug-in projects but net.sf.redmine_mylyn in the Git repository (i.e. it shows a corresponding suffix next to these project names in its Project Explorer view.)
So net.sf.redmine_mylyn is apparently not recognized with these apparent effects: it has no such suffix in the Project Explorer view and its Team menu list only Apply Patch ... (but no other option related to either Git or sharing). However, if I run git status from the command line e.g. on net.sf.redmine_mylyn/build.properties I can see that it very well also part of the same repository. The Project Explorer does not show the two feature projects at all.
What could be the reason that Eclipse (Kepler) apparently does not recognize one plug-in project in the Git repository and how could I make it do so?
UPDATE
Here is how the .project files are arranged in the file system (output from find . -name .project):
./net.sf.redmine_mylyn/.project
./net.sf.redmine_mylyn.api/.project
./net.sf.redmine_mylyn.api-test/.project
./net.sf.redmine_mylyn.common/.project
./net.sf.redmine_mylyn.core/.project
./net.sf.redmine_mylyn.core-test/.project
./net.sf.redmine_mylyn.core.extension.timesheet_extensions_plugin/.project
./net.sf.redmine_mylyn.extensions.feature/.project
./net.sf.redmine_mylyn.feature/.project
./net.sf.redmine_mylyn.ui/.project
The .project files reference three or four buildCommands (org.eclipse.jdt.core.javabuilder, org.eclipse.pde.ManifestBuilder, org.eclipse.pde.SchemaBuilder, org.eclipse.pde.ds.core.builder)
and two natures (org.eclipse.pde.PluginNature, org.eclipse.jdt.core.javanature). The offending project is one of those which do not reference org.eclipse.pde.ds.core.builder.
And find . -name .git gives:
./.git
Using the usual Import > Existing Projects into Workspace wizard, I could not reproduce the problem. I don't know what Import > Plug-ins and Fragments is supposed to do, but it looks like a bug in there.
I recommend filing a bug for Eclipse PDE and add the link to it here. Be sure to include the specifics such as which repository you used. A high quality bug report contains: A series of steps to reproduce the problem (like you would write in a short tutorial), followed by "this is what I expected to happend" and "this is what actually happened".
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.
Could someone explain to me how to properly check out the trunk from the SVN via eclipse?
Setup:
there is a /trunk/ that I need to check out in its entirety. There are tons of sub-folders, ie
/trunk/a
/trunk/b
/trunk/c
Each of them has different source files. For example, folder ../c/ would have c++ code
folder ../b/ would have java code, folder ../a/ would be just config files, etc...
Question:
How do I properly bring the entire trunk into the eclipse via the subclipse when I use 'Checkout'? Specifically, do I
1) Import using a New Project Wizard
OR
2) import the entire file system into the workspace
If 1) then what project type do I choose since my /trunk/ contains a conglomerate of different files pertaining to separate projects (even though .project is NOT present). For example, if I choose 'as Java project', then how do I run 'c++' code and vice versa. Or eclipse does not care and everything is contextual based on the perspective?
if 2) then how does eclipse know about inter-dependencies between the files and what compiler to use, etc. How does Eclipse know how to process the files (Highlighting, code )
Also, regarding the 'import the entire file system into the workspace', are we talking about the eclipse's workspace or a folder that I can choose to import the files to, which may or may not be eclipse's workspace?
Thanks!!
Eclipse generally wants projects to point to one thing. So your "a", "b" and "c" would typically be 3 distinct projects in Eclipse. You would check out each of them individually creating 3 working copies in the same workspace folder.
You can checkout trunk as a "Simple Project", but I am not sure there is any value in doing so. You would then need to Import the each of the 3 "real projects" so that you have 4 total. If these projects already have Eclipse .project files in them, this will generally be fairly easy to do. Otherwise, it depends on the current state of the various Eclipse Import and Create project wizards and whether they allow you to do this on the fly or not. I do not work this way, so I am not sure.
In my case, my trunk has a couple dozen Java projects in it. Each of those has the Eclipse .project and .classpath files checked in to them. I just checkout the individual projects.
Subclipse still allows me to do things like atomically commit changes for all projects in a single commit. There is not a lot gained by having their parent folder checked out.
We want to share an eclipse Qt project via an SVN repository.
Of course we need to share the .pro file of Qt to be able to build the project.
The problem is, that without the project files you can not handle the project in eclipse but we cannot use the same as they contain local references.
Also it would be nice to use the Eclipse SVN plugin to manage this.
I already tried to check out the project and create a Qt project on Checkout but this overwrites the checked-out project file.
Any suggestion would be appreciated.
These are some lines from the .cproject file that are autogenerated, so I can not change the absolute paths:
<storageModule moduleId="org.eclipse.cdt.core.pathentry">
<pathentry base-path="/usr/include/qt4" include="" kind="inc" path="" system="true"/>
<pathentry base-path="/usr/include/qt4" include="QtWebKit" kind="inc" path="" system="true"/>
...
There are 2 rules for Subversion (independent of Eclipse, should be the same all the time):
If the tool will regenerate a file, and you don't have to change it:
==> don't check it in your version management (may it Subversion, Git, CVS, ...).
If the file contains parts that are manually changed by a user
==> it should be checked into version management.
If you have the second case (not clear from your question), you should try to change the paths to be relative, so that others could use your project at the same location.
If you cannot change that, stick to the location in the file system. Every developer has to use an identical setup.
If you have to support different operating systems, and the files generated by the tooling are not compliant (shame on the tool makers), you should hold templates for all operating systems in your version management, and should initially (manually) make a copy, depending on the operating system you are working in.
If you have to change that file for some purpose, you have to change the templates as well and should remember that all developers have to make a new copy after that.
Sorry, I don't know Qt and have never developed in a C-environment on different platforms, so my tips are pretty vague.
Finally I found following solution:
No .cproject .project file in SVN!
Import the code files from SVN (also the .pro file for Qt)
Eclipse will ask you to create a project, so create a Qt Project with the same name (or some else, but you will then have to delete the files)
When the project was created, revert it (right MB on the Project in Project Explorer -> Team -> Revert) to the state of the repo checkout
Done, now you can work with the project
I'm trying to re-familiarize my self with the Eclipse environment and ant integration.
Question is: how to keep my sources dir + build.xml separate from the workspace?
What I have is
a small java project and its build.xml file with all the sources placed under a separate
project folder. I then started Eclipse and let it import my project via
New Project -> "Java Project from existing Ant Build File"
All went fine, until when I wanted to build the project from inside Eclipse using build.xml.
Ant starts complaining about not being able to find the source tree. After I examined
the workspace I found that Eclipse had copied the build.xml into the workspace, so it's
obvious that ant couldn't find any sources there. They are still under my project director
and I do want to keep them there, if possible.
so whats the best way so make this setup work? workspace on one side, my project on the other?
Thank!
edit: Is what I want even possible ?
Instead of using "Java Project from Existing Ant Buildfile", just create a simple "Java Project". In the wizard uncheck "use default location" and enter the path (or browse) to the top level directory of your existing project (i.e., where your build.xml is). True, eclipse will create .project and .classpath files in your project directory (if they do not already exist), but the project will remain outside the eclipse workspace.
Case in point, this setup has worked really well in a very particular situation on a standalone system where the source tree resides in a common location but each user has a workspace in a protected location. Using the method described above, each user of this system can create a project in their own eclipse workspace, execute ant targets and subsequently remove the project from their own workspace without affecting other users' workspaces.
What about using links?
Windows Symbolic Links
Linux man page for ln
I do this all the time in C++ projects (no Java, sorry, but I think the concept is portable).
I have my workspaces in ~/workspaces/{workspace_name}. I have a single shared project file in ~/{my_projects, and then the source trees (multiple versions) are in ~/proj1, ~/proj2, etc.
Within each ~/proj* directory, I put a symlink to ~/my_projects/.project and .cproject (required for C++, not used in Java). So each source tree is sharing the single project file. Then in each workspace (one for each source tree), I configure the workspace by importing the project link. For example, ~/workspaces/proj1 imports ~/proj1/.project, but ~/proj1/.project is actually a symlink to ~/my_projects/.project.
So this keeps the source separate from the workspaces. When building, there's no real configuration to do -- I just have Eclipse run make in the appropriate node of the tree -- we already have our own command-oriented build system (we're not using ant, but the same principle should apply).
I source-control the ~/my_projects folder in a private area of the SCM, so other team members don't see it or fiddle with it -- many of them don't use Eclipse at all.
There isn't really any need to try and avoid Ant and Eclipse using the same set of source files. In fact, its probably better that they do use the same set.
Bear in mind, you're not actually mixing anything. There is just one set of source files and then there are two different ways of building it; Ant and Eclipse. These builders are independent of each other, so there is no problem with being coupled to Eclipse. You can even happily commit all the eclipse files (.classpath, .project, .settings) to source control without affecting any developers who use a different IDE.
I do this all of the time (admittedly using maven, not ant), but the same principle applies.
If you have an existing project in Eclipse (with the .project in the source tree), then you can Import Project->Import Existing Project. When the dialog box comes up, you can choose to 'Copy projects into workspace'. Make sure this is unchecked, and them import.
You still store the .project in the original source tree, but thats all.
So now I have
code/xxx (which contains the .java files, which are in SVN)
code/xxx-workspace (which contains the eclipse workspace)
I'm trying to transition to eclipse+pydev but am having a problem importing projects under scm. My old projects (and also projects on github) don't have the "src" parent directory that pydev seems to really like.
If I use egit or subclipse to import/check out the project, the pydev environment is incomplete. If I externally check out the source and move it into place, I don't seem to be able to tell eclipse it's SCM'd.
I would think this is a FAQ, but I can't figure it out. What is the best practice to use SCM'd projects under eclipse that aren't SCM'd as eclipse projects.
Thanks. Kent
Choose the properties for the project. Then change the pydev-PYTHONPATH - remove the src entry and then add the directory of your project that contains the source.