I filed bug 1759179 against the maven module to stop filtering the glassfish-el package, which should allow the eclipse module to drop the glassfish-el package and fix the conflict.

I filed bug 1759187 against the eclipse module to stop shipping glassfish-el package, because we'll be able to consume it from the maven module instead.

Proposed as a Blocker for 31-final by Fedora user mbooth using the blocker tracking app because:

 The Eclipse IDE is not installable out of the box due to a conflict between modules and ursine package requirements. This will affect upgrades for users with Eclipse installed.

This issue was discussed during today's FESCo meeting (see https://pagure.io/fesco/issue/2236#comment-602778), and we voted to make it a FE.

Requested maven filter changes (bug #1759179) are implememented and available as updates in updates-testing-modular. However that doesn't fix the issue with Eclipse installability - neither eclipse-platform no glassfish-el are installable, see below.

The issue is that the old module version is still available from fedora-modular repo, even though updated module is available in updates-testing-modular (or updates-modular once the update is pushed to stable), and filter of the old module version seems to be in effect.

Contents of fedora-modular are frozen before GA and nothing can be altered in that repo. If maven filter was changed before GA (even during final freeze, as it had freeze exception) then it would be pushed to fedora-modular repo and would fix the issue. Post-GA update will land in updates-modular and won't fix the issue.

# dnf -q --enablerepo updates-testing --enablerepo updates-testing-modular module provides maven
maven-1:3.5.4-5.module_f28+3939+dc18cd75.noarch
Module   : maven:3.5:2820190416211833:819b5873:x86_64
Profiles : default
Repo     : fedora-modular
Summary  : Java project management and project comprehension tool

maven-1:3.5.4-5.module_f28+3939+dc18cd75.noarch
Module   : maven:3.5:2820190416211833:819b5873:x86_64
Profiles : default
Repo     : updates-modular
Summary  : Java project management and project comprehension tool

maven-1:3.5.4-5.module_f29+6921+ca3ed728.noarch
Module   : maven:3.5:2920191030094746:868ae023:x86_64
Profiles : default
Repo     : updates-testing-modular
Summary  : Java project management and project comprehension tool

# dnf -q --enablerepo updates-testing --enablerepo updates-testing-modular module info maven | grep Version
Version          : 2820190416211833
Version          : 2820190416211833
Version          : 2920191030094746
Version          : 2820190530101447
Version          : 2820190530101447
Version          : 2820190530101447

# dnf -q --enablerepo updates-testing --enablerepo updates-testing-modular install eclipse-platform
Error: 
 Problem: conflicting requests
  - package eclipse-platform-1:4.12-6.module_f31+6165+9b01e00c.x86_64 requires glassfish-el >= 3.0.1, but none of the providers can be installed
  - package glassfish-el-3.0.1-0.12.b08.module_f31+6519+12cd0b27.noarch is excluded
  - package glassfish-el-3.0.1-0.11.b08.fc31.noarch is excluded

# dnf -q --enablerepo updates-testing --enablerepo updates-testing-modular install glassfish-el
Error: Unable to find a match: glassfish-el

I'm seeing this problem, too.  I can't install eclipse-platform.

Error: 
 Problem: package eclipse-platform-1:4.11-3.fc31.x86_64 requires glassfish-el >= 3.0.1, but none of the providers can be installed
  - conflicting requests
  - package glassfish-el-3.0.1-0.12.b08.module_f31+6519+12cd0b27.noarch is excluded
  - package glassfish-el-3.0.1-0.11.b08.fc31.noarch is excluded
(try to add '--skip-broken' to skip uninstallable packages)

I removed all eclipse modules and after attempting to reinstall eclipse-platform, the installation fails still.

when will this be fixed? What is the point of releasing fedora if even eclipse can't be installed? Is the whole point of release  to damage fedora trust and brand?

lol, it means current fedora is 30

Any outlook on this? Can I install a F30 toolbox on a Fedora 31 release? Then, I can install eclipse-platform in the F30  toolbox.

I was able to create a Fedora 30 toolbox with the commands ...

1. First, install the toolbox program, if you haven't installed it already.

   sudo dnf install toolbox

2. Now, create a fedora 30 toolbox.

   toolbox create --image registry.fedoraproject.org/f30/fedora-toolbox:30

3. Then, I enter it.  If you only have one toolbox, you can enter simply ...

   toolbox enter

   Otherwise, you will have to be more specific, such as ...

   toolbox enter --release 30

4. Installed eclipse

   sudo dnf install eclipse-platform eclipse-cdt

5. Install any other eclipse components that you need, etc., if any.

Is this ever going to be fixed?

(In reply to Bruce Bigby from comment #12)
> Is this ever going to be fixed?

This is blocked by fedora infrastructure issues and policies regarding modularity. As these are not things we (eclipse maintainers) can influence we strongly suggest trying our flatpak https://flathub.org/apps/details/org.eclipse.Java . It should provide you with very similar experience.

Okay, I'll give the Flatpak a try.

The Flatpak appears to be just for Java.  I want CDT.  Now, I tried the first of the workarounds as a commenter described earlier, ...

----------------

There are two "workarounds":

1) Users must first enable the eclipse module to install the latest version of modular Eclipse:

[mbooth@fedora31 ~]$ sudo dnf module enable eclipse:latest

2) Users must first disable all conflicting java modules to install obsolete ursine version of Eclipse:

[mbooth@fedora31 ~]$ sudo dnf module disable eclipse maven

------------------

and eclipse installed okay, but when I open a project and attempt to open a new source file, eclipse hangs so I have to kill it, but when I reopen eclipse, the file that I attempted to open is open in an eclipse tab. Unfortunately, since the Fedora 31 eclipse is newer than the fedora 30 eclipse in my toolbox, now I can run the fedora 30 eclipse safely without compromising the integrity of my eclipse projects.  :-(

@Bruce Bigby: Did you consider / test to install Eclipse from the download as it is directly distributed by the Eclipse Foundation?

For Eclipse CDT I can recommend to download eclipse-cpp-2019-09-R-linux-gtk-x86_64.tar.gz and extract it to /opt/. That worked out-of-the-box for me.

(In reply to Bruce Bigby from comment #15)
> The Flatpak appears to be just for Java.  I want CDT.  Now, I tried the
> first of the workarounds as a commenter described earlier, ...
> 
> ----------------
> 
> There are two "workarounds":
> 
> 1) Users must first enable the eclipse module to install the latest version
> of modular Eclipse:
> 
> [mbooth@fedora31 ~]$ sudo dnf module enable eclipse:latest

This was all it needed for me.

But this was quite a major issue for Fedora release, I use eclipse cdt a lot and it's DOA for weeks.

> and eclipse installed okay, but when I open a project and attempt to open a
> new source file, eclipse hangs so I have to kill it, but when I reopen
> eclipse, the file that I attempted to open is open in an eclipse tab.
> Unfortunately, since the Fedora 31 eclipse is newer than the fedora 30
> eclipse in my toolbox, now I can run the fedora 30 eclipse safely without
> compromising the integrity of my eclipse projects.  :-(

Arcane lore: Eclipse has always needed to be started from the commandline with a magic "-clean" arg to not blow itself to hell on old workspace after updates.

I know that I can install Eclipse from the Eclipse Foundation and put it in /opt. I've done that in the distant past.  Luckily, I'm not desperate since this is a home desktop and I'm not doing real work on it so I can wait for a fix, but if I get tired of waiting, I'll install Eclipse via the Foundation, or I'll consider porting my hobby project to Code Blocks.  It's great that we have choices.

Oh, by the way, I ran "eclipse -clean", and the hang still occurs. Puzzled.  Not sure how to debug this java process.

I attached to the Java thread that was using 100% CPU and this is the backtrace:

-----------------------------------------------------------------------------------

(gdb) where
#0  0x00007f7becb4ba0d in cairo_matrix_transform_point () at /lib64/libcairo.so.2
#1  0x00007f7becb3c91d in _do_cairo_gstate_user_to_backend () at /lib64/libcairo.so.2
#2  0x00007f7becb36e6d in _cairo_default_context_line_to () at /lib64/libcairo.so.2
#3  0x00007f7becb92a59 in cairo_line_to () at /lib64/libcairo.so.2
#4  0x00007f7bf407d52e in draw_error_underline () at /lib64/libpangocairo-1.0.so.0
#5  0x00007f7bf407d668 in pango_cairo_renderer_draw_error_underline () at /lib64/libpangocairo-1.0.so.0
#6  0x00007f7bf405584b in pango_renderer_draw_layout_line () at /lib64/libpango-1.0.so.0
#7  0x00007f7bf4055d54 in pango_renderer_draw_layout () at /lib64/libpango-1.0.so.0
#8  0x00007f7bf407f228 in _pango_cairo_do_layout () at /lib64/libpangocairo-1.0.so.0
#9  0x00007f7bde43dcaf in Java_org_eclipse_swt_internal_gtk_OS__1pango_1cairo_1show_1layout ()
    at /usr/lib/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_64_3.112.0.v20190908-0312/libswt-pi3-gtk-4928r15.so
#10 0x00007f7bf6dd85f6 in  ()
#11 0x0000000000000007 in  ()
#12 0x00000000ec830810 in  ()
#13 0x00000067ec830b40 in  ()
#14 0x00000000ec82d620 in  ()
#15 0x00000000c077c8a0 in  ()
#16 0x00007f7bf708ceec in  ()
#17 0x00000000c077d7f8 in  ()
#18 0x00007f7bf709ee68 in  ()
#19 0x00000001001f53c0 in  ()
#20 0x00007f7bf7084418 in  ()
#21 0x0000004400000002 in  ()
#22 0x00007f7c048c7b50 in  ()
#23 0x00000000ebbeea50 in  ()
#24 0x00000000ec82d620 in  ()
#25 0x00000001001f53c0 in  ()
#26 0x00000000ebbeea50 in  ()
#27 0x0000000000000007 in  ()
#28 0x00000000fa618a58 in  ()
#29 0x0000000000000001 in  ()
#30 0x0000000000000011 in  ()
#31 0x0000000000000009 in  ()
#32 0x00007f7b00000000 in (anonymous namespace)::AtomicExpand::tryExpandAtomicRMW(llvm::AtomicRMWInst*) () at /lib64/libLLVM-9.so
#33 0x00007f7c05f31840 in  ()

---------------------------------------------------------------------------------------------------------------------------------

Maybe this will help. Don't know.

Never mind.  Sadly, the pango lines in the back-trace reminded me that pango appears to have a problem with the "Comic Mono" font, which I downloaded from site,

https://dtinth.github.io/comic-mono-font/

and love absolutely!  Sadly, I can't use it for Eclipse or Gnome Builder.  I filed a bug report against pango, but I have no idea whether the problem is indeed with pango or the font itself.

Fortunately, Comic Mono works as my main Gnome Shell mono font. I've had NO issues.  I've used "Comic Mono" in VSCode, too, but some applications seem to have a problem with it via pango.

To fix my Eclipse hang problem, I edited the file,

.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.ui.workbench.prefs

and replaced all occurrences of "Comic Mono" with a different font name.  Now, Eclipse is fine.  I really wish that I could use "Comic Mono", because it really is a nice easy-to-read pleasant playful font to use.  Oh well.  Bummer. :-(

By the way, the font, "Comic Sans MS Regular", works fine, but it is a proportional font. I prefer a monospace font for programming. Comic Mono would be perfect, if it weren't for its fatal interaction with pango.

Yay! I found a mono-space font, called "Comic Relief", that is just as good as the "Comic Mono" font that I had been using.  If you're interested, see the URL,

https://www.fontsquirrel.com/fonts/comic-relief?q%5Bterm%5D=comic&q%5Bsearch_check%5D=Y


The main site URL is ...

https://www.fontsquirrel.com/

Actually, "Comic Relief" doesn't appear to be a monospace font.  I'll keep looking.  Sorry for cluttering up this bug report.

I believe we've managed to resolve all the necessary issues with FESCo, Releng and Modularity teams.

It should now be possible to install Eclipse from the Fedora repositories in the normal way:

$ sudo dnf install eclipse
$ # ... OR ...
$ sudo dnf groupinstall eclipse
$ # ... OR ...
$ sudo dnf module install eclipse


Don't forget if you explicitly disabled any modules, you will first need to reset them before installing Eclipse, e.g.:

$ sudo dnf module reset eclipse ant maven

Sorry for the inconvenience.

Today I cannot install eclipse.

I upgraded from Fedora 30 with eclipse 2019-03 installed a few weeks ago. Today I tried to launch it the for the 1st time after I upgrade to Fedora 31 but eclipse crashed during start up.
I removed eclipse via dnf and did 

$ sudo dnf module reset eclipse ant maven

thereafter I tried to install eclipse via dnf

$ sudo dnf install eclipse
Last metadata expiration check: 0:00:16 ago on Di 14 Jan 2020 18:28:53 CET.
Error: 
 Problem: package eclipse-jdt-1:4.11-3.fc31.noarch requires eclipse-platform = 1:4.11-3.fc31, but none of the providers can be installed
  - package eclipse-platform-1:4.11-3.fc31.x86_64 requires glassfish-el >= 3.0.1, but none of the providers can be installed
  - conflicting requests
  - package glassfish-el-3.0.1-0.12.b08.module_f31+6519+12cd0b27.noarch is filtered out by modular filtering
  - package glassfish-el-3.0.1-0.12.b08.module_f31+6793+1c93c38e.noarch is filtered out by modular filtering
  - package glassfish-el-3.0.1-0.11.b08.fc31.noarch is filtered out by modular filtering
(try to add '--skip-broken' to skip uninstallable packages)

I did an dnf upgrade beforehand as well.

Please help

I am seeing the same as above. I upgraded from F30, but first had to uninstall eclipse to get the upgrade to work. Now, with F31 upgraded, I see the same message as Comment #26. I also performed the module reset mentioned above, but to no avail.

This is still broken, unfortunately.

If I enable the eclipse module first, then install eclipse, it works fine:

sudo dnf module enable eclipse:latest
sudo dnf install eclipse

In the event a user does not enable the module, is it possible to give a useful error message rather than a misleading one about unmet dependencies? Perhaps a hint?

I stumbled over this issue as well. On a fresh F31 installation, "sudo dnf install eclipse" does not work (output similar to comment #26). The workaround described in comment #28 helps.

I would still consider this a bug, since the well-known standard operation to install a package fails. The 1st described method of comment #25 is not working. Please re-open the bug report.

$ sudo podman run -ti fedora:31 /usr/bin/bash
# dnf upgrade
...
# dnf install eclipse
Last metadata expiration check: 0:02:04 ago on Wed Apr  8 14:11:26 2020.
Error: 
 Problem: conflicting requests
  - package eclipse-jdt-1:4.14-5.fc31.noarch requires eclipse-platform = 1:4.14-5.fc31, but none of the providers can be installed
  - package eclipse-jdt-1:4.11-3.fc31.noarch requires eclipse-platform = 1:4.11-3.fc31, but none of the providers can be installed
  - package eclipse-platform-1:4.14-5.fc31.x86_64 requires glassfish-el >= 3.0.1, but none of the providers can be installed
  - package eclipse-platform-1:4.11-3.fc31.x86_64 requires glassfish-el >= 3.0.1, but none of the providers can be installed

  - package glassfish-el-3.0.1-0.12.b08.module_f31+6519+12cd0b27.noarch is filtered out by modular filtering <========
  - package glassfish-el-3.0.1-0.12.b08.module_f31+6793+1c93c38e.noarch is filtered out by modular filtering <========

  - package glassfish-el-3.0.1-0.11.b08.fc31.noarch is filtered out by modular filtering
(try to add '--skip-broken' to skip uninstallable packages)

Yep, seems to be still broken.

*** Bug 1806086 has been marked as a duplicate of this bug. ***

Here is a potential work-around which worked for me:

Disable fedora-module (and updates-modular) entirely. Either by editing the according files in /etc/yum.repos.d/ or by disabling them on the command line.

Without having anything from the modular repositories installed, the following command line should install the non-modular eclipse version:

dnf --disablerepo fedora-modular --disablerepo updates-modular install eclipse

I am not sure if this is the same issue, but after a fresh installation of Fedora Workstation 32 (from Live CD) a group install of "Fedora Eclipse" fails in the following way:
# dnf update --refresh
# dnf group install "Fedora Eclipse"

No match for group package "eclipse-linuxtools-gprof"
No match for group package "eclipse-pydev-mylyn"
No match for group package "eclipse-dltk-mylyn"
No match for group package "eclipse-linuxtools-vagrant"
No match for group package "eclipse-linuxtools-gcov"
No match for group package "eclipse-cdt-docker"
No match for group package "eclipse-packagekit"
No match for group package "eclipse-linuxtools-systemtap"
No match for group package "eclipse-linuxtools-javadocs"
No match for group package "eclipse-linuxtools-libhover"
No match for group package "eclipse-usage"
No match for group package "eclipse-linuxtools-valgrind"
No match for group package "eclipse-dltk-sh"
No match for group package "eclipse-linuxtools-docker"
No match for group package "eclipse-cdt"
No match for group package "eclipse-egit-mylyn"
No match for group package "eclipse-linuxtools-changelog"
No match for group package "eclipse-linuxtools-perf"
No match for group package "eclipse-linuxtools-rpm-editor"
Error: 
 Problem: package eclipse-mylyn-context-cdt-3.25.0-0.6.fc31.noarch requires osgi(org.eclipse.cdt.core), but none of the providers can be installed
  - conflicting requests
  - package eclipse-cdt-native-2:9.8.0-1.module_f32+6163+c0e6dcb2.x86_64 is filtered out by modular filtering
  - package eclipse-cdt-native-2:9.9.0-1.module_f32+6792+7663b3b5.x86_64 is filtered out by modular filtering
  - package eclipse-cdt-native-2:9.11.0-5.module_f32+8422+d2b9781b.x86_64 is filtered out by modular filtering
(try to add '--skip-broken' to skip uninstallable packages)

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This problem was fixed in Fedora 32