When using different workspaces for different SDKs, e.g. Appengine, Android & basic Java development, how can I make sure, only the required plugins are loaded when launching the desired workspace?
The trick is to specify a different configuration folder. Use the -configuration argument when launching Eclipse.
By default, you get something like this:
eclipse/
plugins/
features/
configuration/
By specifying a separate configuration folder, all those 4 folders will move to a new location. I usually use a folder called configs and add several numbered folders under it. So, I get something like:
eclipse/
plugins/
features/
configs/
c1/
plugins/
features/
configuration/
c2/
plugins/
features/
configuration/
To do that, use the argument -configuration configs/c1/configuration. When running a given instance and installing plugins, they will be installed in the relevant location.
You can also add -data argument and specify the workspace folder location, or select it when Eclipse launches.
I don't think plugins are a function of your workspace. You'd probably need to have separate Eclipse installations. Or, there's a way to do a "shared" install, whereby the binary is in one place and the plugins are in another. That must mean that there's a startup parameter to tell it where to find plugins. Perhaps you could leverage that?
Related
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.
When i click add in the target-editor i can choose between:
Directory (just plug-ins on the filesystem)
Installation (only plug-ins, too?)
Features (one or more from the filesystem)
and Software Site (e.g. p2-repository)
So what's the difference between a installation (such as eclipse-SDK) and a directory, when the installation just fetch the plugins? I thought a installation would resolve my features, too. But it seems there is another difference, so what's the benefit?
Edit: Note if you want to use features with the type "installation", it's necessary to unjar the features.
An Eclipse installation contains metadata as to what was installed via Help -> Install New Software and other similar means. Since the installation process verifies dependencies, you know that your target platform is valid and will run. Defining target via an install will use the install's metadata to populate the target. Note that Eclipse has not been automatically detecting plugins copied into the plugins directory for several years now.
If you define a target by pointing at a folder that you put together by copying plugins, you do not know if the dependencies of those plugins are satisfied, so your target may not run.
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.
in my Java Eclipse project that contains JUnit tests, I also have a package "resource" that contains all input data used for the tests. But when compiling JUnit tests, the Java compile also data available in resources, so I find the same data in the "bin" folder. Is there a way to avoid this?
thanks.
If you have a particular package within the source path you want to exclude (your resources folder for example), you can right click on the package and select: Build Path > Exclude.
This will tell Eclipse that you don't want to include that package as part of the build.
This is making a couple of assumptions: that you're using Eclipse Helios (because the option might be different in older versions), and that the resources are stored in the same folder as your regular java source files (because if resources is in a folder by itself, you can remove that entire folder from the build by using Build Path > Configure Build Path -> Source tab.
Update:
After the discussion in the comments regarding why you would or would not want to copy resources into the bin directory:
The contents of your bin directory should be ignored and not checked into to a version control system (when using CVS, bin should be an entry in the .cvsignore file)
The resources are only duplicated on your local machine, which is fast and hard discs are big. I'm not sure you should be worrying about this
If you're using Class.getResource to access those resources, they need to be on the classpath somewhere. The bin directory is as good a place as any
So, realistically (barring some unknown, like the files are hundreds of gigabytes or something), I don't think you need to be concerned about excluding these files from the build.
I am currently trying to get my headless pde-build working but I am stuck on a point where I do not know how to continue.
The problem is how to define the related target platform to compile the plugins against.
I have a build.bat with the following call (all in one line!):
java -jar D:\target\eclipse\plugins\org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
-application org.eclipse.ant.core.antRunner
-f D:\target\eclipse\plugins\org.eclipse.pde.build_3.5.2.R35x_20100114\scripts\productBuild\productBuild.xml
-Dbuilder=c:\pde-build\scripts %*
I tried to create the target eclipse platform from different parts: The eclipse SDK, RCP SDK, Delta Pack, PDE-SDK in all combinations but none of them worked well.
I got the following error:
BUILD FAILED
D:\target\eclipse\plugins\org.eclipse.pde.build_3.5.2.R35x_20100114\scripts\productBuild\productBuild.xml:18: Cannot fin
d ${eclipse.pdebuild.scripts}/build.xml imported from D:\target\eclipse\plugins\org.eclipse.pde.build_3.5.2.R35x_2010011
4\scripts\productBuild\productBuild.xml
where the variable ${eclipse.pdebuild.scripts} does not got resolved. I also tried to give this parameter via the command line but then I got another error regarding missing svn task which is absolutely confusing as this is working with my local eclipse installation referenced.
When I replace the path from d:/target/eclipse to my local eclipse installation the pde build works as expected!
This leads my to the point that the configuration of the target eclipse is not correct but in the moment I have no idea how to configure this!
My goal is the automate the pde build first on my local site without referencing my local eclipse and later on integrate this building process into our running cruisecontrol instance.
As I saw already another question about defining the target eclipse I would be happy if anyone can contribute hints or facts regarding the problem.
Regards,
Andreas
When performing a headless build, the target can be separate from the eclipse that is actually running the build itself. The problem you had here is that the eclipse that you were using to run the build did not have PDE/Build properly installed.
This is why the ${eclipse.pdebuild.scripts} was not set, because PDE/Build was not installed into that eclipse instance, the org.eclipse.pde.build bundle was not resolved and the code that sets this property never got called. Similarly, the necessary ant classpath entries for PDE/Build tasks would not have been set up properly either.
You need the Eclipse with PDE installed inside to run the build, but the target for the build can be separate from this.
In the build.properties file found under -Dbuilder=c:\pde-build\scripts you can set several properties:
baseLocation This is a path to an eclipse that is your target.
buildDirectory This is where the build will actually take place, source is fetched to plugins/ and features/ subfolders, but if there are already binary plugins located here then those become part of the target as well.
pluginPath This is a list of paths (separated with ';' on windows or ':' on linux) containing other locations that should be considered as part of your target. These locations can be several things:
The root of an eclipse-like install with plugins/ and features/ subfolders. This is a good way to provide the delta-pack instead of just unzipping it on top of an eclipse install.
The root of a workspace-like folder, where all subfolders are treated as plugins or features depending on the presence of a manifest or feature.xml.
The root of a bundle or feature, or the jar for a bundle.
If you are doing a p2 build (p2.gathering = true) you can also provide p2 repositories under a ${repoBaseLocation} which will be transformed and placed under ${transformedRepoLocation} and will become part of your target, and the p2 metadata there will get reused during the build.
after some more time of investigation I found out, what I did wrong so far. As I mentioned above defining the target platform is not that easy as copying the SDK and plugins in into one location (as it was in early times of eclipse dev).
The working solution by now is the following: Copying the eclipse SDK into the target location and run this version. Install inside this the neccessary PDE-Tools to enable plugin development. After that, close the IDE and copy the delta pack + the respective svn plugin (I used org.eclipse.pde.build.svn-1.0.1RC2 from sourceforge) into the target platform and you're done.
Now my automated PDE build is running as expected.
Only minor issue now is the following: The result product contains eclipse-specific menu entries which are not there when I ran this from inside my dev-eclipse.
Any hints on that?
I just posted an answer to my question on this kind of topics, may be this can help you:
Plugin product VS Feature product