Community
Participate
Working Groups
N20120114-2000. When reading/loading a target it fails to read the manifest for one my JARs (see picture1). This used to work with 3.8 M4. When I then disable the JAR but don't restart, it tells me that it can't find the JAR (see picture2). The very bad thing here is that it completely aborts to load the target and I'm doomed.
Created attachment 209570 [details] picture1
Created attachment 209571 [details] picture2
I had seen something similar (bundle x could not be found), but it was caused by a bad install. Will investigate asap.
I also got the bug with latest M-build (M20120111-0800) but there it seemed to better recover from the failure than in N20120114-2000 (see picture3). Wild guess: caused by bug 355890 (which got backported).
Created attachment 209573 [details] picture3
So there are several issues here: 1) In 3.8 if there is a problem creating a target bundle a core exception is thrown all the way to the container resolving causing resolution to fail fast. This is caused by changes to the target API earlier in 3.8 and can be fixed by catching the exception inside the containers and creating InvalidTargetBundles. 2) I have a broken install that lists bundles in my bundles.info that don't exist on the file system. This surfaces problem (1) but does not require any additional changes to PDE. 3) The target does not respect plug-ins that are not bundles. The bundle causing Dani problems is not an OSGi bundle (manifest.mf contains jar entries not bundle information, actual bundle information is in plugin.xml). Since Dani says this was working with M4, I expect the fix for bug 367164 is too aggressive. This fix will have to be backported.
Note that if you use a directory location or an installation location that points to a simple directory, the problematic bundle will be ignored. This is to avoid polluting the target with errors for files that are not bundles that just happen to be in the directory. The non *.jar fix surfaces this more often after files of any extension are now checked for validity.
Dani, can you confirm that your example bundle is actually read in M4? As far as I know, PDE only supports non OSGi bundles unjarred. Going back as far as 3.5 the target platform only checks the plugin.xml if the file is unjarred. I downloaded M4 and tried it and got an NPE. If I extract the bundle and try it again, it works fine (in both.M4 and latest).
(In reply to comment #8) > Dani, can you confirm that your example bundle is actually read in M4? As far > as I know, PDE only supports non OSGi bundles unjarred. Going back as far as > 3.5 the target platform only checks the plugin.xml if the file is unjarred. I > downloaded M4 and tried it and got an NPE. If I extract the bundle and try it > again, it works fine (in both.M4 and latest). Note that the NPE should be bug 366405. Already marked for M5
(In reply to comment #8) > Dani, can you confirm that your example bundle is actually read in M4? Sorry, no. It works on 3.8 M3 but fails on 3.8 M4. This is what I see in more detail: Having my JAR in a custom location and then launch Eclipse works in all builds I tested back to 3.5.2 (i.e. my bundle gets activated and e.g. the 'Mixed Line Delimiters' search page is available). If I append ".off" to the JAR name it is consistently not activated in all builds (expected). Loading the target differs. I first deleted all targets, then did the following test for each build: 1. open 'Target Platform' preference page 2. click 'Restore Defaults' 3. click 'Edit' If the file ends with *.jar: 3.5.2, 3.6.2, 3.7, 3.7.1: loading works and my bundles is visible 3.7.2/M20120111-0800: loading gives read error but only on the failing JAR 3.8 M4: loading gives NPE (logged) and fails entirely N20120116-2000: loading gives read error and fails entirely (worse than in 3.7.2 build). If the file ends with "*.off" loading works and the bundle is not listed (expected).
I have fixed the fail-fast behaviour in master. The hashtag for the change is below, but git.eclipse.org is listing no repositories currently. 0d84238e4fd1050c5e3d54d2ddea8dfd787a9422
(In reply to comment #10) > If the file ends with *.jar: > 3.5.2, 3.6.2, 3.7, 3.7.1: loading works and my bundles is visible > 3.7.2/M20120111-0800: loading gives read error but only on the failing JAR > 3.8 M4: loading gives NPE (logged) and fails entirely > N20120116-2000: loading gives read error and fails entirely (worse than in > 3.7.2 build). > > If the file ends with "*.off" loading works and the bundle is not listed > (expected). We must be working on different bundles or something. Using 3.6.2 Build id: M20110202-0800 I cannot open it. Looking at the code, I don't see any way it could work as there is an explicit check that an old style plugin.xml manifest is only checked if the bundle is unjarred. If I unjar the bundle it works fine. Can you plesae email me the bundle you are testing on?
(In reply to comment #11) > I have fixed the fail-fast behaviour in master. The hashtag for the change is > below, but git.eclipse.org is listing no repositories currently. > 0d84238e4fd1050c5e3d54d2ddea8dfd787a9422 Verified that fail-fast has been fixed in N20120119-2000. But it still fails to read the JAR. (In reply to comment #12) > (In reply to comment #10) > We must be working on different bundles or something. Using 3.6.2 Build id: > M20110202-0800 I cannot open it. Looking at the code, I don't see any way it > could work as there is an explicit check that an old style plugin.xml manifest > is only checked if the bundle is unjarred. If I unjar the bundle it works > fine. > > Can you plesae email me the bundle you are testing on? It's the one I already sent you, but I sent it again now. Also, I attached picture4, showing you that it really works in 3.6.2 (like it also does in 3.5). In case it matters: - I start with -Dosgi.clean=true - The JAR is linked in by adding a 'links' folder which has a '.link' file with this entry: path=C:/eclipse/customPlugins
Created attachment 209802 [details] picture4
(In reply to comment #13) > In case it matters: > - I start with -Dosgi.clean=true > - The JAR is linked in by adding a 'links' folder which has a '.link' file > with this entry: > path=C:/eclipse/customPlugins I can finally reproduce by taking a 3.6.2 build, creating a links folder setup and starting with osgi clean. Having it as a linked folder must cause the target to use some obscure code path that was removed when working on target platform code. Assuming the code that reads jarred non-osgi bundles is reasonable, we can provide a fix for all types of target locations.
This is interesting. Jarred non-osgi plug-ins have been broken in the target platform code since 3.4! The target usually throws away plug-ins of this type because we can't read the necessary information (what happens when using a directory location). By using a links folder, p2 installs the old bundle and adds an entry to the bundles.info containing id/ver/url. When using an installation location, we actually are still failing to read the information from the plug-in manifest. However, this is hidden from the user because the UI uses the information from bundles.info! Everything works once the target platform is loaded because the OSGi state is able to load the plug-in. The most likely fix to this is to pull out the plugin.xml from jarred files and try reading the necessary information. There is a performance cost associated with this, but it should not happen excessively as most non-bundle archives files in the target folder will not have plugin.xml unless they are non-osgi plug-ins. The fix should be reasonably small, so we can consider backporting to 3.7.2 (though 3.4, 3.5, 3.6 will still be broken). I am reducing the severity because of how obscure this is. Dani, why do you have a jarred pre-3.1 (7 release old!) plug-in in your install? Assuming you are not developing against it, the fix to the fail fast behaviour means that you will have a usable target platform. It has been discussed many times whether PDE should support non-OSGi bundles at all. ( if (map == null || map.get(Constants.BUNDLE_SYMBOLICNAME) == null) { throw new CoreException(new Status(IStatus.ERROR, PDECore.PLUGIN_ID, 0, NLS.bind(Messages.DirectoryBundleContainer_3, bundleLocation.getAbsolutePath()), null)); }
I have committed a fix to master for this so it will be in the N builds (not integration). We can decide on Monday if we want to put it in for M5 and backport to 3.7.2. The fix is pretty reasonable as the plugin converter works for jars as well as directories. The javadoc suggests otherwise (opened bug 369306) which may be the reason why this was broken in 3.4. 497e9d66f660c7096515d84055b0981201bff835
While I tested a nightly build and was happy with the results, I don't think it is necessary to push these changes in for M5. Bumping to M6
> Dani, why do you > have a jarred pre-3.1 (7 release old!) plug-in in your install? Because it works in my dev workbench. Why should I spend time to updated all my helper plug-ins with every release if they still work? > Assuming you > are not developing against it, Correct, I'm only using its functionality in my dev workbench. > the fix to the fail fast behaviour means that > you will have a usable target platform. Yes, that's fine for me. I was never aware that it didn't work in the target since that was never my use-case. I'm fine in closing this bug here as FIXED with only the fail fast fix. At any rate, I think we should backport to 3.7.2.
> I'm fine in closing this bug here as FIXED with only the fail fast fix. At any > rate, I think we should backport to 3.7.2. Sight! I mean "SHOULD NOT BACKPORT".
Verified in I20120124-2000 that the fail fast bug is fixed.
Integration branch has been caught up to master, so the fix will be in the next I build. (In reply to comment #19) > > Dani, why do you > > have a jarred pre-3.1 (7 release old!) plug-in in your install? > > Because it works in my dev workbench. Why should I spend time to updated all my > helper plug-ins with every release if they still work? Eclipse doesn't make major changes like the introduction of OSGi every release :) Having the bundle around helped catch an edge case, so I can't complain, but eventually PDE will no longer be backwards compatible all the way to Eclipse 3.0.
Verified in N20120201-2112.
