I'm about to commit Eclipse .classpath and .project into SVN, following the good advice I got here on SO.
The problem is that some JRE definitions are unique to a developer's machine, e.g.:
<classpathentry kind="con" path="..JRE_CONTAINER/org..../Jeffs JRE"/>
If this line is committed, it fails on other machines that don't have Jeffs JRE.
Any idea for a workaround? Could the JRE definitions be shared as well?
In project properties > Java Build Path > Libraries > Double click on you JRE and then choose: Use Execution Environments instead of Alternate JRE or Workspace default JRE. You .classpath entry will be then something like this:
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.6"/>
I never saw adding specific IDE configuration files as a good practice, but that's a different issue.
If you want to follow that path, you should use the variables.
Java Build Path > Add variable
Then you need to make sure that every single developer has those variables defined, everyone with their own paths.
(or use Maven to avoid these problems)
Related
I'd like to use IntelliJ IDEA with an Eclipse project, without converting the project format.
The main problem I'm running into right now is that in my .classpath file, we have entries like:
<classpathentry kind="lib" path="/lib/whatever.jar" />
In Eclipse, that path is relative to the workspace root. But in IntelliJ, I believe it's looking for the actual "/lib" folder on my hard drive, which obviously doesn't exist.
How can I maintain the Eclipse functionality while having IntelliJ look in the "lib" module in my project? Is there a variable that both support?
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)
The Maven plugin for Eclipse is finding relevant source code for one of my project's referenced libraries in my local Maven repository and adding a sourcepath attribute to my .classpath file.
<classpathentry kind="lib" path="lib/core/guava-11.0.1.jar" sourcepath="Users/<my_user>/.m2/repository/com/google/guava/guava/11.0.1/guava-11.0.1-sources.jar">
<attributes>
<attribute name="javadoc_location" value="http://docs.guava-libraries.googlecode.com/git-history/v11.0.1/javadoc/"/>
</attributes>
</classpathentry>
The problem is that I cannot commit the .classpath file because it contains a hardcoded path to my local maven repo. Is there a way to tell Eclipse to output that using a environment variable like M2_HOME? Even if it's not automated, is there any token that I can put in there that will let it resolve the location of the source without the hard-coded path? I tried:
sourcepath="$M2_HOME/com/google/guava/guava/11.0.1/guava-11.0.1-sources.jar"
but Eclipse could not resolve the location of the source for this library after I made this change.
Any ideas?
With maven 2 you can set the M2_REPO classpath variable in Eclipse and maven eclipse:eclipse will use it automatically in your .classpath file. Details can be seen here: http://www.mkyong.com/maven/how-to-configure-m2_repo-variable-in-eclipse-ide/
We've not yet migrated to maven 3 so I am not certain, but I imagine the variable needs to be named M3_REPO for maven 3.
You're right that committing the .classpath or .project files is not a good idea.
However, in the same way that m2e added that value, as would the plugin for other users. Maven will download the files required on the PC of another user if required (i.e. not in their local repo), and give the correct sourcepath in the .classpath file.
Hope that helps!
I would add "guava-11.0.1.jar" to a maven repository and then add it as a dependency in my pom.xml. By doing this you won't have "classpathentry" tags in your .classpath file.
After that I would turn on source downloading via the m2eclipse plugin (Window->Maven and check "Download Artifact Sources"). Using sources this way does not add any .classpath file entries.
I'm using Eclipse on a small development environment where one developer has a Windows PC and the other has a MacBook. We share code using a subversion repository, and use Maven as an "External Tool" (not using the m2e plugin).
We each have an M2_REPO variable that has been working great for resolving paths to .jar files on our two systems. Recently, however, I ran a command to tell Maven to pull down sources and javadocs.
mvn eclipse:eclipse -DdownloadSources=true -DdownloadJavadocs=true
Since then, I see some very Windows-centric references in my .classpath that are a nuissance to my Mac-using friend.
<classpathentry kind="var" path="M2_REPO/org/slf4j/slf4j-api/1.6.4/slf4j-api-1.6.4.jar"
sourcepath="M2_REPO/org/slf4j/slf4j-api/1.6.4/slf4j-api-1.6.4-sources.jar">
<attributes>
<attribute value="jar:file:/C:/Users/John/.m2/repository/org/slf4j/slf4j-api/1.6.4/slf4j-api-1.6.4-javadoc.jar!/" name="javadoc_location"/>
</attributes>
</classpathentry>
Even after having removed the downloadSources and downloadJavadocs parameters, and verified that they're false in my plugin configuration for maven-eclipse-plugin, deleted my .classpath file, and reran mvn eclipse:eclipse I still see those unwanted references placed into my .classpath file.
Has anyone found a good working solution to this problem? Have I overlooked some setting that tells Maven to use the M2_REPO variable in its references to javadoc files?
On my team we don't commit Eclipse .settings or .classpath files into source control. When we initially check out projects we use m2e to build the classpath (did it with eclipse goal as you are once upon a time) and everything is set up correctly no matter what platform the developer is using. We have people using Win 7, Macs, and various Linux flavors and the build machine is Linux, no issues I know of anywhere.
I don't use maven, I am the only developer and I have a Windows PC and a Mac. For me this "small" solution works fine. Create a symbolik link so your paths on both systems match:
C:\> mklink /d "C:\Users\xxx\android-sdks" "C:\Users\xxx\AppData\Local\Android\android-sdk"
I did this on the windows machine. The command is mklink /d (for directory) newDir existingDir. Works on Windows 7 at least. Maybe this will help.
Try enabling the dependency management of your maven project by:
Right Click on the project –> Maven –> Enable Dependency Management
After this delete and recreate your .classpath file.
Rather than use 'mvn eclipse:eclipse', install M2Eclipse either from the project site or through the Eclipse Marketplace. It will handle all the linkups for you, and not embed absolute paths.
(I always version .classpath and .settings/)
If you have javadocs in your repository, the maven eclipse plugin will always add them to your classpath.
The -DdownloadJavadocs=true option only tells the eclipse plugin to download them. It does not tell the plugin to include them or not in your classpath. If you do not want them in your classpath anymore, you have to remove all -javadoc. from your local repository (or delete your locate repository).
I am developing currently on Windows and Linux in parallel. I am facing the problem when including libraries, the path cannot be found on both machines at the same time, as Eclipse saves the absolute path. Is there an option or something similiar?
If your libraries are inside the project, Eclipse references them relatively in the .classpath file. For example:
<classpathentry kind="lib" path="lib/example.jar" />
The same applies if you are referencing libraries in your workspace, using an absolute path within the workspace:
<classpathentry kind="lib" path="/Libraries/example.jar"/>
You can also use Eclipse's "Classpath Variables" section in the preferences (in Java > Build Path > Classpath Variables), which "can be used in a Java Build Path to avoid a reference to the local file system."
Finally, you can use the "User Libraries" section in the preferences (in Java > Build Path > User Libraries) to "define a number of external archives".