I imported external libraries using absolute path. But I have two work environments, switching between Linux and Windows. Projects are downloaded from SVN. So I was wondering whether I can import these libraries by relative path.
You should declare a variable (Java Build Path -> Add Variable... -> Configure Variable ... -> New) to set the changing path on each system (e.g. FOO_BAR_HOME).
Than you can add the Variable to the Libraries and edit it to point to your library, like
%FOO_BAR_HOME%/lib/foobar.jar
Take a look at the existing variables for usage.
Alternative you can place the library inside the project (e.g. subfolder 'lib'). If you add the library from this location ('Add Jars...' NOT 'Add External Jars...') it will be added by relative path.
Hey I was having this issue as well, but I can offer an alternate solution for those who want to keep the required library locally but outside the directory of the Java Project.
First, add the library you want using the usual "Add External Library/Jar" method.
If you go into the home directory of your Java Project, you should see a .classpath file. Edit this with any text editor you wish, and look for the line that references the library you added. Then, say your library is called lib.jar and you have it one level outside of your project.
Lets say the line says:
<classpathentry kind="lib" path="C:/Users/Public/workspace/lib.jar"/>
Rather than moving lib.jar to your Project's directory, you can just change this line to say:
<classpathentry kind="lib" path="./../lib.jar"/>
and your Java Build path will be updated to look for it in the directory one level above the current project.
Also, to my knowledge if you're running a Mac or any Unix based OS, then the .classpath file will be hidden. In order to access it, you can try opening it from Terminal, by navigating to the directory that your Java Project uses (the actual project folder itself, not the workspace), then either vi or vim ".classpath". Keep in mind that using ls or even ls -a might not work, but trust that it will be there.
Once you've changed it to the specified location, save the file and when you go back into eclipse, the reference should still be working. Keep in mind that the "./" at the beginning is necessary. Just having "../" will not work, or at least it didn't for me.
I did it very simple. I had a lib with an absolute path in my classpath:
/home/glauco/workspace/ltClubs/lib/swingx-core-1.6.2.jar
So i just removed the absolute path from it and it works. Now it's relative xD:
lib/swingx-core-1.6.2.jar
This should be a comment on the previous answer, but the strange reputation system from this site forces me to post a new answer instead... (no comments)
You can use a relative path, but you're missing the './' in it.
Instead of
lib/swingx-core-1.6.2.jar
you should use
./lib/swingx-core-1.6.2.jar
Add the folder containing the dependencies into the JAVA project. Select and right-click the dependencies, "Add to Build Path" pops up as a context menu. This adds the dependencies using relative path instead of the absolute path.
Related
I want to figure out how can I put a file in the root folder of the project and use it in run time, there it will be accessible.
The problem that I have by doing that (placing the file in the root folder)-is that by default it means:
It is not in the classpath of the project.
It is not copied to the bin (output) folder.
I can’t see how my modifications of the file will affect the run process.
As I know there is a similar mechanism in eclipse that does the same:
The Plugin development project has a file-"plugin.xml" in the root folder of the project.
When you make a change in the file without building the project or copying it to the bin folder the changes take place when you run it.
example:
add an extension point in ”plugin.xml” and hit “RUN”, it will take place immediately.
Does anybody have an idea how this mechanism works in eclipse?
Edit - for clarification :
I am interested in how the launcher of eclipse Plugin development project loads\handles the "plugin.xml" file.
I assume when you say you want to put a file in a "root folder of the project" you are refering to a plugin that you are developing and then in runtime you want to get access to that file. Please don't vote me down if I did not understand that question correctly but based on my understanding here are some steps to follow:
Open your MANIFEST.MF file /MANIFEST.MF, this will oepn a multipage editor.
Click on the build tab (third from right).
This is where you specify what resources in your plugin you want the builder to include in the plugin at runtime. You will notice that plugin.xml is already checked which is why extensions get updated each time.
Check the resource on this editor page for the resource you want to be able to load and access at runtime. Behind the scenes this is updating your build.xml which the internal builder uses to figure out what sources to build/add when building/exporting the plugin.
One you have done that this is how you can get access to that file, you get the Bundle for your plugin and call the getEntryMethod with the path to your file and then open in inputstream from there you can load it as a File or whatever you want. Code example below: Hope this helps - Duncan
Bundle myBundle = Platform.getBundle("com.mycompany.myplugin.id")
InputStream in = myBundle.getEntry("/myfile.txt").openStream();
When I try to add a new Classpath Variable in Eclipse for my Build Path configuration, and the path I add is a directory that the current workspace is a subdirectory of, Eclipse gives the error:
'C:\JavaStuff' is not a valid location for linked resources.
Why does Eclipse impose this restriction? I can't think of a good reason for it... I might want to put my JARs in C:\JavaStuff\libs and have my workspace in C:\JavaStuff\workspace, then reference libs (on my machine) via JAVASTUFF_DIR\libs where JAVASTUFF_DIR is C:\JavaStuff. This restriction prevents me doing this.
OK, the reason I was having this problem was not the Classpath Variable... it was the fact that I was trying to add it to the Java Build Path, because the way I was creating the variable was to go to the Java Build Path and click 'Add Variable'. After creating the variable pointing to the directory above my workspace, I OK'd out of that dialog and it tried to add that parent dir to my build path.
Looks like the way Eclipse wants you do add JARs via Classpath Variables is 'Add Variable', select the variable representing your base path, OK back up to the Java Build Path window, then edit the entry that's been added and manually add the rest of the path on (ie. turn MY_BASE_DIR to MY_BASE_DIR/libs/library.jar. A little bit unintuative.
I am trying to create a script that would list all the linked libraries in an FDT project and their corresponding svn repositories.
My problem : I was not able to find the file on my system where Eclipse (or FDT, I'm not even sure) writes all of the path variables.
I have tried capturing changes on my system and have had no luck.
If anyone knows where to find this file (Mac OS X) or knows a technique I could use to find it, it would be very appreciated.
Thanks.
In FDT, you can find the list linked libraries in the .as3_classpath file if those libraries are in your project folder (or below). They reflect the content you add in the 'Library' tab of 'FDT Build Path' in your project's properties. There's also an entry in the .project file that reflect the linked libraries you add with the 'Source' tab. Those libraries can be located anywhere on your hard drive, and that's why you define 'path variables' for them.
Personally, I create a 'lib' folder in my project where I copy the libraries I need and add them with the 'Library' tab. I find it much easier to share the project (since everything is relative to the project) and you don't need to worry about having two projects modifying the same library file.
For the location of those 'Path' variables, as far as I know, could only be located in your eclipse installation folder or in your eclipse 'settings' folder, usually in your 'user' directory.
I have been moving my Java projects from Jdeveloper over to Eclipse whenever I have to go back and make a change (I only work with Java projects sparingly).
Everytime I try to create a project in Eclipse (3.3.2) I spend quite some time trying to figure out the proper way to configure the source directories in the Java build path dialog.
The biggest problem I'm having is getting the source directories to match up with the package specified in the source files. For Example my project looks like this:
MyProject
DevelopmentBuilds
MainSRC
The MainSRC directory is also the "Root" package so my classes would be defined as:
package MainSRC.Sub1;
If I set my included directory to blank, the files compile but with many errors because the Packages are not in the right place.
How do I tell eclipse to start at MainSRC for the compilation rather than the children of MainSRC?
Or, should I the path up with one src folder with MainSRC as subfolder?
I basically don't understand how this works.
you need to set MainSRC as a 'Source Folder'.
Apparently, you project root are set as Source Folder.
Enter in project properties:
. Right click over your Project root, and select Properties
. Choose Java Build Path
. Remove all source folders
. Click 'Add Folder'
. Select 'MainSRC'
. Click Ok and Ok
Now, your MainSRC are a Source Folder. Some error occurs inside source files. For agile process, right click over package 'Sub1', and press F2. Rename your package for a new, then all your source files will be put in the correct new package.
[]'s,
And Past
You would need to set the source directory to the root MyProject directory. You would have to tell Eclipse to exclude the other directories (such as DevelopmentBuilds) as they are not source code.
You might find you're better off conforming to Eclipse's expectations and creating a source folder which contains your main package folder.
I have a rather large project which contains a number of third-party dependencies which are linked via svn:externals. These include tomcat and blazeDS, which are packaged by our installer via ant. The problem is that these projects contain dozens of sample JSP pages, and eclipse chokes on them when trying to build the project, producing hundreds of errors.
Our project setup is something like this:
src/
main/
test/
third-party/
blazeDS/
tomcat/
etc.
Now, in eclipse, my project's build path is set to only include subfolders in src/main and src/test. Yet, for some reason, it still tries to build everything beneath third-party. I have clicked on third-party and selected "remove from build path", but this had no effect. I even tried adding the third-party folder to the build path, and then excluding "", "/*", and "**/*.jsp", but again, to no effect.
What is going on here?
Edit: Thanks for the suggestions, though unfortunately, they don't seem to fix the issue. I don't have the CheckStyle plugin installed (I'm using Eclipse 3.4.1 with the only custom plugins being subclipse and flex builder), and I tried disabling all extra builders except for Java, but the errors are still being thrown.
I usually have this kind of issue with CheckStyle plugin, where you need to specify in its properties (right-click on project -> Properties -> CheckStyle):
"Exclude from check Files non located in a source directory"
Otherwise it does analyze (and reports warning/errors on) files which are not candidate to be compiled in the first place.
Couple of other suggestions:
try restarting your eclipse with the -clean option (eclipse software version of 'did you reboot it ?' ;) ). Beware it can reset your workspace perspectives, so you may want to try that with a copy of your workspace instead.
try deleting your project (your workspace reference of your project, not its actual content), and reimporting it (beware of your custom launchers, they may get removed in the process).
check if you do not have any linked directory within src or test, which would point to thirdparty(/**): that would explain the unwanted compilation.
It could be that your eclipse project is configured to have extra Builders. You can check that in the project's properties (right-click on project -> Properties -> Builders).
In my case it was because there was a reference to the file (which I had excluded from the build path) in another file which was in the build path. I wanted to exclude SegModel.hpp from the build path, but in another file, I had specified template short K::KEstimate<SegModel>(SegModel& m, short stepCode);