Bug 1937950

Summary: Eclipse Plugin Development Environment is not correct, org.eclipse.ui unresolved
Product: [Fedora] Fedora Reporter: Phil Wiggum <p1mail2015>
Component: eclipseAssignee: Mat Booth <mat.booth>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 34CC: akurtako, andjrobins, dbhole, ebaron, eclipse-sig, jerboaa, jjohnstn, lef, mat.booth, rgrunber
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-04-23 11:29:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Phil Wiggum 2021-03-11 19:08:30 UTC
How reproducible:
    Always.    
    
Steps to Reproduce:
    Install Fedora 34 beta https://dl.fedoraproject.org/pub/alt/stage/34_Beta-1.1/Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-34_Beta-1.1.iso
    Or use Fedora 33.
    
    1. Start Eclipse
    2. Open a new empty Workspace.
    3. Create a project: Plug-in Development/Plug-in Project, Next, <Test_name>, Next, Next
    4. Create a plug-in using a template: Hello, World Command, Finish.
    5. Open Perspective.

Actual results:
    In MANIFEST.MF/Dependencies 'org.eclipse.ui' unresolved (red x)

    Errors (17 items)
    Description Resource Path Location Type
    AbstractHandler cannot be resolved to a type SampleHandler.java /Test/src/test/handlers line 10 Java Problem
    Bundle 'org.eclipse.ui' cannot be resolved MANIFEST.MF /Test/META-INF line 6 Plug-in Problem
    ExecutionEvent cannot be resolved to a type SampleHandler.java /Test/src/test/handlers line 13 Java Problem
    ExecutionException cannot be resolved to a type SampleHandler.java /Test/src/test/handlers line 13 Java Problem
    HandlerUtil cannot be resolved SampleHandler.java /Test/src/test/handlers line 14 Java Problem
    IWorkbenchWindow cannot be resolved to a type SampleHandler.java /Test/src/test/handlers line 14 Java Problem
    MessageDialog cannot be resolved SampleHandler.java /Test/src/test/handlers line 15 Java Problem
    The import org.eclipse cannot be resolved SampleHandler.java /Test/src/test/handlers line 3 Java Problem
    The import org.eclipse cannot be resolved SampleHandler.java /Test/src/test/handlers line 4 Java Problem
    The import org.eclipse cannot be resolved SampleHandler.java /Test/src/test/handlers line 5 Java Problem
    The import org.eclipse cannot be resolved SampleHandler.java /Test/src/test/handlers line 6 Java Problem
    The import org.eclipse cannot be resolved SampleHandler.java /Test/src/test/handlers line 7 Java Problem
    The import org.eclipse cannot be resolved SampleHandler.java /Test/src/test/handlers line 8 Java Problem
    Unknown extension point: 'org.eclipse.ui.bindings' plugin.xml /Test line 25 Plug-in Problem
    Unknown extension point: 'org.eclipse.ui.commands' plugin.xml /Test line 6 Plug-in Problem
    Unknown extension point: 'org.eclipse.ui.handlers' plugin.xml /Test line 18 Plug-in Problem
    Unknown extension point: 'org.eclipse.ui.menus' plugin.xml /Test line 34 Plug-in Problem

Expected results:


Additional info:
    This works in my old F30 system.
    What differ between Eclipse 2020-12 (4.18 w. openjdk 11.0.10, F33) and Eclipse 2019-06 (4.12 w. openjdk 1.8.0, F30) is the number of plugins in the Target platform.
    Going into Windows/Preferences/Plug-in Development/Target Platform/Running Platform/Edit:
    I have 5501 plugins in my F30 system but only 574 in my new F33 system.
    And in tab Content: Bundle 'org.eclipse.ui' is missing in F33!

    This is working in following release downloaded from from 'eclipse.org'. 
    Version: 2020-12 (4.18.0) Build id: 20201210-1552.
    Install: ./eclipse-inst select 'Eclipse IDE for Eclipse Committe' (/usr/lib/jvm/jre-15-openjdk)
    
    F34:
    eclipse-platform-4.18-3.fc34.x86_64
    eclipse-pde-4.18-3.fc34.x86_64

    Noticeable here is that the version is more or less same between F34 (4.18.3) and Eclipse (4.18.0) so I guess it must be a packaging issue...

Comment 1 Phil Wiggum 2021-03-12 08:10:04 UTC
Installed with:
    dnf group install 'Fedora Eclipse'

Comment 2 Phil Wiggum 2021-03-13 13:30:31 UTC
Same error with:
    eclipse-pde-1:4.19-3.fc34.x86_64

Comment 3 Phil Wiggum 2021-03-15 10:27:53 UTC
After some testings I would like to change the caption of this bug to:

  'Eclipse Plugin Environment is not correct'

If I start a fresh Fedora Eclipse the 'Target Platform' has 574 plugins.
After installing a HelloWorld-plugin (build-ed by 2020-12 from Eclipse) I get 778 plugins.
Removing the HelloWorld-plugin I get 777 plugins.
So now with a little help from HelloWorld-plugin Eclipse has found a number of plugin belonging to the core of Eclipse.

No there reason why I would like to change the caption.
Another plug-in developed by 2020-12 from Eclipse is not working or recognized by Fedora-Eclipse at all.
One line in the MANIFEST.MF differ here from HelloWord:
  Import-Package: org.eclipse.cdt.ui

I can find that package in
  /usr/share/eclipse/droplets/cdt/plugins/org.eclipse.cdt.ui_6.7.1.202006250915.jar

My proposal is that if Eclipse is repacked in a different way as the original Eclipse the 'Target Platform' must match in all setups.

Some maybe useful stuff for who ever would like to dig in to this.
Monitoring what Eclipse is doing while the scanning take place during startup.
  strace -f eclipse 2>&1 | grep eclipse | grep -E 'open|stat' | grep -vE '\.png|\.bak|\.htm|\.gif|\.log|\.tmp' | grep -E '/usr/lib/eclipse/plugins"|dropins|/home/user'  
Also:
  https://wiki.eclipse.org/Equinox/p2/P2_Fragments

I lower this bug to 'Medium' because I'm switching over to the official Eclipse version instead.

Comment 4 Alexander Kurtakov 2021-04-23 11:29:43 UTC
PDE doesn't really support "roaming" target platforms and we have hit this issue multiple times including RPM and Flatpak distributions. Fixing this would requires significant work upstream to improve it.