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".
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'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?
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 :).
I'm using eclipse with svn and when I add some .jar files to my Build Path eclipse add the jar with the full path from the root.
I know for sure that the file will always be in a folder called lib in the same directory as my project:
for example:
~/lib
~/proj
Can I add the file taking my project's directory as a reference? Something like ../lib?
Because, right now, when somebody makes an update the Build Path needs to be changed...
Thanks a lot
under
Window > Preferences > java > Build Path > User Libraries
you can define user libraries, witch you can add to your class path. just say new type in a name (for example MY_EXTERNAL_LIB_FOO) and hit ok. Then select it (simple click) and hit add JAR..., you can then brows your jars and add the ones you want (multi select is possible)
the entry in .classpath will look something like this
<classpathentry kind="con" path="org.eclipse.jdt.USER_LIBRARY/MY_EXTERNAL_LIB_FOO"/>
this way you can abstract the location for the libs for your projects, they only need to know the name, Eclipse needs to know where the Libs for a name are located.
If you are versioning the libs too within you project then when editing the Build path hit add JARs... and not add External JARs... you will be prompted wi a list of all the project in the actual workspace, choose the onse you have in your project. the entries in .classpath will be relative to your project.
So if you have the following project layout
+ MyProject
+ src
+ lib
some_3rd_party_lib.jar
then the entry in .classpath will look like
<classpathentry kind="lib" path="lib/some_3rd_party_lib.jar"/>
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)