empty maven console in 2021-06

[Bananeweizen]

All the IDEs that I have upgraded to 2021-06M1 don't show normal output in the maven console. They only show the error messages for wrong logger bindings, and that's it (but the maven process runs to the end, as seen in task manager). Running the same launch config from 2021-03 IDEs is fine. Also other consoles in 2021-06M1 are fine, just the Maven console seems broken.

I've already uninstalled the optional feature org.eclipse.m2e.logback.feature.feature.group, but that didn't fix anything.

[HannesWell]

From the print-out's I think the problem could be that Eclipse 2021-06 includes the slf4j.api plugin with version 2.0.0.alpha1. This is at least the case for my Eclipse-for-commiters:

What I've read so far, slf4j does not like it when bindings and API with version 2.0.0 and prior are mixed together.

In my Eclipse 2021-03 (based on Modelling-tools) the first and third entry are not present.
I didn't find out yet which feature pulls in slf4j-2.0.0.

Also the question is how to solve the problem: Either somehow remove the slf4j-2 plug-in, upgrade m2e to slf4j-2 or make them work together? I'm not yet very familiar with slf4j but if nobody else can jump in and knows a solution I can search for one.

[sravanlakkimsetti]

From the print-out's I think the problem could be that Eclipse 2021-06 includes the slf4j.api plugin with version 2.0.0.alpha1. This is at least the case for my Eclipse-for-commiters:

What I've read so far, slf4j does not like it when bindings and API with version 2.0.0 and prior are mixed together.

In my Eclipse 2021-03 (based on Modelling-tools) the first and third entry are not present.
I didn't find out yet which feature pulls in slf4j-2.0.0.

Also the question is how to solve the problem: Either somehow remove the slf4j-2 plug-in, upgrade m2e to slf4j-2 or make them work together? I'm not yet very familiar with slf4j but if nobody else can jump in and knows a solution I can search for one.

slf4j v2 is coming in from jetty 10.0.2

[guw]

It's the Eclipse project pulling it in.
https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse.platform.releng.prereqs.sdk/eclipse-sdk-prereqs.target

[HannesWell]

From all I know about slf4j, multiple bindings are not supported respectively all bindings except the chosen one are ignored (http://www.slf4j.org/codes.html#multiple_bindings). The case here is especially problematic, because with version 1.8 the binding mechanism changed: http://www.slf4j.org/faq.html#changesInVersion18
See also http://www.slf4j.org/codes.html#ignoredBindings

So from that I conclude the two options are to either avoid pulling in slf4j.api version 2.0 or to upgrade all usages of slf4j's api to use version 2.0. But the latter would probably affect many Eclipse plug-ins and should therefore be done in a more coordinated and long-term planned fashion.

[sravanlakkimsetti]

In platform we have upgraded Jetty to version 10. Jetty version 10 has a dependency for slf4j.api version 2.0.0. This where slf4j.api version 2 is coming from. to stop pulling slf4j.api version 2 we have to drop jetty update. I don't think that would be the way forward.

[HannesWell]

Agree. I can try to update m2e and the embedded maven runtime to use slf4j 2.0.0-alpha1.

[mickaelistria]

Maven itself uses slf4j 1.7; this is not something we can easily change and I'd rather relying on alpha versions for m2e. Jetty can rely on it if they want to, but we should probably avoid it here.
Another approach, that I am investigating, is restricting the range to ensure we stick to slf4j 1.7 in m2e, and have 1.7 and 2.0 coexisting.

[mickaelistria]

#213 Should fix that.

[HannesWell]

Thanks Mickael for taking care of it!

Maven itself uses slf4j 1.7; this is not something we can easily change and I'd rather relying on alpha versions for m2e. Jetty can rely on it if they want to, but we should probably avoid it here.
Another approach, that I am investigating, is restricting the range to ensure we stick to slf4j 1.7 in m2e, and have 1.7 and 2.0 coexisting.

I was afraid that problem of that kind you mentioned would arise.

Actually I thought that it would not be possible to mix multiple versions of slf4j bindings/API (especially before and after 1.8), because slf4j states that only one binding from the classpath is considered and it has to be compatible to the API. But I forgot that each bundle comes with its own ClassLoader and therefore has its own classpath.

EDIT: The following paragraph sounds worse than it actually is. It actually works. See my my next answers.
However unfortunately the solution does not work for me, when I tested it with the Eclipse Application configuration of m2e. The print-out is still gone with Eclipse 2021-06 and I still get the following error message on the console:

SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#noProviders for further details.
SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions prior to 1.8.
SLF4J: Ignoring binding found at [jar:file:/C:/dev/workspaces/eclipse.m2e/.metadata/.plugins/org.eclipse.pde.core/.bundle_pool/plugins/org.eclipse.m2e.maven.runtime.slf4j.simple_1.16.0.20200610-1735/jars/slf4j-simple-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#ignoredBindings for an explanation.

But before this happens the https://download.eclipse.org/eclipse/updates location of the dev-workspace.target has to be updated to the 4.20-I-build just like the target-platform.target. They went out of sync with your latest change.
With the old dev-workspace.target the print out is there just as expected, but then there is no slf4j-2.0.0 api plugin in the debugged Eclipse.

[HannesWell]

When installing the latest m2e snapshots that include the mentioned commits in my Eclipse-for committers latest (not released) Version: 2021-06 M2 (4.20.0 M2) and Build id: 20210506-1248 it works perfectly fine.

I'm a bit puzzled about this discrepancy.

Nevertheless I still get a error message about mutliple slf4j bindings:

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/C:/Users/Hannes/.p2/pool/plugins/org.eclipse.m2e.maven.runtime.slf4j.simple_1.18.0.20210402-1458/jars/slf4j-simple-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [file:/C:/dev/Eclipse-committers-latest/eclipse/configuration/org.eclipse.osgi/745/0/.cp/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.SimpleLoggerFactory]
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/C:/Users/Hannes/.p2/pool/plugins/org.eclipse.m2e.maven.runtime.slf4j.simple_1.18.0.20210402-1458/jars/slf4j-simple-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [file:/C:/dev/Eclipse-committers-latest/eclipse/configuration/org.eclipse.osgi/745/0/.cp/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.SimpleLoggerFactory]

[HannesWell]

The reason why Mickael's solution did not work for an Eclipse-Application launched from the m2e-dev workspace was first that I did not run the maven-runtime installation after rebasing on the current master (my fault)
and second that the maven-runtime modules in the workspace and those installed in my local maven repository are not considered for the debugged Eclipse-Application. Instead the maven-runtime bundles from the target-platform are used, which are those from the latest release (that obviously don't contain the fix).

I worked around that issue locally at my computer by including the runtime bundles in the TP using a Maven-target (which should fetch them from my local maven repo) instead of m2e latest released p2 repo. And now it also works perfectly fine in the debugged Eclipse-Application.

I'm not yet certain if this is a general problem or I just miss-configured something. At least some part's of the maven-runtime module pom's show that it is intended that the runtime-modules should generate the required PDE meta-data and should be considered as Eclipse-plugins. But I will continue this in issue #214.

[HannesWell]

Thanks to @mickaelistria this issue was fixed with #213 and I think this can be closed.