Nominated and accepted as a Prioritized Bug https://meetbot.fedoraproject.org/fedora-meeting/2020-02-12/fedora_prioritized_bugs_and_issues.2020-02-12-16.00.log.html#l-132

I investigated the issue and I found that glassfish-el package was filtered out by maven:3.5:2820190416211833:819b5873:x86_64 module. Maven modules provides glassfish-el.src and glassfish-el-api.noarch and because maven:3.5 is a default module glassfish-el is filtered out.

The problem could be resolved by update of maven:3.5. They should use glassfish-el from base repo or pack glassfish-el as a compact package.

The problem could also be resolved by not having default modular streams.

Also note that the bug is now assigned to Orphan Owner :(

(In reply to Miro Hrončok from comment #4)
> The problem could also be resolved by not having default modular streams.

I would like to open a discussion what is allowed in modules. I believe that module cannot break other components. Modules are not containers but an alternative content. It means that after switching into module (doesn't matter if it is default or not), it must not create additional broken dependencies. Modules must be considered as additional repositories shipped with Fedora. Modules with a default stream are like Fedora repository and without defaults like fedora-cisco-openh264. Genera expectation from fedora-cisco-openh264 is that after repo is enable everything works like before plus there will be an additional content.

I would like to highlight that not using defaults is not a solution of the problem. It only makes problem less visible.

None of the affected packages are are part of maven module. They are either ursine or come from eclipse module (module builds #6793 and #6519 are eclipse:latest builds). Moving the bug to eclipse.

Further note: maven:3.5 available from Fedora 31 updates no longer filters out glassfish-el. maven:3.5 in base Fedora 31 (GA) does indeed filter glassfish-el, but that module can't be altered post GA.

Let me summarize the issue. Module maven:3.5 in fedora-modular repository makes eclipse uninstalable (tested on Fedora 31).

See output:
sudo dnf install --repo=fedora,fedora-modular eclipse
Last metadata expiration check: 0:01:07 ago on Wed 19 Feb 2020 01:20:58 PM 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 excluded
  - package glassfish-el-3.0.1-0.11.b08.fc31.noarch is excluded
(try to add '--skip-broken' to skip uninstallable packages)


The issue was resolved by dropping glassfish-el but not when fedora-modular is available.
See: 
sudo dnf install --repo=fedora,updates-modular eclipse
sudo dnf install --repo=fedora,updates-modular,fedora-modular eclipse

The issue is same like with incorrect obsoletes in rpm in Fedora repo. You cannot resolve the issue by dropping that problematic obsoletes in next release and when someone point that it doesn't work just to move the issue to package that was obsoleted.

Now we have to try once again from beginning. The issue is there and it is caused by maven:3.5. Prove it is quite easy. 
sudo dnf install eclipse  # transaction fail
sudo dnf module disable maven:3.5
sudo dnf install eclipse  # no issue

How to resolve the issue?
In maven:module provide all missing requirements to eclipse or find a better way. I strongly to recommend to fix not only 3.5 stream.
Convince eclipse people to not require glassfish-el or glassfish-el-api. It must be done by very nice way, because as I said it is not their problem.

I'd argue that the issue is not in maven module. But even assuming it is, there is nothing that can be fixed in maven module - module versions in GA repository cannot be altered.

(In reply to Jaroslav Mracek from comment #9)
> How to resolve the issue?
> In maven:module provide all missing requirements to eclipse or find a better
> way.

Providing dependencies for Eclipse is beyond scope of maven module. The purpose of maven module is to provide Maven. I'm not going to add packages unrelated to Maven to maven module.

(In reply to Mikolaj Izdebski from comment #10)
> I'd argue that the issue is not in maven module. But even assuming it is,
> there is nothing that can be fixed in maven module - module versions in GA
> repository cannot be altered.
> 
> (In reply to Jaroslav Mracek from comment #9)
> > How to resolve the issue?
> > In maven:module provide all missing requirements to eclipse or find a better
> > way.
> 
> Providing dependencies for Eclipse is beyond scope of maven module. The
> purpose of maven module is to provide Maven. I'm not going to add packages
> unrelated to Maven to maven module.

A can also argue that maven in GA provided glassfish-el-api and glassfish-el.src but not glassfish-el.noarch. In case that you will provide also glassfish-el.noarch it would resolve the issue. I would recommend to cooperate with maintainers of glassfish-el to synchronize steps. Please also inform maintainers of eclipse about the progress.

I am sorry that I tried to suggest a solution for the issue and it is completely up to you how you will resolve it. I hope that you will provide an alternative solution in reasonable time.

> Providing dependencies for Eclipse is beyond scope of maven module. The purpose of maven module is to provide Maven. I'm not going to add packages unrelated to Maven to maven module.

Per https://pagure.io/modularity/issue/146, all packages must be exposed via the API of a default module stream; none can be filtered.

glassfish-el is part of the maven module's default stream, and thus cannot be filtered out. The same holds for all the other packages in the filtered: section of the maven module's default streams.

Reassigning to sgallagh to step in with a fix as a provenpackager as agreed in last week's PrioritizedBugs meeting:
https://meetbot.fedoraproject.org/teams/fedora_prioritized_bugs_and_issues/fedora_prioritized_bugs_and_issues.2020-03-11-15.00.log.html#l-156

This fell off my radar. Can someone remind me what we agreed on here?

(In reply to Alex Scheel from comment #12)
> > Providing dependencies for Eclipse is beyond scope of maven module. The purpose of maven module is to provide Maven. I'm not going to add packages unrelated to Maven to maven module.
> 
> Per https://pagure.io/modularity/issue/146, all packages must be exposed via
> the API of a default module stream; none can be filtered.
> 
> glassfish-el is part of the maven module's default stream, and thus cannot
> be filtered out. The same holds for all the other packages in the filtered:
> section of the maven module's default streams.

This, basically. Do not filter out glassfish-el.

FEDORA-MODULAR-2020-885927b4dc has been submitted as an update to Fedora 30 Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-885927b4dc

Because of how this module is built, there is only one update marked as "Fedora 30 Modular". This will go to stable for both F30 and F31 at the same time, so if you want to provide karma, please do so on https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-885927b4dc

FEDORA-MODULAR-2020-885927b4dc has been pushed to the Fedora 30 Modular testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-885927b4dc

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

[root@7a52f0f7a161 /]# dnf --enablerepo=updates-testing{,-modular} install eclipse
Fedora Modular 31 - x86_64 - Test Updates                171 kB/s | 1.1 MB     00:06    
Fedora 31 - x86_64 - Test Updates                        794 kB/s | 7.1 MB     00:09    
Last metadata expiration check: 0:00:06 ago on Thu Apr  9 22:07:44 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.13.b08.module_f31+8483+4971e288.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 know no way of saying whether the update has hit the mirrors yet, so I'll retest in couple days.

Works now, will add karma.

FEDORA-MODULAR-2020-885927b4dc has been pushed to the Fedora 30 Modular stable repository.
If problem still persists, please make note of it in this bug report.