I need to mention a path variable in eclipse Helios on Mac Os.
The path I am specifying contains whitespace in it.
Example:
user/folder/android sdk
I have tried following ways which failed in the end:
Specifying path in quotes both single & double.
Can anyone suggest way to solve this.
There shouldn't be any issue with classpath including spaces, on Mac Os or any other Os:
Add your space through the Gui (Java Build Path)
, and you will get a .classpath file with:
<classpathentry kind="lib" path="my libs/apache_cli/lib/commons-cli-1.0.jar"
sourcepath="my libs/apache_cli/src/commons-cli-src.zip"/>
The quotes take care of any spaces in the paths.
Related
When a jar file that I am using changes names (usually the version number is what changes), is there a better way to update the name than deleting the old jar and adding the new in the Eclipse Java Build Path Libraries tab? What I am really looking for is a way to manage this whole upgrade process of downloading the jar, putting it in my project lib directory, removing the old one, and updating Eclipse. For instance, right now I am using the .jar, source, and javadoc from
cucumber-core-1.1.5.jar
and would like to update it along with its source and javadoc files to version 1.2.4. In fact there are four different version numbers used by six jar files associated with Cucumber - times three because of the associated source and javadoc files. And my project is also dependent on two other tools, which have their own set of jars and version numbers. How do I set things up so that I can just go in and reset these version numbers in a simple way in the Java Build Path Libraries tab? Or even better, just dump these new jars in a jar/lib directory and Eclipse should work, right?
If that's impossible, how do you suggest I handle version numbers. Do I have to learn how to handle maven or gradle integration with Eclipse, or have you found a simple way to manage upgrading your tool versions?
I looked at the Eclipse .classpath at the root directory of my project, and found that the source and javadoc locations are included there with the classpathentry tag. For instance, here is what I have for JUnit:
<classpathentry kind="lib" path="vendor/junit-libs/junit-current.jar" sourcepath="vendor/junit-libs/junit-current-sources.jar">
<attributes>
<attribute name="javadoc_location" value="jar:platform:/resource/myproject/vendor/junit-libs/junit-current-javadoc.jar!/" />
</attributes>
</classpathentry>
Notice that I am using "-current" anywhere that the files I downloaded had a version number. I originally did that because I couldn't get variables to work in a previous version of Eclipse. Now, I'm thinking that I could use this "-current" trick as part of a scheme to only enter version numbers in a single place, a Gradle file or Ant build.properties file.
Gradle has a very convenient way to download libraries and get them installed in the Eclipse build path. See jmruc's example at https://stackoverflow.com/a/17008509/1759555 . But I could find no evidence in the Gradle documentation that Gradle takes care of source and javadoc
My strategy for attacking the problem is going to be
use "-current" in Eclipse where the downloaded files have a
version number
download the files and change their names with Ant
use an Ant build.properties file to store the file names and version numbers in a single place for my project
I have a few projects which run using Jython 2.7b1 where I add the jars (in fact all the jars in a directory) by doing this:
set CLASSPATH=.;"%SYSADMIN%\resources\java jar files/*"
set JYTHONPATH=...
C:\jython2.7b1\jython myproj\__main__.py
But my latest project is using 2.7.0FR and this "set CLASSPATH" approach doesn't seem to work. I then tried this:
D:\apps\jython2.7.0\bin\jython -Dpython.path="%SYSADMIN%\resources\java jar files/*" my_latest_proj\__main__.py
... but it didn't work. Then I wanted to see whether I could load an individual .jar:
D:\apps\jython2.7.0\bin\jython -Dpython.path="%SYSADMIN%\resources\java jar files\lucene-analyzers-common-4.6.0.jar" my_latest_proj\__main__.py
This didn't work either: the following line
from org.apache.lucene.analysis.fr import FrenchAnalyzer
leads to the following error: "No module named apache"... nor is there any "unpacking" of the jar as you typically see with Jython the first time you use a jar.
Finally I tried this:
set CLASSPATH=.;"%SYSADMIN%\resources\java jar files\lucene-analyzers-common-4.6.0.jar"
... same thing: "No module named apache"
NB I have no trouble getting jars to work from within my project when running it under Eclipse.
Can anyone tell me what I'm doing wrong?
Aha...!
1) It appears that with Jython2.7.0FR you have to use forward slashes in paths in the CLASSPATH, even in a Windows OS. This appears to be a change relative to 2.7b1...
2) I also seem to find that paths with spaces are to be avoided... previously I could enclose such a path in quotes and it would work OK. This seems not to work any more.
Any comments from the Jython "High Command" would be welcome...
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 eclipse, my sbt files show the 'J' symbol in the icon, rather than the superman 'S' symbol I expect to see for scala files. Not a kryptonite-serious problem, but how do I fix it?
generated via sbt-eclipse plugin 2.4.0, sbt 0.13.1-RC2, eclipse 4.3.1, scala-ide 4.0.0-m2.
I'll guess that the problem is related to the convention of including sbt .scala files in the root of the /project directory.
Edit:
It is bad to not have the super 'S' symbol, otherwise the .scala files won't be compiled in eclipse.
I manually added the following to the project/.classpath:
<classpathentry including="*.scala" kind="src" output="target/scala-2.10/sbt-0.13/classes" path=""/>
That fixes things. Is this an sbteclipse issue? Is there a workaround?
The wrong icon is the result of a bug in SDT - I created a ticket.
Beside from that, Scala files (as well as Java files) which are not assigned to the classpath (as it is currently the case for sbt project files) are not compiled by Eclipse (because they are not associated with a builder).
Nevertheless, you get most other IDE features for these files like semantic highlighting or auto completion (in fact all features which don't require or rely on bytecode generation should work).
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)