Community
Participate
Working Groups
If a bundle is imported into the workspace and then used in a subsequent build, PDE will create a jar for the bundle that contains the bundle itself. This doesn't cause a problem during build time, but at runtime. Setting to major as it results in an unstartable product. FYI Buckminster had the same problem and came up with a fixed in #212411
Why isn't an imported bundle just extracted into the workspace and a builder-less .project and .classpath generated? During bundle export the disc contents then simply needs to be jarred again.
Created attachment 107738 [details] draft patch This is my current take and I wonder if I'm on the right track so don't spare me with early feedback. :) I know it has a couple of limitations: - Utils.isBinaryProject(BundleDescription) isn't bullet proof yet - non archived product export is broken (unpack is ignored) - https://issues.apache.org/bugzilla/show_bug.cgi?id=42122 causes the extrated jar to have 000 permissions - subsequent exports fail - ... patch applies against 3_4_maintenance
Created attachment 107739 [details] mylyn/context/zip
Created attachment 107822 [details] revised patch This one works for us in our fairly complex product build (multi platform + archived and non archived product + update site). And even all the pde build tests pass. :) However, if a feature sets unpack=true for a jarred bundle (either originating from target platform or binary project), pde fails. We probably want to file a separate bug since this isn't directly related to this one.
Created attachment 107823 [details] mylyn/context/zip
Chris, Can you comment on the format of the project for the imported binary plugin. This patch essentially tries to identify such projects, and then copies the nested jar instead of using the project itself. One alternative would be for UI to identify such projects for us. And provide the info in a map akin to the existing classpath & patch data set in FeatureExportOperation.setupGenerator's call generator.setStateExtraData. Also, what about binary projects with linked content? This could cover both cases if UI told us the location of the real jar. Re: Comment #4 & unpack=true for jarred bundles, this is a long-standing problem. I meant to look at it in 3.4, but it slipped. Other Initial comments are: Utils.isBinaryProject: a) patch contains an extra "findDeltaPack" in Utils, leading to a compile error (gfindDeltaPacket) b) Moot if UI provides the binary info, but Bundle-Classpath headers are already stored in PDEState.bundleClasspaths by bundleId. We do not need to read the manifests again here. (Note also, Properties should not be used to read manifests, it wouldn't handle the line continuations, can use ManifestElement.parseBundleManifest instead). PackageConfigScriptGenerator: - The last line changed (in the feature loop) is not an equivalent change. This is a mistake?
The respective code in UI that identifies such projects is in: org.eclipse.pde.internal.core.WorkspaceModelManager.isBinaryProject(IProject) During import, we mark projects as binary by setting a persistent property on the project. So Andrew, we could easily pass this info to you if need be, just let me know where to do it.
(In reply to comment #6) > Chris, Can you comment on the format of the project for the imported binary > plugin. This patch essentially tries to identify such projects, and then > copies the nested jar instead of using the project itself. > > One alternative would be for UI to identify such projects for us. And provide > the info in a map akin to the existing classpath & patch data set in > FeatureExportOperation.setupGenerator's call generator.setStateExtraData. Does this work in headless mode where PDEUIState is null? > Also, what about binary projects with linked content? This could cover both > cases if UI told us the location of the real jar. Indeed, the current patch hasn't been tested with linked content. > > Re: Comment #4 & unpack=true for jarred bundles, this is a long-standing > problem. I meant to look at it in 3.4, but it slipped. Is there a bug open that tracks this issue? I have a partial patch lying around that handles this scenario partially. > Other Initial comments are: > Utils.isBinaryProject: > a) patch contains an extra "findDeltaPack" in Utils, leading to a compile error > (gfindDeltaPacket) s/gfindDeltaPacket/getProperty > > b) Moot if UI provides the binary info, but Bundle-Classpath headers are > already stored in PDEState.bundleClasspaths by bundleId. We do not need to > read the manifests again here. (Note also, Properties should not be used to > read manifests, it wouldn't handle the line continuations, can use > ManifestElement.parseBundleManifest instead). Perfect, I wasn't aware of that API. I'll revise the patch again. > PackageConfigScriptGenerator: > - The last line changed (in the feature loop) is not an equivalent change. > This is a mistake? Yep, damn you cut&replace.
Created attachment 108432 [details] as per previous comments yet again a revised patch
Created attachment 108433 [details] mylyn/context/zip
Any thoughts about this one for 3.5 Andrew?
(In reply to comment #11) > Any thoughts about this one for 3.5 Andrew? I'm not Andrew, but FWIW with bug #258820 and bug #260831 fixed in Buckminster, Versant doesn't need this fix any longer.
*** Bug 267180 has been marked as a duplicate of this bug. ***
Currently we are not actively enhancing PDE build anymore. Therefore, I close this bug as WONTFIX. Please reopen, if you plan to provide a fix.
