Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Workspace Product Export does not respect 'Eclipse-BundleShape: dir' Manifest-Header anymore #995

Closed
HannesWell opened this issue Dec 8, 2023 · 8 comments · Fixed by #1271
Closed

Workspace Product Export does not respect 'Eclipse-BundleShape: dir' Manifest-Header anymore #995

HannesWell opened this issue Dec 8, 2023 · 8 comments · Fixed by #1271
Assignees
@HannesWell
Labels
bug Something isn't working regression Regression defect

Comments

@HannesWell
Copy link
Member

When exporting a product from the workspace using PDE's product export the Eclipse-BundleShape: dir Manifest headers are not considered and plug-ins containing it are therefore not extracted.

To replicate just import the following simple product definition and export the my.product:
my.example.product.zip

This has the consequence that the exported product cannot even be launched since for example org.eclipse.equinox.launcher.* is not extracted and the launcher cannot find its companion shared library.
Thus this is a sever regression for those that use the product export (like us), probably from

I can take core of this later (probably at the weekend).
@HannesWell HannesWell added bug Something isn't working regression Regression defect labels Dec 8, 2023
@HannesWell HannesWell self-assigned this Dec 8, 2023
@laeubi
Copy link
Contributor

laeubi commented Dec 8, 2023

See also

@Rainer7000
Copy link

Is there any progress with this bug, or is it paused until #862 is resolved ?
I'm asking because after 2023-09 and 2023-12 this is the third time in a row that we are unable to update to the current version of eclipse because of a unresolved but already known bug. In this case the short term solution could be rather trivial (directory-unpack-flag gets ignored somewhere) and the complete rework of the PDE Export Wizard could lead to a very long development phase where the export-functionality is still broken in the eclipse-distribution.

@laeubi
Copy link
Contributor

laeubi commented Mar 19, 2024

If this is crucial to your business and likes to speed up the development you can contact me to enter a contract about this specific issue or if you need dedicated enterprise support.

Of course a PR to fix the problem would also be welcome as it seems you have developers at hand that are familiar with Eclipse RCP, see the contribution guides here and if Eclipse is an important Technology for you you maybe even want to join the Eclipse IDE Workingroup that also regularly funds development in critical areas or consider a sponsoring to improve Eclipse IDE in general.

@Rainer7000
Copy link

Rainer7000 commented Apr 3, 2024 •
edited by HannesWell
Loading

Unfortunately we are a rather small company and I'm the only Java-Developer, so our resources are very limited.
Although we decided to dedicate 100% of our java-developer-resources to the issue for quite sime time ;)
I could make out one of the commits that removed the unpack attribute from plugin-builds:
commit 824f124
Author: Alshama M S 2023-09-27 07:27:36
I have tried to reverse some of the changes but only could make it work for a simple test-product consisting of plugins.
When I tried to build our more complex feature-based product the changes had no effect.
It seems the feature to plugin resolution is done in a seperate process and the changed code isn't used for that.
Never the less I attach the patch that enabled the plugin-unpacking here for further refference.
product_build_unpack.patch

@fpapai
Copy link

fpapai commented May 14, 2024

hello,
We are in the same situation as Rainer700: 1 java developer, no resources/time to understand Eclipse internals to create a correct fix through a PR.

This bug breaks an important feature of Eclipse IDE: exporting plugins/applications.
Not sure why is not considered for a fix by Eclipse team for the next release.

@laeubi
Copy link
Contributor

laeubi commented May 14, 2024

Not sure why is not considered for a fix by Eclipse team for the next release.

Because there is no "Eclipse Team" that can fix issues for other companies (either large or small), see #995 (comment)

Still you can stay on older releases / toolchains if it works there for you but there is no grantee.

This bug breaks an important feature of Eclipse IDE: exporting plugins/applications.

Just because it is important for you don't mean its important for the wider audience, e.g. most companies simply have a CI pipeline that produce the artifacts, because exporting from the IDE is risky and error prone so that defiantly not something important for them.

I also wanted to mention that of course it is sensible for a group of affected users to work together or fund a campaign to pay someone to work on that (again feel free to contact me) I already did this in the past with success, the spirit of Open Source Software does not end when you download the next release ...

HannesWell added a commit to HannesWell/eclipse.pde that referenced this issue May 15, 2024
@HannesWell
[PDE-Build] Copy Eclipse-BundleShape and other headers in wrapped states
d4e543d 
For wrapped OSGi States obtained from pde.core/ui the Manifest
'Eclipse-BundleShape' entries, besides others, were not copied into the
bundle's user-object Properties. This had the consequence that in
ShapeAdvisor.getUnpackClause() the value of that entry never has been
considered.
The method only used to return the expected boolean value because of
corresponding unpack-attributes in 'plugin' entries of feature.xml
files. But since the removal of that otherwise unused attribute in [1]
this makeshift was gone and ShapeAdvisor.getUnpackClause() always return
false leading to all bundles in an exported product being in jar-shape,
even if the 'Eclipse-BundleShape' entry in the MANIFEST.MF told
something different.

Fixes eclipse-pde#995

[1] - eclipse-pde#770
HannesWell added a commit to HannesWell/eclipse.pde that referenced this issue May 15, 2024
@HannesWell
[PDE-Build] Copy Eclipse-BundleShape and other headers in wrapped states
ac2891c 
For wrapped OSGi States obtained from pde.core/ui the Manifest
'Eclipse-BundleShape' entries, besides others, were not copied into the
bundle's user-object Properties. This had the consequence that in
ShapeAdvisor.getUnpackClause() the value of that entry could never be
considered.
The method only used to return the expected boolean value because of
corresponding unpack-attributes in 'plugin' entries of feature.xml
files. But since the removal of that otherwise unused attribute in [1]
this makeshift was gone and ShapeAdvisor.getUnpackClause() always return
false leading to all bundles in an exported product being in jar-shape,
even if the 'Eclipse-BundleShape' entry in the MANIFEST.MF told
something different.

Fixes eclipse-pde#995

[1] - eclipse-pde#770
@HannesWell HannesWell mentioned this issue May 15, 2024
Merged
HannesWell added a commit that referenced this issue May 15, 2024
@HannesWell
[PDE-Build] Copy Eclipse-BundleShape and other headers in wrapped states
2afa4d3 
For wrapped OSGi States obtained from pde.core/ui the Manifest
'Eclipse-BundleShape' entries, besides others, were not copied into the
bundle's user-object Properties. This had the consequence that in
ShapeAdvisor.getUnpackClause() the value of that entry could never be
considered.
The method only used to return the expected boolean value because of
corresponding unpack-attributes in 'plugin' entries of feature.xml
files. But since the removal of that otherwise unused attribute in [1]
this makeshift was gone and ShapeAdvisor.getUnpackClause() always return
false leading to all bundles in an exported product being in jar-shape,
even if the 'Eclipse-BundleShape' entry in the MANIFEST.MF told
something different.

Fixes #995

[1] - #770
@HannesWell
Copy link
Member Author

HannesWell commented May 15, 2024 •
edited
Loading

This should now be fixed with #1271.
While working on this I noticed another potential problem in the export fixed in #1270.

@Rainer7000 and @fpapai please verify with tonight's I-build that this is really fixed. The link will probably be
https://download.eclipse.org/eclipse/downloads/drops4/I20240515-1800/

We are in the same situation as Rainer700: 1 java developer, no resources/time to understand Eclipse internals to create a correct fix through a PR.

This bug breaks an important feature of Eclipse IDE: exporting plugins/applications. Not sure why is not considered for a fix by Eclipse team for the next release.

Out of curiosity and assuming you work for the company you named in your GH bio, I wonder why a tech company from the silicon-valley with over 2000 employers (according to Wikipedia) has only one Java developer?
It's also funny that a company with over half a billion of revenue relies on a guy at the other end of the world spending two hours of his free-time to fix that bug (after working day time in a small company too).
I don't want to start the open-source is exploited song, just wanted to shed some light on what or better who the 'Eclipse-team' is. And of course there are also other contributors with individual circumstances, if you are interested please read https://github.com/eclipse-platform/#community

I fixed that out of conscientiousness, but in that sense: Quality contributions are more welcome and the most reliable way to ensure that your needs are met. Besides that you can also learn a lot about Eclipse, which can be beneficial for your own products based on Eclipse.

@Rainer7000
Copy link

I checked the I-Build, but unfortunately the issue is only 'half-fixed'.
The launcher plugin org.eclipse.equinox.launcher.win32.win32.x86_64_1.2.1000.v20240507-1834 gets extracted in the build,
but a workspace-plugin which i tagged with Eclipse-BundleShape: dir gets exported as a jar.
I attach my test-project for analysis.
TestAppRCPAndPlugin.zip

fedejeanne pushed a commit to fedejeanne/eclipse.pde that referenced this issue Jul 31, 2024
@HannesWell @fedejeanne
[PDE-Build] Copy Eclipse-BundleShape and other headers in wrapped states
bb499b6 
For wrapped OSGi States obtained from pde.core/ui the Manifest
'Eclipse-BundleShape' entries, besides others, were not copied into the
bundle's user-object Properties. This had the consequence that in
ShapeAdvisor.getUnpackClause() the value of that entry could never be
considered.
The method only used to return the expected boolean value because of
corresponding unpack-attributes in 'plugin' entries of feature.xml
files. But since the removal of that otherwise unused attribute in [1]
this makeshift was gone and ShapeAdvisor.getUnpackClause() always return
false leading to all bundles in an exported product being in jar-shape,
even if the 'Eclipse-BundleShape' entry in the MANIFEST.MF told
something different.

Fixes eclipse-pde#995

[1] - eclipse-pde#770
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@HannesWell HannesWell

Labels
bug Something isn't working regression Regression defect
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[PDE-Build] Copy Eclipse-BundleShape and other headers in wrapped states HannesWell/eclipse.pde
4 participants
@fpapai @laeubi @HannesWell @Rainer7000