Community
Participate
Working Groups
OVERVIEW ======== I work for MKS Inc. and I am currently building an integration between our SCM application (Source Integrity) and the new Team API (org.eclipse.team.*) included in the eclipse 2 platform. My plugin will be an adapter that connects our private API and the eclipse workbench. Our API is currently packaged as a JAR and installed with our product in the %siinstallhome%/bin directory. The first approach I tried was right-click on the project->properties->Java Build Path->libraries->Add External Jar. I browsed to the location of the jar and selected it. It seemed to work. I could access classes and methods in the jar without compile errors. But I found 2 problems with it. The first was that every time I updated the plugin.xml file, it updated the classpath and removed the reference to my external jar causing a whole bunch of compile errors. I had to re-add the reference manually every time. The second problem was that even though I have the box checked in the libraries page (for export I thought) it would not add the jar or the jar's class files in the proper locations when I did either "Run in runtime workbench" or "Create Plugin Jars". I would get NoClassDefFound errors and exceptions all over the place. I had to manually add the class files into the bin directory. The second approach I tried was to add the jar location as a variable in the global (workbench) java preferences. Then I added it to the project again from the libraries page, but by chosing Add Variable and I checked the export box. Again I had access to the source at compile time, but the export feature still did not work properly. The third approach I tried was to make a Java project in the object tree of my compiled source for our API. I then added it as a project reference in my plugin project. This again gave me compile level access to the source, but I still have trouble exporting it. Maybe this was because the workbench doesn't build that project - I am really confused now. The other thing it did was change the icon on my plugin project to the icon used for java projects. I still have not figured out if it will have any negative effects on the plugin. It still removed the reference every time I changed the plugin.xml file which updates the classpath and I had to re-add the project reference. Ideally ======= The best solution would be to be able to use windows system environment variables or registry keys to look up and access the JAR that is installed with our product instead of bundling up another copy of it with the plugin. We currently manually insert the class files into the completed plugin jar to get everything to work. This also effects our patch process forcing us to re-issue the workbench plugin if we make minor changes to our API - which would not be required if we could use some other inclusion mechanism. I am open to any work around solutions that would at least allow me to include external Jar (and have it stay on classpath update) and get it exported on builds and test-runs of the runtime workbench. Thanks, Adam.
Adam, your comments about adding external JARs references could be reviewed after 2.0. In order to solve your problem you cannot depend on external JARs. All plug- ins have to be self-contained or depend on other plug-ins. You can provide the external JARs in a plug-in library (like the way we provide Xerces in the org.apache.xerces and JUnit in the org.junit plugin). Doing so, your plugin can require the plug-in library and the JARs will be available for it.
The Team API is built to interact with outside repository providers and their installed clients as an integration with a minimal level of effort on the workbench side. The entire purpose of it is to access outside code so that the developer does not have to leave the workbench interface to reap the benefits of source code control. Thank you for your comments - I have searched help and not found any crisp documentation on how to set up a 'plug-in library' that contains the jar. Could you be more specific with instructions on how to set this up and make sure the export works appropriately so that my JAR is bundled with the plug-in? Thanks, Adam.
Basically you will have to create a plugin that contains all JARs you need and declare these JARs as plug-in libraries. Here is the plugin.xml for xerces as an example: <?xml version="1.0" encoding="UTF-8"?> <plugin name="%pluginName" id="org.apache.xerces" version="4.0.3" provider-name="%providerName"> <!-- This is an IBM maintenance branch of xerces 2.0.0 --> <runtime> <library name="xmlParserAPIs.jar"> <export name="*"/> </library> <library name="xercesImpl.jar"> <export name="*"/> </library> </runtime> </plugin> If you do not or cannot have a plug-in with these JARs, another alternative would be to build a ClassLoader that knows how to find the JARs in order to load the necessary classes but this solution can be very tricky to get done right. I recomend the plug-in library approach.
Thanks for all of your help Rodrigo. Do I have to copy my JAR into my local plugin file structure for this to work? But then just out of curiosity - what is the "Add External JARs" button on the Project Properties -> Java Build Path -> Libraries page used for if it doesn't work as expected? It would seem to me that this is exactly what that button should do. Thanks again, Adam.
Yes, you do have to copy all the JARs to the plugin folder. The Add External JARs option may not be useful if you are a plug-in developer - and you can get confused like happened to you - but if your Java project is not a plug-in, that's exactly what you want.
Thanks again for all of your input. I guess you can close this issue or whatever you have to do with it. Adam.
*** This bug has been marked as a duplicate of 3074 ***
Copying external jar-files is not acceptable for us. - We do version libraries only once - Libraries are on a central server and only referenced by projects - Not every project creates a jar file, but should be possible to get referenced in a plugin as project I see no reason why defining dependencies in Properties->Build-Path->Libraries and mark as export should not also work in PDE. A solution for this problem is as follows: At Build-Time the referenced projects should be compiled and internally added as a jar. External jars should be included at build-time. e.g.: Plugin-project MY_PLUGIN - contains no jar files and only its own source-files - references project (not a plugin) MY_PROJECT - references jar-file \\central-server\jars\xy.jar when building the jars and externalk sources are included in the deployment (but not the source!): MY_PLUGIN-deployment: - contains plugin.jar - contains myProject.jar - contains xy.jar