So the way I gather it, eclipse stores its project specific files in two or three hidden files such as:
.project
.classpath
are there more?
Do I sync the .project file through the version control? the .classpath? (I'd assume not). To be able to import a project easily, I'd definitively assume the .project has to be there :p.
So my problem seems to be that it's not just to create a project on machine A, put the entire contents of the project folder on some version control, and import it on machine B. It always seems like it works wonderfully (as it should) on machine A, and becomes a mess with invalid classpaths for libGDX jar files on machine B, and we have to manually fix these afterwards by going into each libGDX 'sub-project' (since it has one project per target platform) and link it to the correct gdx.jar, gdx-native.jar etc....
Can't this be automatic? Am I doing it wrong? A lot of people probably use libGDX, and they probably collaborate right? So how do you do it? :)
2 notes here:
I know this is a one time setup kinda thing, and once you do this, we un-track the .project .classpath files so they no longer mess each other up. But it's still a pain to do this for every project... I still think this should not be such a turn-off when starting a collaborative project with libGDX / eclipse.
I was contemplating making this question more specific about libGDX, since this is what I am using at this particular instant together with others, but it would seem to be applicable to most eclipse projects anyway.
OK, so I finally found a solution!
some info:
eclipse does support relative paths (since 3.5 apparently) for libraries and the build path. (I want to credit #VonC, here: .classpath and .project - check into version control or not?)
the libGDX setup tool creates an eclipse project for you (yay!), but it does so with absolute paths to the build path libraries (bad!)
solution:
apparently there is no nice GUI method of editing the .classpath file from eclipse that I could find (without navigating using the file browser), so open the .classpath file in a text editor, and change the path from absolute to relative like this:
"/some/absolute/path/to/project/libs/gdx.jar" ---> "libs/gdx.jar"
and here are my exact lib entries in the .classpath file for my project-desktop project (after making changes):
<classpathentry kind="lib" path="libs/gdx-backend-lwjgl.jar" sourcepath="libs/gdx-backend-lwjgl-sources.jar"/>
<classpathentry kind="lib" path="libs/gdx-backend-lwjgl-natives.jar"/>
<classpathentry kind="lib" path="libs/gdx-natives.jar"/>
These might be of interest due to them being relative paths (thus presumably identical to what others would want in many cases (libGDX cases!)).
version control?
Now (with relative paths) we can safely put all our eclipse project settings in our version control / repository, and anyone can just clone and run our libGDX projects with ease! :)
(I hope libGDX makes use of relative paths for their project setup tool in the future)
Related
I used Eclipse PDT (Kepler with PDT 3.2.0) as my main IDE and there is something I could find how to do.
I'm working on a big Zend application, with a couple of hundreds of modules on it. To make it easier to code, I add to Eclipse each of these modules as a separate project. They are also logically arranged on Working Sets.
I would like to make it so that the classes of all of the open projects on the workspace appear as code completion automatically on the other projects. Right now it only recognizes the classes on that same module, or I have to create a library based on the local folder and manually add to each project, which makes building very slow.
I am not aware of a setting that can solve this, but there is some other options.
You can add the bin folder for each project to the build path: Project preferences -> Java Build Path -> Libraries -> Add Class Folder. This is a painstakingly slow process to do through the gui, so you might want to add the line <classpathentry kind="lib" path="/NAME_OF_PROJECT/bin"/> to the .classpath file - one line for each project - and work some copy-paste.
If you add new modules relatively often, you might want to automatize this. You could of-course write some hack-script that modifies the .classpath file, but a more proper way will be to create your own classpath container. Take a look at this blog post, that describes how to create one. You should be able to get it working in less than a day, if you have experience with Plugin development.
I have a netbeans project that is under mercurial. What I would like to do is to strip down everything that makes this project netbeans project to only to leave code in there so that I can easily import it in say eclipse.
Is there some automated way to do this or do I have to remove manually this?
What approach would you recommend.
Cheers
You only have to add the nbproject folder to ignore (= don't check in). All NetBean-settings are placed in this folder. Dont check in the build and dist folder as well, because these contain the compiled code (but they are ignored per default).
The best way to do "IDE neutral projects" is to use Maven !
In NetBeans when the project is Maven-based (as opposed to Ant-based) you'll see that all those NetBeans-specific files that you normally see in nbproject folder are just not there. The nbproject folder doesn't even exist. The reason is that for a Maven-based project NetBeans essentially uses the pom.xml as the definition of the project and that's a good thing because the POM is portable and directly understood by other IDEs.
Even for a Maven-based project NetBeans will still store some IDE-specific stuff in a file called nb-configuration.xml but you can include all of the contents of this file as properties inside the pom.xml. These properties will then be ignored by other IDEs when they load the POM. This way you can pretty much avoid altogether to check any IDE-specific files into the VCS. Also it is worth mentioning that the stuff in nb-configuration.xml is never needed for someone else (using NetBeans or another IDE) to be able to build your project. Another way to put it is that it contains non-essential data. The POM - by virtue - is always guaranteed to be a complete description of how to build the project.
Contrary if your NetBeans project is Ant-based then at least in my experience you cannot avoid checking NetBeans specific files into the VCS ... because otherwise even those using NetBeans won't be able to correctly open your project.
However even with Maven there's one area where you'll be forced to have NetBeans-specific files in the VCS and that is if you use the Matisse GUI builder in NetBeans. The Matisse GUI builder produces some proprietary files with .form extension and you really need to have those in your VCS. But this is the only example I can come up with where NetBeans-specific files will need to go into the VCS assuming your project is Maven-based.
If the project indeed is Maven-based and you still feel that there are NetBeans-specific files that you need to have in the VCS then let us know exactly which files you're thinking of. Then we can take it from there. :-)
I am new to Git and I'm having a lot of difficulty figuring this out.
We are using JBoss Application Server 5.1 in Eclipse. Some people have downloaded the JBoss Tools Eclipse Plugin so they can add the JBoss 5.1 Runtime Server as "JBoss AS 5.1" to their Eclipse workspace. This results in a classpath line that looks like this:
<classpathentry kind="con" path="org.eclipse.jst.server.core.container/org.jboss.ide.eclipse.as.core.server.runtime.runtimeTarget/JBoss 5.1 Runtime"/>
Other people do not see the value of downloading and installing the JBoss Tools plugin, so they just use Eclipse's built-in JBoss server adapter, which only goes up to JBoss v.50. They have a classpath line that looks like this:
<classpathentry kind="con" path="org.eclipse.jst.server.core.container/org.eclipse.jst.server.generic.runtimeTarget/JBoss v5.0"/>
I don't want to add .classpath to my .gitignore file because:
The files are already pushed to my origin, and removing them is a super painful process that I have tried and failed to understand in the past.
I want people who are setting up new workspaces to just be able to import the projects from Git and get going right away.
So far we have just tried each modifying our .classpath files in our working directory but never committing. This is annoying not only because they keep showing up in our git status, but sometimes they will not allow us to merge or switch branches in Egit - complaining about uncommitted changes.
I've read on the internet about using Classpath Variables instead, but I cannot seem to find the correct path to the JBoss libraries at all. The classpath lines I listed above seem to point to somewhere inside the Eclipse/plugins directory somewhere? But I can't find it. I also tried pointing some variables to my C:\jboss-5.1.0.GA\ directory, but that does not seem to do anything either.
Is there a way to just leave the .classpath file inside the repository as it is now in its current state, so that new users who clone the repository still get them, but then just ignore all future changes any developers make to the files?
An easy, once-per-developer solution from Pagebakers and git is
git update-index --assume-unchanged <file>
To undo it, just use
git update-index --no-assume-unchanged <file>
Another answer can be using a content filter driver, ie a script that you declare in a .gitattribute file.
On checkout of your repo, the smudge script would be in charge of analyzing the local environment, detecting the JBoss in place and adapting the classpathentry accordingly.
That way, you can keep the most useful content of that file already versioned, while adapting to the few special cases where the classpathentry is not the correct one.
When I commit a web appliction to source control should I also include the .project & .classpath files ? I don't think it should make any difference either way as other users who use the project should have the same project settings ?
This is the sort of question that gets people bent out of shape in a debate that never ends. You basically have two camps:
Only put source code into the source control system. Each developer chooses their own IDE and manages their own project configuration. Setting up your IDE after getting source code from the repository will be tricky. If one dev changes project dependencies, they have to explicitly communicate that so that all other devs update their project configurations. There are some tools that try to address this problem, like a Maven plugin that will attempt to generate Eclipse project metadata from pom.xml, but all have their limitations. Groups that go this way favor the purity of not restricting developer choice in IDE over the convenience of having Eclipse projects across the team that just work.
Standardize on Eclipse. Put all Eclipse project metadata into source control. This includes .project, .classpath and the entire contents of .settings. Basically, the only thing that you don't want in your source control repository is content marked as derived in Eclipse. You can check that in right-click->properties. Taking this approach ensures that developers can get started coding immediately after getting the project from source control. No additional configuration required. Also, when one dev changes project configuration, the rest of the team will see the same change on next sync.
Choose the approach that makes the most sense for your team.
For ClearCase, including the .project and .classpath can make a difference when you are using the IBM ClearCase plugin for Eclipse.
That plugin will work better if it can rely on those (versioned) files being there, right next to the sources (as opposed as being in the Eclipse workspace, which doesn't necessarily contains said sources).
In general, nothing generated should go into repository. Those files are generally generated by IDE or maven. However, sometimes you may need to click a button or execute a command to get those generated.
i would include them.
The .project file have plugin info (e.g. maven, ant, pdt, wst, aspectj, findbug..). It is essential if it is not a plain java project.
.classpath contain the classpath. it is needed if you use jar files.
I would say that all files - including .project and .classpath - should go to source control, to ensure that everyone in the team has the exact same setup.
I'm trying to develop a small project using Eclipse and the Google Web Toolkit.
It's a (small) group project so I want to use SVN.
So far I have created a GWT Project in Eclipse and added it to my SVN Repository.
The problem is that when I use 'compile' on the project, it breaks SVN's metadata and the whole war-directory is marked as broken. (Red Exclamation mark).
I then cannot commit and/or update - neither can I just ignore the war directory because of the web.xml / appengine-web.xml files which Eclipse complains about when they are missing... Cleanup also fails.
So far the problem -
Does anyone of you know how to properly set up a new GWT Project with SVN?
Which files need to be ignored? Which files can be committed? ...
A beginner-friendly solution would be great!
Thanks in advance
In the answer below I'm assuming you're not using Maven. I tried to answer generically as well so the below should apply to any version control system (I'm on Bazaar).
You want to commit the files which constitute the application source code (e.g. *.java files) and configuration metadata (e.g. *.xml files). Some (like me) also like to commit Eclipse project configuration (.settings, .classpath and .project), even though doing so might on occasion cause some inconvenience to other team members due to differing Eclipse setups. I think the convenience of not needing to guess which Eclipse natures the project has or what's supposed to be on the classpath is worth it (Maven helps even more, but that's a separate discussion).
You want to ignore the files and folders which are build products (and hence are temporary and reproducible by nature). For GWT apps developed in Eclipse using the Google Plugin for Eclipse these are typically war/WEB-INF/classes, war/WEB-INF/deploy and war/<module_name>, where <module_name> is the name GWT uses for the folder where it places your GWT module compiled into JavaScript/HTML. You might also want to exclude .gwt where GWT dumps log information during work in Development Mode.
Also in your project directory be sure to ignore the gwt-unitCache. This is where gwt stores a manifest of what units have been compiled for re-usability.
Hope this helps.