Comment 1 Gary Karasiuk 2004-11-12 13:21:42 EST

Created attachment 15829 [details]
The .log file

Comment 2 Gary Karasiuk 2004-11-12 13:24:07 EST

Created attachment 15830 [details]
sample plugins

This zip file contains the three plugins that I was testing.

Comment 3 Pascal Rapicault 2004-11-12 13:51:52 EST

Although not optimal for running large products this mode should be supported 
but it seems that there is a bug, since the inner jars do not get unzipped into 
the org.eclipse.osgi folder of the configuration area.

A better approach for running large products out of jars is to:
- unzip the code jar at the same level than the resources (or in a folder)
- change the library entry in the plugin xml to refer to the source

For example: org.eclipse.perfmsr.core will become (in the top level jar):
plugin.xml (with library set to "binaries/")
binaries/
  org/eclipse/perfmsr/core/A.class
  org/eclipse/perfmsr/core/B.class
  ...

If you want to have the class files at the root, the library value becomes ".".

Assigning to Tom to investigate the initial problem.

Comment 4 Pascal Rapicault 2004-11-12 14:00:01 EST

Never mind, the windows explorer tricked me.

Comment 5 Gary Karasiuk 2004-11-12 14:05:48 EST

Created attachment 15831 [details]
.log file

This is the .log file from my second attempt. In this attempt I:

1) deleted the source jars
2) expanded and then removed the code jars
3) copied the manifest file from the configuration directory, but removed the
classpath line
4) edited the runtime stuff out of the plugin.xml file

So this version of the plugins do not have any nested jar files

Comment 6 Gary Karasiuk 2004-11-12 14:07:23 EST

Created attachment 15832 [details]
plugins 

The plugin jar files that Iused for my second attempt

Comment 7 Thomas Watson 2004-11-12 14:17:02 EST

Pascal, I looked into the initial problem.  The jars are extracted.  It is the 
PluginConverter that does not seem to generate the Provide-Package list 
correctly for the inner jars.  So the framework cannot find packages from 
required bundles.

Comment 8 Thomas Watson 2004-11-12 14:20:55 EST

Gary, the manifest files you copied in comment 5 will be incorrect because 
they are missing the Provide-Package header.  This will cause the same errors 
to occur as your original jar'ed bundles.  You should look at using the 
manifest files that get generated for you plugins when the are fully extracted 
plugins.

Comment 9 Pascal Rapicault 2004-11-12 14:28:13 EST

I've been tricked by the file explorer :) 
What is interesting that if I unjar the plugins to be like in eclipse the plugin
works fine. If I run from the jar, some classes are being found but there is
this strange exception that I haven't figured out yet (and won't be able to
address today).

Tom if you want to keep the investigation, go ahead. I'm not sure why in case of
zipped plugin we would generate a bogus manifest.

Comment 10 Gary Karasiuk 2004-11-12 14:34:04 EST

Re: Comment 8

I can confirm, that once I manually added in the Provide-Package header that 
my plugins worked!

Comment 11 Gordon Hirsch 2005-02-23 13:47:33 EST

I ran into this problem while experimenting with the JavaWebStart/JNLP support.
I debugged a bit, and the problem seems to happen in the
PluginConverterImpl.getExports() method. This is where the jars containing the
plugin classes need to be scanned to build a exported package list. In the
jarred plugin case however, the jar file containing the classes is not correctly
found, so the export list is empty. The following code is where things start to
go wrong. pluginManifestLocation is the plugin jar file and libEntryText is the
name of the library within the jar, so libraryLocation becomes non-existent. 

File libraryLocation;
if (DevClassPathHelper.inDevelopmentMode()) {
...
} else
    libraryLocation = new File(pluginManifestLocation, libEntryText);
Set exports = null;
if (libraryLocation.exists()) {
    if (libraryLocation.isFile())
        exports = filterExport(getExportsFromJAR(libraryLocation), filter);
//TODO Need to handle $xx$ variables
    else if (libraryLocation.isDirectory())
        exports = filterExport(getExportsFromDir(libraryLocation), filter);
} else {
...

Comment 12 Pascal Rapicault 2005-04-01 12:00:27 EST

Consider for M7.
Patches welcomed.

Comment 13 Pascal Rapicault 2005-05-09 12:48:21 EDT

The launcher feature in the delta pack is not up-to-date. Please try to replace
the launcher feature of the delta pack with the one attached in bug #93171

Comment 14 Pascal Rapicault 2005-05-09 12:49:17 EDT

Wrong bug report.

Comment 15 Pascal Rapicault 2005-05-31 15:45:49 EDT

DJ and I did separate evaluations on how to fix this bug, and we both came to
the same conclusion: "nay, too risky, too complicated for this late in the game".

I will even go further saying that this is a wontfix because:
- Eclipse 3.1 recommends shipping with MANIFEST.MF
- Manifest support is now first class in PDE (which used a counter argument as
to why we should not ship manifest before)

I opened bug #97689 to add something in the README.

Comment 16 Gary Karasiuk 2006-07-10 07:15:57 EDT

Cleaning up old defects.