I am developing an Eclipse Java project and would like to use "variables" to point to required libraries (.jar files).
Setup:
Machine 1: Eclipse Juno, OS X, own laptop, libs under /mylibs
Machine 2: Eclipse Juno, Linux, shared machine, libs under /sharedlibs/some/complex/path
Source control: Mercurial
Example of libs I use:
"${libs_base}/junit.jar"
"${libs_base}/guava.jar"
"${libs_base}/logging/slf4j.jar"
How can I configure the project Build Path to use the same "variable" for the base directory for libraries, pointing to different locations on different machines, but still check in my project description to source control so that when I add a new library, provided I specify its location relative to the libs base, it is found on both machines?
I have found the help file but could use an example, maybe even a screenshot please?
http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Fconcepts%2Fcpathvars.htm
for instance, do I copy this model:
http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Fconcepts%2Fconcepts-exttools.htm
inside "Java > Build Path > Classpath Variables" or elsewhere?
I have done a fair bit of "blind trial and error" already.. like stitching forms like "${env:VAR}" in there..
Oh, and I suppose I should mention that I don't know how to set these Eclipse variables based on environment variables considering that my systems' environment variables are set by Bash's .profile and I doubt Eclipse runs a shell to source that before...
/org.eclipse.jdt.core/org.eclipse.jdt.core.classpathVariable.my_libraries=$MY_SYS_ENV_VAR_LIBS
Of course, I use "Configure Build Path > Libraries > Add Variable" and then Extend from there, but still... an example would be worth a 1000 words.. (could it be that defining an Eclipse variable from which to Extend actual .jar references for inclusion in Build Paths just can't be based on a system environment variable, full stop?!)
PS: please don't ask me to just symlink things around, I am not a sysadmin on the shared machine..
From what I understand, extending a path variable would work perfectly for your case as you can define different base paths for each machine and reference libraries on subpaths based on that path. However if you are looking specifically to use environment variables you can try adding them to the build path this way:
Edit your launch configuration.
Go to the Classpath tab.
Click on User Entries and click the Advanced button.
To add a library based on a system environment variable, select Add
Variable String, and in the box type:
${env_var:libs_base}/logging/slf4j.jar. In this case
libs_base is your environment variable and logging/slf4j.jar is
the path to the jar in the subdirectory.
Related
I have been searching for a good way to use python virtual environments from within eclipse.
The only suggestion I have found is to create a new eclipse-wide "interpreter" for each virtual environment. That is cumbersome for many project, but it works.
I want to have a virtual environment per project, so the path to the interpreter will have to change for each project.
1) can you define an interpreter specific for a project?
2) alternatively, how do you define an interpreter that use e.g. PROJECT_LOC variable?
any suggestions are welcome
Unfortunately, the way that PyDev works, it expects all interpreters to be configured "eclipse-wide" (and then in a given project you can say which one should be used for that particular project if it shouldn't be the default one).
The other option is actually having one Eclipse workspace per project (then you'd configure a single "eclipse-wide" interpreter for it).
Another option, if the interpreters are from the same Python version and you're only changing the installed libraries would be creating a single "eclipse-wide" interpreter as the default one for all projects and then configuring the additional paths to be included in the PYTHONPATH per project.
Personally what I usually do is having one Eclipse workspace per project and having everything independent as I'm usually working on a single project at a time (so, I can focus only on what it's important for it), so, switching projects would be opening a new Eclipse instance pointing to the proper place, although it depends quite a lot on your use case (which you haven't actually made explicit) -- each project would have its own virtual env configured "eclipse-wide" (although in my case it's actually conda virtual envs).
We have an application developed in NetBeans, based on the NetBeans platform. There's a 3'rd party program that we have a runtime dependency on, more specifically a jar in the other progams lib folder.
How should we include the other progam's jar in our classpath?
The recommendation from the other progam's manufacturer is to set environment variable CLASSPATH to include
C:\Progam Files\Other Program\lib\theJAR.jar
And if that's not possible, we should copy theJAR.jar to JRE-HOME\lib\ext
We must not copy theJAR.jar anywhere else, that might cause it to stop working...
Now NetBeans takes no notice of what's on environment variable CLASSPATH. Their recommended way seems to be to make a wrapper, but that would lead to copying the jar, unless there's some way to make a wrapper module that points to CLASSPATH?
At the moment we are copying the jar into JRE-HOME\lib\ext. But then there's unnecessary hassle when we install some java update.
Do you have any solution to this problem? It seems like something that might be simple, but I haven't found the right place to look yet...
Edit: The application is ant-based.
From the documentation for the Module System API's overview of the runtime infrastructure (bottom of the page under the section "Common Problems and Solutions"):
Q: Can my module add a library JAR to the classpath from outside the
IDE [read: platform] installation?...
A: Not easily. You have a few options:
Add an entry to ide.cfg [your app's .config file]. For example:
-cp:a c:\eak\lib\eak.jar This startup file provides the ability to add classpath entries to the IDE's Java invocation.
...
It goes on to list two more options. The second option is the same solution you've come up with. The third is to "partition your module and use a new classloader" which I can't recommend either way since I have no experience doing this (but it's worth a read).
Assuming that this first option is what you are looking for, you will need to add a custom .conf file to your project and point to it in your project.properties file, like so: app.conf=nbproject/my.conf. This will add your custom .conf file to your app's install directory instead of the default config file that is normally added. Of course, you'll need to add the -cp:a c:\eak\lib\eak.jar entry to this custom config file in order to load the .jar.
During development you'll need to add the following entry to the project.properties file: run.args.extra=-cp:a c:\eak\lib\eak.jar. This will pass the command line option to your debug instance.
You can add that .jar file by following the steps below:
In the left side panel named "Projects" open your project and right click on the "Libraries", then select "Add JAR/Folder...".
Then select your .jar file from the location where you have stored it in the next dialog box that opens and then press "Open".
Vola Finished!!! (with the same process you can add other libraries also like JavaCV, JMF,etc)
And Now You Can Use That .Jar File From Your Project Library.
Hope It Helps.
I am currently working on an effort which makes use of Windriver's Workbench tool, which I understand is built on top of Eclipse.
Our source control tool is ClearCase and we are working primarily out of snapshot views located on the workstations of individual developers. As a result the absolute path for each developer's view is different. As deeply nested relative paths can be somewhat cumbersome (e.g. ../../../../../Some_Package/src/) we are using a Linked Resource PROGRAM_ROOT_PATH which identifies the particular view directory for a given developer.
This is working relatively well for for referencing header and library directories in the build properties, but we are trying to reference that Linked Resource from our build scripts in order to do build post processing such as copying the compiled program to a release area.
Accessing the Linked Resource as though it were an environmental variable appears to be the wrong thing to do as $(SOURCE_ROOT_PATH) provides an empty string. Is there a way to access this information from Eclipse / Workbench from a makefile?
Look inside the .classpath and .project files in the root of your workspace project - I believe the linked resource should be defined in one or the other of those (probably .classpath). From your script (you don't mention if it is Ant, Maven, Gradle, etc.) you should be able to find a way to get that value out of the .classpath (through some plugin or custom code).
We use Eclipse, ClearCase, and Ant. The easiest way I have found to share projects is to include the .project, .classpath, and build.xml files in the top level of the project in ClearCase. Then when you create your view, mount it in your Eclipse workspace, and do a File -> Import, then choose Existing Project from the popup. Browse to the top-level of the project in the view and import it.
The paths in the build.xml and .classpath are relative from that point down, so it doesn't matter what the absolute path is up to the project. For example, your build will define your source directory as something like ./src/java, test directory as ./test/java, etc. Whether your absolute path is c:\workspace\project or /home/someuser/project or whatever doesn't matter to your build script.
As I'm quite new to Java, I would like to know the proper procedure of installing new libraries (those that are no available in my linux dist repositories).
Where should I place them? and how to install them?
For instance, I downloaded openCsv (http://opencsv.sourceforge.net/), and I have no idea how to install it.
Java libraries don't really need to be 'installed' like other applications. All you need to do is put the jar file in a specific location, and add the jar file to your classpath. How you do that depends on the linux distro you are using. If you are making a web application in eclipse, you can drop the .jar file in the WebRoot/web-inf/lib folder, and it will be bundled in with your project.
Be sure that the path, which you place the libaries at, is set in the $CLASSPATH Environment Variable.
For Eclipse: Project -> Properties -> Java Build Path -> Add JARs...
It's up to you really - I use /opt/javalib, but you might consider a directory in /usr/local as well.
You can store them wherever you wish. You can store them within the JRE distribution directories, but I wouldn't recommend that.
Instead I would store them per-project (so you can have different versions for each project easily - some libraries have different names for each version, some don't) and adopt a standard such as a lib/ directory. That way you can have standard build scripts (Ant etc.) that can operate in the same way (if you're using Maven, then there's a standard place per-project - src/main/resources)
You could use Maven to manage any dependencies to those libraries.
Maven will automatically download all needed JAR files and put them in a local repository (the location is configurable).
This makes upgrading to new versions of various libraries very easy as you just declare the version you want and Maven does the rest.
Beware: Maven is something to get used to and the initial learning curve is steep.
The rewards come if you have everything set up properly and maven takes care of compiling, packaging, distribution, site creation, release management etc. etc. etc.
I am trying to avoid duplicating customBuildCallbacks.xml for all my plug-ins, when called from either PDE's headless build or the Eclipse GUI. I have in customBuildCallbacks.xml steps to generate code or modify the plug-in packaging that I:
obviously want to run with the headless build
would also like to run either when I export this plug-in from the GUI or from an external builder watching specific files in my plug-in
The headless build runs in a well defined environment, so I can set customBuildCallbacks.buildpath or even use a relative path in each plug-in's build.properties to point at my common customBuildCallbacks.xml. However, this is trickier from the GUI: that path is different for every developers since we do not have sources in the Eclipse workspace (we import projects from various locations due to our internal build process). I was hoping for every project to have an associated ant property holding its path on disk, similar to the ${workspace} variables exposed in various dialogs. I couldn't find anything useful though.
Does anyone have any experience doing this kind of things?
Thanks,
Romain