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?
Related
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)
In my RCP plugin application, earlier having a folder at project level "neededJar" in which i have all external jar needed in project build
But now I want to put all jar at a common library say a lib folder in installation directory, at my workspace i added needed jar as project->build path->configure build path->add external jar it works but when I export the plugin project it is not able to resolve dependency.
I also tried to give it as class path variable but it did not work.
My classpath entry is as follow:
<classpathentry kind="var" path="MY_JAR"/>
<classpathentry kind="var" path="MY_JAR/MYClasses.jar"/>
<classpathentry kind="var" path="MY_JAR/jMYlex.jar"/>
<classpathentry kind="var" path="MY_JAR/MYsm.jar"/>
By digging i got to know, not sure about it I am missing some entry in Manifiest.MF and build properties.
Please count what are the steps that i am missing. Please suggest me through process to add external jar in plugin project
update: it is yet not answered well.
You could use a linked folder.
Create a new folder in your workspace, but open the "advanced" tab in the wizard. Chose "Link to alternate location".
Just be careful with references to folders outside your workspace, since they have a tendency to move from time to time :).
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 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)
I have a basic web application (dynamic web project in eclipse) with an associated EAR project. I am trying to make sure that my junit test code stays out of the deployment EAR file.
In my web project I have a source folder called "src" and one called "test". I need to keep the .class files from the "test" source folder OUT of the EAR when I export it using eclipse.
I know this is trivial using ant but seems impossible using eclipse.. right click project and export the ear file.. the test classes are always included.
If I manually edit the .setting/org.eclipse.wst.common.component.xml file to remove the tag associated with the test folder it works but if some other developers change anything related to the build path, it gets regenerated...
Am I missing something obvious.. I've googled like crazy to no avail.. checked eclipse's docs and am at a loss..
It doesn't seem to be directly possible, which is bizarre. Here's a couple of workarounds you could try.
Note I'd move the java files from the web project to a Java project (this is probably a good practice to follow anyway). Either way create another "test" Java project and move the test sources to that project. Your test project declares the "main" Java project as a dependency so it has access to the types for testing, but isn't included in the war, so the test classes won't be deployed.
Alternatively if you want to keep the sources in one project, you can configure the test project to use linked resources. I've posted another answer that shows how you can use linked resources to share source locations across projects. With this approach the test sources still aren't on the build path for the main project, so won't be bundled in the jar, but are physically located in the project so source control is simpler.
I'm doing something similar, except with PDE, Using Eclipse 3.7.
I am deploying Eclipse/OSGi plugins/bundles, and have two java source directories: src and test
I've tweaked the contents of two eclipse project files to separate test code from the build.
.classpath:
<classpath>
<classpathentry kind="src" path="src"/>
<classpathentry export="false" kind="src" path="test"/>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry export="false" kind="lib" path="/thirdparty/junit/junit.jar"/>
<classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/>
<classpathentry kind="output" path="bin"/>
</classpath>
These changes were motivated by reading this
I don't know if this will apply to your situation, but I also had to modify a build.properties file, to exclude the results of compiling 'test' from the produced jar file.
source.optimizing.jar = src/
#This doesn't contain test/ because we don't want it in the build.
bin.includes = META-INF/,\
optimizing.jar
#The junit.jar is also exluded
When I build the entire project, the test files are completely absent.