Remove unused attributes in auto-generated feature.xml #770

alshamams · 2023-09-27T05:55:42Z

This commit removes some of the unused attributes of plugin element, which are redundant and are never read from a feature.xml file: install-size, download size and unpack attributes.

Fixes: 730

github-actions · 2023-09-27T06:12:50Z

Test Results

    270 files ±0     270 suites ±0 1h 14m 13s ⏱️ + 6m 46s
  3 327 tests ±0   3 297 ✔️ ±0 30 💤 ±0 0 ❌ ±0
10 278 runs ±0 10 188 ✔️ ±0 90 💤 ±0 0 ❌ ±0

Results for commit 67a7a83. ± Comparison against base commit 6465a65.

♻️ This comment has been updated with latest results.

alshamams · 2023-09-27T07:05:45Z

I did not remove the fragment attribute, as it causes warnings in feature.xml compiler. I will investigate where the compiler is processing that, and create a separate PR to take that out

alshamams · 2023-09-27T07:06:04Z

Investigating the test failures.

HannesWell · 2023-09-27T19:53:10Z

@alshamams thanks for working on this.
It looks like this change can go much further and remove all modelling of all attributes mentioned in #730 (comment) as well as their reading and writing and the UI support for them.
Eventually they should not be written, read or displayed in the UI. For existing Features (e.g. from a target-platform) those attributes should just be ignored. New or modified features should have them removed (which I assume happens automatically if they are not read and written on changes, so you don't have to add some logic to actively remove them).
To make it short, anything that belongs to those attributes should be removed.

...clipse.pde.ui.tests/src/org/eclipse/pde/core/tests/internal/feature/FeatureDataTestCase.java

HannesWell · 2023-09-28T21:15:45Z

Thanks @alshamams, after a quick look this looks much better. 👍🏽
I'm away over the weekend until mid of next week, but will review it in detail when back.
Of course everybody else review is also welcome.

HannesWell

I reviewed this in detail and everthing that was removed is fine.
There was just a little bit more to remove.
In FeaturePlugin the fFragment field can be removed and instead isFragment() returns if the PluginBase model is a fragment. The returned value is only considered to select the icon of an included Plugin in the Feature editor.
This also removes the fragment attribute, which should not be read or written anymore.

The method FeatureExportOperation.setAdditionalAttributes() can be removed because all overrides are now removed and the texts for all removed elements in the PluginDetailsSection in the Feature Edeitor can be removed too.

For all of that I have pushed another commit at the tip of your branch.

I also verified that with your change and all the unnecessary attributes are not written and displayed anymore. 👍🏽

Please address the only remaining comment and squash all your commits and mine into one commit with a reasonable overall message.
Then I think this should be ready for submission.

@laeubi can you tell if Tycho already handles features with all those features removed properly?

HannesWell · 2023-10-04T22:52:47Z

ui/org.eclipse.pde.core/src/org/eclipse/pde/internal/core/builders/FeatureErrorReporter.java

+					String id = attr.getValue();
+					int severity = CompilerFlags.getFlag(fProject, CompilerFlags.F_UNRESOLVED_PLUGINS);
+					if (severity != CompilerFlags.IGNORE) {
+						IPluginModelBase model = PluginRegistry.findModel(id);
+						if (model == null || !model.isEnabled()) {
+							VirtualMarker marker = report(NLS.bind(PDECoreMessages.Builders_Feature_reference, id),
+									getLine(plugin, attr.getName()), severity, PDEMarkerFactory.CAT_OTHER);
+							addMarkerAttribute(marker, PDEMarkerFactory.compilerKey,
+									CompilerFlags.F_UNRESOLVED_PLUGINS);
+						}
+					}


Instead of implementing a logic without isFragment I think it is sufficient to remove that parameter from validatePluginExists and remove the associated logic in that method and then just call:

Suggested change

String id = attr.getValue();

int severity = CompilerFlags.getFlag(fProject, CompilerFlags.F_UNRESOLVED_PLUGINS);

if (severity != CompilerFlags.IGNORE) {

IPluginModelBase model = PluginRegistry.findModel(id);

if (model == null || !model.isEnabled()) {

VirtualMarker marker = report(NLS.bind(PDECoreMessages.Builders_Feature_reference, id),

getLine(plugin, attr.getName()), severity, PDEMarkerFactory.CAT_OTHER);

addMarkerAttribute(marker, PDEMarkerFactory.compilerKey,

CompilerFlags.F_UNRESOLVED_PLUGINS);

}

}

validatePluginExists(plugin, attr);

szarnekow · 2023-10-05T06:53:55Z

@HannesWell Do I read this part as you intended?

In FeaturePlugin the fFragment field can be removed

Is this a breaking change? Would existing feature.xml files no longer be understood by the newest revision of the parser?

Why I am asking this:
We build a product based on Eclipse, compatible with many Eclipse versions. We use multiple target platforms in our build as a sanity check to ensure that we can compile against old and new versions before we run our tests against different TPs, too. Our workspace doesn't have any warnings.
Old versions require the fragment property to be present in the feature.xml if the feature includes a fragment. If the new version doesn't allow this anymore, it will not be source-compatible and require a major version increment. Would it be worth it?

HannesWell · 2023-10-05T23:26:39Z

In FeaturePlugin the fFragment field can be removed

Is this a breaking change? Would existing feature.xml files no longer be understood by the newest revision of the parser?

It shouldn't be a breaking change. For existing feature.xml the now unsupported attributes are simply ignored. And the other way round if e.g. the download-size attribute is absent a current Eclipse simply shows a 0 in the Editor.
You can verify that by simplify removing the attributes to be discontinued in a current workspace.

Our workspace doesn't have any warnings.
Old versions require the fragment property to be present in the feature.xml if the feature includes a fragment.

Yes a missing fragment attribute leads to a warning.
If that isn't possible it also isn't a problem to keep the fragment attribute (or the others) as they are then simply ignored. Those attributes are not even reported as Illegal attributes since the validation is (for now) kept intact:

eclipse.pde/ui/org.eclipse.pde.core/src/org/eclipse/pde/internal/core/builders/FeatureErrorReporter.java

Lines 124 to 126 in 6b0f0ed

    
           } else if (!name.equals("os") && !name.equals("ws") && !name.equals("nl") //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$ 
        
           		&& !name.equals("arch") && !name.equals("download-size") //$NON-NLS-1$ //$NON-NLS-2$ 
        
           		&& !name.equals("install-size") && !name.equals("filter")) { //$NON-NLS-1$ //$NON-NLS-2$

Some time later we can consider to remove even that so that a Illegal attribute will be issued for them if they are present.
The only inconvenience is that each time you modify a feature.xml through the editor all unknown attributes get removed.

But what makes me wonder, why can't you just use the latest Eclipse release?
Once a Feature is build and is in the TP it should not be validated anymore by the FeatureErrorReporter, so downstream consumers should not be affected.

HannesWell · 2023-10-05T23:28:23Z

I also checked Tycho. A feature.xml without install-size, etc. can be build even with a current Tycho. But at the moment Tycho then still adds the install/download-size into the build feature.xml.
That should be adjusted.

alshamams · 2023-10-11T06:15:25Z

Hi @HannesWell ,
I have addressed your latest review comment and squashed the commits. Kindly have a look and let me know.

vogella · 2023-10-11T19:39:50Z

@HannesWell have your concerns be adressed?

HannesWell · 2023-10-11T19:57:28Z

Hi @HannesWell , I have addressed your latest review comment and squashed the commits. Kindly have a look and let me know.

Thanks for the update @alshamams! Your change looks good now. 👍🏽
I also checked the code-base of P2 for references to the attributes about to be removed and found references to unpack

But while checking the P2 code-base I found some references to the attributes about to be removed, i.e. the unpack attribute, where I'm not yet entirely sure if it is absolutely not used. I already checked with Tycho that it has no effect, but I have to figure out if the same applies for all use cases in P2. I'm working on it but would like to have confidence about it before submitting this.
Thus I would like to keep this open probably for a few more days, but you can probably consider this work as done.

HannesWell · 2023-10-15T19:02:06Z

A quick update on this one.
The next Tycho release will handle feature.xml without the attributes to be removed properly (i.e. does not add the inferred sizes).
For Tycho 5 there is no full aggreement yet how to handle those attributes, but since its release is further in the future that's not a concern for this one.

What's currently blocking the submission of this one is that CoreUtility.guessUnpack() is currently used in P2 and we need to remove its usage before we can remove it here. Unfortunately the usage is quite convoluted and I didn't went 100% through it yet.
I'll be at EclipseCon from tomorrow on and will therefore not be able to continue the work on the P2 site until the end of the coming week. If any body of you attends as well, I'll be glad to have a chat about this. :)

vogella · 2023-11-01T16:18:27Z

Is there an issue to follow the work of CoreUtility.guessUnpack()?

Maybe remove the UI elements as a first step?

This commit removes some of the unused attributes of plugin element, which are redundant and are never read from a feature.xml file: install-size, fragment, download size and unpack attributes.

HannesWell

Is there an issue to follow the work of CoreUtility.guessUnpack()?

I just created eclipse-equinox/p2#368 to some related work on P2. But it looks like PDE-build again uses some parts of that again.
However the good news is that I confused CoreUtility.guessUnpack() with another Utility class in P2 and it is in fact not used and this change is ready for submission now.

Thank you @alshamams for your work on this issue.

alshamams · 2023-11-02T08:56:03Z

Is there an issue to follow the work of CoreUtility.guessUnpack()?

I just created eclipse-equinox/p2#368 to some related work on P2. But it looks like PDE-build again uses some parts of that again. However the good news is that I confused CoreUtility.guessUnpack() with another Utility class in P2 and it is in fact not used and this change is ready for submission now.

Thank you @alshamams for your work on this issue.

Thanks @HannesWell !

vogella · 2023-11-02T09:06:09Z

Thanks @alshamams and @HannesWell , always great if we get rid of outdated stuff.

JDT moved in eclipse-jdt/eclipse.jdt.ui#810, JDT moved classes from o.e.jdt.ui to o.e.jdt.core.manipulation PDE removed unused attributes of feature.xml in eclipse-pde/eclipse.pde#770 Fixes eclipse-m2e#1591

JDT moved in eclipse-jdt/eclipse.jdt.ui#810, JDT moved classes from o.e.jdt.ui to o.e.jdt.core.manipulation PDE removed unused attributes of feature.xml in eclipse-pde/eclipse.pde#770 Fixes #1591

Entries for - eclipse-pde/eclipse.pde#730 - eclipse-pde/eclipse.pde#770 - eclipse-equinox/p2#378 - eclipse-pde/eclipse.pde#882

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

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

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

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

gireeshpunathil reviewed Sep 28, 2023

View reviewed changes

...clipse.pde.ui.tests/src/org/eclipse/pde/core/tests/internal/feature/FeatureDataTestCase.java Outdated Show resolved Hide resolved

...clipse.pde.ui.tests/src/org/eclipse/pde/core/tests/internal/feature/FeatureDataTestCase.java Outdated Show resolved Hide resolved

HannesWell force-pushed the require_bundle_attr_errorfix branch from 9eb4d51 to 7cd3d43 Compare October 4, 2023 22:34

HannesWell reviewed Oct 4, 2023

View reviewed changes

alshamams force-pushed the require_bundle_attr_errorfix branch from ccac62d to a496ac2 Compare October 9, 2023 06:17

HannesWell mentioned this pull request Oct 14, 2023

Remove support for unused attributes in feature.xml eclipse-tycho/tycho#2916

Merged

Remove unnecessary attributes of plugin element in feature.xml

67a7a83

This commit removes some of the unused attributes of plugin element, which are redundant and are never read from a feature.xml file: install-size, fragment, download size and unpack attributes.

HannesWell force-pushed the require_bundle_attr_errorfix branch from a496ac2 to 67a7a83 Compare November 1, 2023 20:03

HannesWell approved these changes Nov 1, 2023

View reviewed changes

HannesWell merged commit 824f124 into eclipse-pde:master Nov 1, 2023
16 checks passed

HannesWell mentioned this pull request Nov 7, 2023

Adapt to internal changes in JDT and PDE for Eclipe SimRel 2023-12 eclipse-m2e/m2e-core#1595

Merged

HannesWell mentioned this pull request Nov 11, 2023

Add N&N about removal of unnecessary attributes in Features and Products eclipse-platform/www.eclipse.org-eclipse#84

Merged

HannesWell added the noteworthy Noteworthy feature label Nov 11, 2023

HannesWell mentioned this pull request Nov 13, 2023

FeatureErrorReporter.validatePluginExists should recognized fragments #916

Merged

HannesWell mentioned this pull request Dec 8, 2023

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

Closed

HannesWell mentioned this pull request May 15, 2024

[PDE-Build] Copy Eclipse-BundleShape and other headers in wrapped states #1271

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Remove unused attributes in auto-generated feature.xml #770

Remove unused attributes in auto-generated feature.xml #770

alshamams commented Sep 27, 2023

github-actions bot commented Sep 27, 2023 •

edited

Loading

alshamams commented Sep 27, 2023

alshamams commented Sep 27, 2023

HannesWell commented Sep 27, 2023

HannesWell commented Sep 28, 2023

HannesWell left a comment

HannesWell Oct 4, 2023

szarnekow commented Oct 5, 2023

HannesWell commented Oct 5, 2023

HannesWell commented Oct 5, 2023

alshamams commented Oct 11, 2023

vogella commented Oct 11, 2023

HannesWell commented Oct 11, 2023

HannesWell commented Oct 15, 2023

vogella commented Nov 1, 2023

HannesWell left a comment

alshamams commented Nov 2, 2023

vogella commented Nov 2, 2023

Remove unused attributes in auto-generated feature.xml #770

Remove unused attributes in auto-generated feature.xml #770

Conversation

alshamams commented Sep 27, 2023

github-actions bot commented Sep 27, 2023 • edited Loading

Test Results

alshamams commented Sep 27, 2023

alshamams commented Sep 27, 2023

HannesWell commented Sep 27, 2023

HannesWell commented Sep 28, 2023

HannesWell left a comment

Choose a reason for hiding this comment

HannesWell Oct 4, 2023

Choose a reason for hiding this comment

szarnekow commented Oct 5, 2023

HannesWell commented Oct 5, 2023

HannesWell commented Oct 5, 2023

alshamams commented Oct 11, 2023

vogella commented Oct 11, 2023

HannesWell commented Oct 11, 2023

HannesWell commented Oct 15, 2023

vogella commented Nov 1, 2023

HannesWell left a comment

Choose a reason for hiding this comment

alshamams commented Nov 2, 2023

vogella commented Nov 2, 2023

github-actions bot commented Sep 27, 2023 •

edited

Loading