I'm working on a new project with a full ANT build. I use eclipse to write my code, and I would like others to be able to check out the project to have a full working eclipse workspace. I do not want to have specific user settings committed though.
What files and directories should I have in source control?
(I'd rather not just go grab a plugin - I prefer more control over what goes in the repository)
We just put .project and .classpath in our repository, and that's sufficient to make it work "out of the box" for new developers. I'd like to have other stuff (run configurations come to mind), but haven't figured out how.
We use Subversion, so I put these files in a separate directory and defined svn:externals on that directory to point to the actual code, leaving it unpolluted by IDE-specific files.
Per request in the comments, here are the external that we use. Nothing complicated going on here:
Properties on 'svn://dev/trunk/IDEs/eclipse/runtime':
svn:ignore
bin
.fbprefs
cobertura.ser
.settings
svn:externals
lib/bin svn://dev/trunk/lib/bin
runtime svn://dev/trunk/runtime
Related
I want to build my portfolio on GitHub. I have a few Java projects and I used Eclipse to build them. How should I share them on GitHub?
Should I share only the src folder? That way, however, I would end up losing some dependencies (databases or img folder etc.).
Is it good practice to share the Eclipse workspace on GitHub? If I use third party libraries these will be included too though.
Sharing only the bin folder would be mostly pointless. Basically, if you want to share your projects in Github, the expectation is that you are also sharing your source code as well. Sharing only the src folder would still be mainly pointless, both for the missing resources you already mentioned and also for missing project metadata (e.g. required Java version, project name, etc.) that gets stored there. Without this metadata it might be still possible to compile your projects, but having the project metadata included allows others to simply check it out into an Eclipse instance, and it should compile and run without any extra configuration required.
Sharing a workspace is a bad idea, as your workspace .metadata folder contains your preference settings, file system references (sometimes referring to absolute paths on your computer), and sometimes even passwords. I would not recommend doing it.
To be more constructive, I would suggest to do the following:
Categorize your projects, and create a separate repository for each different project. This helps to show you are building several things that can be used separately. Of course, if some projects belong together, share them inside a common repository.
When you create a repository, generate a gitignore file related your project type (e.g. Java project) - see screenshot below. This sets up the repository in a way that you are not uploading class files, etc. that is unnecessary in a source code repository.
Share your projects one-by-one into this repository. Eclipse has the EGit project that supports this aspect (most likely it is already installed if you have a not too old Eclipse instance.
Im very new to git ingeneral, egit and github.
The problem:
Lets say I have a project for eclipse in c:/username/workspace name "Test". So I versioned it and pushed it up to github.
Now I can see all my Files in github under the directory "Test" in github. In example /src. The "Test" directory is not versioned. only the name of the repository is "Test".
My next step was to delete my local files and fetch my project again(For testing). After that I had to import my project again (but I had to use the new project wizard) over the egit view. Unluckily also the wrong scala version was detected. (Was a play framework project). So I had a big exclamation mark on the project view.
My questions:
What is the best practice to oush a project to github so everyone can participate? Everything under the project folder? Obviously some information got lost through the process.
How can I prevent to generate a new project every time someone clones the repository?
What about best practices for using git inside the workspace. Eclipse warned not to put the project inside the workspace.
Im coming from a subversion background :/. Maybe a general missunderstanding.
Thanks in advance
Switching from SVN to Git in an Eclipse environment can take some getting use to. (I'm still getting accustomed to it myself.) Keep in mind the difference between the role of the .git folder and the .svn folders for Git and SVN respectively. There is a .svn folder at every folder level in the working copy. There is no .svn folder in the traditional Eclipse workspace root. The "source controlled things" are subdirectories of the workspace, not the workspace itself. This is generally good because the workspace contains desktop specific settings that one generally doesn't want shared (much of it in the .metadata directory).
With Git, there is only one .git folder that contains everything. The first impulse is to do a
git init
at the workspace level. This would make the subfolders (the Eclipse projects) eligible for source control. But wait, so is .metadata. Of course you can ignore it. But you may have to ignore lots of other folders (projects) that you do not want source controlled. Of course, the .gitignore should be included. But others will have different files to ignore.
It turns out that its easier to use Git with Eclipse if you place the .git folder and its sibling source controlled folders (Eclipse projects) someplace else besides the workspace root. Your view in Eclipse doesn't change. You still see all your projects, both the Git-controlled and the SVN controlled and ones not shared at all. But underneath in the filesystem, the Git-controlled folders will be somewhere else. This is what EGit prefers.
On my desktop, I have a workspaces directory for most of my Eclipse workspaces. Now that I use EGit, I also have an egit directory where I keep the local EGit repositories. The Eclipse workspaces that share using EGit reference a subdirectory of egit. It's from these local Git repositories that one pushes and pulls from GitHub.
Sorry for the length. I got a bit carried away.
I keep my .project and .classpath files in my source repository. I maintain separate eclipse workspaces for each branch off my trunk. I've found the best way to do this is to recursively copy my trunk workspace (cp -r dev/ branch-foo/). This works great. There are a few other details that facilitate sharing templates and key mappings, but that's not important here. The issue with this solution is that I end up with a workspace that, to no surprise, contains all the trunk projects. I then have to remove all these projects from the workspace manually and then import all the projects in the branch. Not a huge deal, but I'm wondering if something better can be done to automate this process.
I don't see any files that get written to as I add/remove project files in my workspace so I'm assuming eclipse manages these relationships in some internal DB or something. Additionally, I looked into any command-line support eclipse offers for doing this, but don't see anything.
Any thoughts would be much appreciated.
One P.S. - I do see some binary files located in ~/workspace/branch/.metadata/.plugins/org.eclipse.core.resources/.projects/project_name/
I'm currently working on several eclipse projects, using Perforce as my source control. I have the perforce eclipse plugin installed.
My problem is that eclipse likes to, for no particularly good reason, write to my .project or .classpath files. It also loves to change the order in which things appear. As such, it demands that I have these files checked out almost all the time. I've somewhat worked around this by creating a pending changelist called "Files which I've checked out for convenience" and stuffing all of the metadata objects that eclipse asks about there.
This has the downside that if anyone updates some metadata (for example, adding a new project reference or changing the classpaths) I now have to resolve differences before they'll show up, adding extra time and trouble to my project.
Coming from Subversion, this is a really rude surprise. With SVN I could just wait until I checked in and move these files to the ignore-on-commit changelist, as needed. SVN would also merge new updates into these files without bugging me.
Basically, is there any way to prevent eclipse from constantly futzing with my projects, or am I just stuck here?
I'm assuming the .classpath and .project files are in version control, since that what causes them to be read only. There is an option in Perforce using P4V to make just those files always writable. Right click the files and select 'Change Filetype...' and select the +w Always writable in workspace option. This will affect all clients using that branch / stream, but now changes can be made without marking for edit first.
If you would like that to be the default for all of your depots, then you can have a Perforce admin to change the p4 typemap so that any new .classpath and .project files will be writable.
See http://www.perforce.com/perforce/r12.1/manuals/cmdref/o.ftypes.html
Have you tried adding a .p4ignore file to the project root dir, containing
.classpath
.project
Support docs for P4IGNORE
I have some projects on bzr code repositories shared with colleagues.
Problem is, I really want to switch to eclipse in some projects, but I don't want to pollute the repository with the unnecessary metadata eclipse creates in its Workspaces.
Any idea how to keep Eclipse's metadata outside my bzr repo?
Adam
If you know the names of the meta files created, you could put them into your .bzrignore file in your repository's directory.
See this part of the bzr docs
All the main metadata in eclipse are in the workspace.
You project, meaning:
your .project file
your .classpath file
your .settings directory
your source files
should all be located elsewhere, within your main project directory.
All those files (except the .class files generated by the compilation) should be versioned.
See "Do you keep your project files under version control?" for more, but also:
What to put under version control?
When working with Eclipse, should I add the workspace to the source control?