Bug 19327 - Problems including external Jars in PDE project.
Summary: Problems including external Jars in PDE project.
Status: RESOLVED DUPLICATE of bug 3074
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 2.0 F3   Edit
Assignee: DJ Houghton CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-06-05 10:28 EDT by Adam Terrenzio CLA
Modified: 2005-01-12 13:26 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Terrenzio CLA 2002-06-05 10:28:27 EDT
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.
Comment 1 Rodrigo Peretti CLA 2002-06-05 11:00:12 EDT
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.
Comment 2 Adam Terrenzio CLA 2002-06-05 11:14:48 EDT
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.
Comment 3 Rodrigo Peretti CLA 2002-06-05 11:23:40 EDT
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.
Comment 4 Adam Terrenzio CLA 2002-06-05 11:27:54 EDT
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.
Comment 5 Rodrigo Peretti CLA 2002-06-05 11:37:24 EDT
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.
Comment 6 Adam Terrenzio CLA 2002-06-05 11:53:30 EDT
Thanks again for all of your input.
I guess you can close this issue or whatever you have to do with it.
Adam.
Comment 7 Rodrigo Peretti CLA 2002-06-05 12:06:22 EDT

*** This bug has been marked as a duplicate of 3074 ***
Comment 8 Michael Wenig CLA 2003-08-11 11:38:38 EDT
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


Comment 9 John Arthorne CLA 2005-01-12 13:26:45 EST

*** This bug has been marked as a duplicate of 3074 ***