I am the only developer on this project.
I would not add the complete workspace, but I would add the .classpath and .project files (as well as the source, of course) so that you can recreate the project if needbe.
I wouldn't commit the whole workspace. But it is worth exporting platform settings and checking them into source control (probably in a separate SCM project as they don't really belong to any individual project) if you've made several changes in case you need to import them into a new workspace.
Examples of these files are those settings for:
Java->Code Style->Formatter
Java->Code Style->Clean Up
Java->Code Style->Code Templates
General->Editors-Text Editors-Spelling-Dictionary
Any other preferences you've made extensive changes to that support import/export
You should check in the primary sources/resources for the project. As others have noted, for a typical project this includes the .project and .classpath files.
Depending on the type of project, I'd add the .settings folder from the project. This folder contains project-specific settings that override the platform preferences, and other project-specific settings. If those are essential to your project then I would add them.
No.
Files that are generated by the IDE or by a build process (binary files, documentation produced by a generator) should not be checked into source control. The only files that should be checked in are your source files and external libraries that your source files utilize.
You might also be interested in the answers to this question: What should NOT be under source control?
I would commit only the project(s) you are working on, as well as .classpath and .project files, and not the whole workspace itself.
Even if you are the only developer, avoid committing the .settings directory. You could switch to another version of Eclipse, or another installation with a different set of plugins, and when you checkout projects in the second installation the .settings directory will be different. Also the .metadata directory is bound to vary.
That said, attempt to use Maven so that the Eclipse .project and .classpath files can be generated without requiring them to be checked in.
I've played with the idea (with Subversion) of having a "MyProject_Eclipseproj" folder that only contains the the Eclipse project files and directories, with an svn:externals prop that pulls in all the "MyProject" files/directories.
So, the layout would be:
/repos/trunk/MyProject
/repos/trunk/MyProject/build.xml
/repos/trunk/MyProject/src
/repos/trunk/MyProject/src/com
/repos/trunk/MyProject/src/com/mypackage
/repos/trunk/MyProject/src/com/mypackage/MyClass.java
/repos/trunk/MyProject_Eclipse_34 <- external prop goes here
/repos/trunk/MyProject_Eclipse_34/.settings/
/repos/trunk/MyProject_Eclipse_34/.project
/repos/trunk/MyProject_Eclipse_34/.classpath
/repos/trunk/MyProject_Eclipse_35 <- external prop goes here
/repos/trunk/MyProject_Eclipse_35/.settings/
/repos/trunk/MyProject_Eclipse_35/.project
/repos/trunk/MyProject_Eclipse_35/.classpath
The MyProject folder would be pure code, no eclipse contaimination. The MyProject_Eclipse_Ver would contain Eclipse specific files, and pointers to pull in the code folders. You could also have specific folders for different Eclipse versions so each developer wouldn't be forced to upgrade if something changed in the .settings or .project file between versions.
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.
Is it possible to create one project in GitHub, and two teams who are using different IDE like Eclipse and Intellij can configure project with github and can work simultaneously on same project?
I have searched it but not able to find proper solution for it.
Yes, you even can version:
your .project and .classpath (eclipse)
and your .idea folder (intellij)
And both set of IDE-specific files would ignore each others: one could use the Eclipse settings without realizing there is an IntelliJ IDEA project, and vice-versa.
Yes this is possible.
Most IDE's do create some specific project folders, where the IDE does store Data for your project. As example local build paths and so on.
Git provides the .gitignore file.
In this file you can specify which folders and files git will ignore. As example IDE Based files and folders. Due that every developer can his favourite IDE and no local IDE based files will be in the Git Porject itself.
Most IDE's will update or crate the .gitignore File automatic when they do find an git folder in the project.
What files you have to add to the .gitignore file is differs from IDE to IDE. It also depends on what Programm language your Project is written in.
Here you can find more about the gitignore file:
How do I ignore files in a directory in Git?
http://www.bmchild.com/2012/06/git-ignore-for-java-eclipse-project.html
Yes you can, there no limits on IDEs and number of team members, check this for Eclipse
and this for IntelliJ
Running OSX.
I have used eclipse for years as a Java developer. I am now messing with all kinds of new technologies but still find myself using svn (don't ask its not my descision). Anyways I don't really like SVN command line as I find it almost impossible to sort through merge conflicts.
With that I was thinking about using eclipse (w/ subclipse plugin) as my SVN client whenever I need to do SVN type things. The one problem that I have found is that eclipse loves to create a .project file. I would never want to check this in as no one else is using eclipse. I know that I can add it to svn:ignore, but that has to actually commit that ignore to SVN as well, which I do not want to do either.
Anyway to create eclipse projects without the .project file. I know sounds dumb because I am sure that eclipse needs the .project file for all its projects. Would be nice just to create an SVN project (not Java project) and have eclipse leave off any other crap.
ideas?
There is no way to create an Eclipse project without the .project file (at least none that I know of), but you can tell Eclipse which files to ignore, as well.
Just go to Preferences -> Team -> Ignored Resources and add the pattern .project.
This setting is purely Eclipse-internal and does neither affect your global svn-ignores (defined in ~/.subversion/config) nor will it add any files to the repository.
Also, when checking out folders from SVN using Eclipse, make sure to create a General Project, not a Java Project, so the .project file is the only file Eclipse creates.
.project is actually not the only file that will be generated - depending on the "project natures" you add to a project.
To really separate the project from the source folders, you'll have to create the project in a separate folder - say the workspace - remove the original source folder and add the source folders as external links - see: Project Settings/Java Build Path/Source.
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)
We normally use Eclipse for a particular Java project, but recently I imported the project into NetBeans to use its dialog building features.
Since I'll probably come back to this, I wanted to store the NetBeans project files into version control. However, I don't want to commit files that are "mine" versus "project", i.e., files with my own settings that would conflict with another user's.
NetBeans created the following structure in the top-level project area:
nbbuild
nb-build.xml
nbproject
<various files>
configs
private
Clearly nbbuild is build output, so that won't go in. The nb-build.xml file seems likely, as does most of nbproject. However, nbproject/private suggests it's "mine". Peeking at "configs", it's not clear to me if that's mine or project...
Anyone have some guidelines?
The NetBeans knowledge base article on project files & version control discusses the NetBeans project files, with loose advice about which files are project specific (i.e. can be shared via version control), and which are user specific.
Here is the section on version control:
If the project is checked out of a version control system, the build (or nbbuild), dist (or nbdist), and the nbproject/private folders should not be checked into that version control system.
If the project is under the CVS, Subversion, or Mercurial version control systems, the appropriate "ignore" files are created or updated for these directories when the project is imported.
Though nbproject/private should be ignored, nbproject should be checked into the version control system. nbproject contains project metadata that enables other users to open the project in NetBeans without having to import the project first.
It turns out that both Thomas & Petercardona are correct, in a way. NetBeans recommends that you only import source code and/or documentation. Oh and the nbproject folder but not the *nbproject/private** folders.
From the NetBeans Knowledge Base article on importing Eclipse projects:
Version Control Considerations
If the project is checked out of a
version control system, the build (or
nbbuild), dist (or nbdist), and the
nbproject/private folders should not be checked into that version control
system.
If the project is under the CVS,
Subversion, or Mercurial version
control systems, the appropriate
"ignore" files are created or updated
for these directories when the project
is imported.
Though nbproject/private should be
ignored, nbproject should be checked
into the version control system.
nbproject contains project metadata that enables others users to open the
project in NetBeans without having to
import the project first.
None.
Only source files, build scripts, and documentation that is not automatically generated (e.g. - the output of tools such as JavaDoc and Doxygen) should be checked into a repository. Things like project files, binaries, and generated documentation should not be checked in.
The reason is two-fold. First, you don't want to overwrite another developer's project settings with your own. Second, other developers might not be using the same IDE as you (or even an IDE at all), so don't give them any more than they need to build (the project or its associated documentation) or run the project.
As tested with Netbeans 6.8, only the project.xml, configurations.xml and the main makefile (the customisable one in the parent dir of the 'nbproject' dir, with pre/post target definitions) must be distributed via the repository. All other files will be automatically (re)generated by Netbeans (Makefile-impl.ml, Makefile-variables.ml, all the Makefile-$CONF, Package-$CONF.bash). The 'private' dir should also be ignored, obviously.
You can check also
https://github.com/github/gitignore/blob/master/Global/NetBeans.gitignore
This open source project contains
A collection of useful .gitignore templates
Toptal has a useful tool for developers wanting to find out what should go on a .gitignore file.
https://www.toptal.com/developers/gitignore
For netbeans, just search Netbeans and it should return a template something like
**/nbproject/private/
**/nbproject/Makefile-*.mk
**/nbproject/Package-*.bash build/
nbbuild/
dist/
nbdist/
.nb-gradle/
Copying and pasting this into a .ignore file on your project's directory should solve your problem.