Migrate to SLF4J-2 from Maven-Central #588

HannesWell · 2022-09-24T11:13:37Z

SLF4J 2 was released recently and I think it is a good opportunity to migrate from Orbit's SLF4J and Logback to recent versions from Maven-Central.

Although this does not affect Eclipse Platform TLPs directly because they don't use SLF4J I found this repo the most suitable one to create this umbrella issue. Mainly affected are the SimRel and EPP and potentially those projects that use slf4j for logging.

Migration of SLF4J users/clients

From a client/user perspective SLF4J 2.0 API is backwards compatible and is therefore a drop-in replacement:

https://www.slf4j.org/faq.html#compatibility
https://www.slf4j.org/faq.html#changesInVersion200
As long as the new fluent API is not used by clients they should work with both slf4j 1 and 2. The version a project is compiled against therefore specifies the minimum required version and the exclusive upper bound can be 3.

Adjustments for clients to migrate from SLF4J from Orbit to SLF4J from Maven-Central

The main difference for users between slf4j from Orbit and Maven-Central is the different Bundle-SymbolicName, at Orbit it is org.slf4j.api, while from Maven-Central it is named slf4j.api.

If projects follow OSGi best-practices and import the needed slf4j packages instead of requiring the bundle, no adjustments are necessary. If they require the bundle they should import the package instead (which makes them also usable with previous versions).
Fragments that use slf4j as their host can simply specify both names (which makes them usable with both versions):
Fragment-Host: org.slf4j.api,slf4j.api

Adjustments for clients to Migrate from SLF4J 1 to SLF4J 2.0:

We have two options here:

Modify the Import-Package of all clients to have a range [1.x, 3).
Affects many Eclipse projects and also all of our dependencies. All have to agree and update. -> Much work, but on the long run it has to happen anyways.
Ask SLF4J to export its packages with version 2 and a version below two (maybe the latest one).
This probably also requires Fix creation of generic-capabilities with multiple versions eclipse-equinox/p2#64.

I'm not sure which way is the better and safer one in terms of preventing accidental use of the new API without lifting the lower bound.

Migration of Logback

The migration of logback mainly affects those that assemble Eclipse applications, so SimRel and EPP (therefore adding @merks and @jonahgraham) but also external product builds.

Logback is for example used by M2E, but I don't know which project is contributing it to the Eclipse SimRel repo because M2E doesn't have it included in its p2 repo. @merks can you tell me who this is?

Logback itself is split into logback-classic and logback-core. But from Logging/SLF4J and application builder perspective only logback-classic is relevant and logback-core is just a dependency of it.

Migration from Logback 1.2 from Orbit to Maven-Central

The SLF4J and Logback-classic bundles from Maven are wired with each other by a package named org.slf4j.impl that slf4j.api imports and ch.qos.logback.classic exports. Other SLF4J bindings (probably) export that package as well.

Logback from Orbit uses a different approach to wire org.slf4j.api and ch.qos.logback.classic (both from Orbit) . Besides logback-core and classic it is split additionally into a third fragment ch.qos.logback.slf4j whose host is org.slf4j.api (from Orbit) and that contains and exports the org.slf4j.impl package of logback-classic and imports packages from the latter. This way effectively org.slf4j.api requires ch.qos.logback.classic.

Thus code that computes a dependency closure that includes slf4j maybe has to consider this. One example is M2E:
eclipse-m2e/m2e-core#931

Migration from Logback 1.2 to Logback 1.3 or 1.4

Since version 1.3 logback requires SLF4J 2.0. This is due to the fact that with version 2 slf4j changed the mechanism how slf4j is bound to a provider/binding.

To quote from https://www.slf4j.org/faq.html#changesInVersion200:

More visibly, slf4j-api now relies on the ServiceLoader mechanism to find its logging backend. SLF4J 1.7.x and earlier versions relied on the static binder mechanism which is no loger honored by slf4j-api version 2.0.x. More specifically, when initializing the LoggerFactory class will no longer search for the StaticLoggerBinder class on the class path.

Instead of "bindings" now org.slf4j.LoggerFactory searches for "providers". These ship for example with slf4j-nop-2.0.x.jar, slf4j-simple-2.0.x.jar or slf4j-jdk14-2.0.x.jar.

Therefore the package org.slf4j.impl is no longer imported by sl4j and not exported by logback-classic.
In order to make Java's Service Loader mechanism work within an OSGi environment like Equinox/Eclipse, the OSGi Service Loader Mediator Specification can be used.
The SLF4J 2 and logback-classic jars>=1.3 from Maven already contain a proper OSGi compliant Manifest with proper entries for the SL mediator.

We could use the Apache Aries SPI Fly implementation of the spec.
It would then be sufficient to include org.apache.aries.spifly.dynamic.bundle and to auto-start it in a product. Maybe it would then be useful to add that plugin to the defaults of auto-started bundles, which PDE's product editor offers.

The difference between Logback 1.3 and 1.4 is that the former uses javax, while the latter has migrated to JakartaEE:
https://logback.qos.ch/download.html
So if we want to migrate to JakartaEE that is probably to consider.

How to proceed

In general I think we should move to logback from Maven-Central. The question is if we should move to the last version of the 1.2 stream (which is not actively developed anymore, don't know if it will receives security updates?) or to 1.3/1.4 and consequently slf4j 2.

Moving directly to 1.3/1.4 and thus requiring slf4j 2.0 could be much more work, depending on the approach we can choose and I don't know if that is feasible within this release cycle. The Eclipse projects should be manageable but external dependencies could be problematic. But maybe this is also a good opportunity to ask for OSGi-fication of more deps.

Moving only to logback 1.2.11 from Maven-Central is definitly less work as a first step but has the risk to cause problems because the way how the slf4j bundle is wired to the logback-classic bundle is changed as described above. At least for M2E I already addressed them, but I don't know if there are other places.

So what do you others think is the best way to move on in this regard?

Associated changes

This section summarizes all changes associated to this issue and is adjusted as more changes are performed.

Migration of slf4j and logger bindings from Maven-Central

Changes to remove SLF4J from Eclipse Features

Changes to prepare bundles for SLF4J-2

Prepare for SLF4J 2.0 and require at least SLF4J 1.7 eclipse-m2e/m2e-core#941

The text was updated successfully, but these errors were encountered:

merks · 2022-09-24T12:15:22Z

Re: Which project is contributing org.slf4j.api to SimRel.

The following have requirements, with the displayed version range, on the IU or on the bundle directly (and will be affected a change to the bundle's ID):

The following have requirements on the provided packages, with the displayed version range:

As you can see, it's a very long list, many with restrictive ranges, some of them "3rd party" for which we might need to go "elsewhere" to ask for changes...

The IU itself is present in the following repositories.

That's also quite a long list of projects providing the IU that satisfies the above requirements.

HannesWell · 2022-09-24T12:31:33Z

Thank you Ed for the analysis, that is very good to know!
Can you also tell the repositories in which logback is present?

The features are indeed bad because they mandate a specific bundle name and a specific version (if they are included and not only referenced). This is problematic if a more recent version should be installed into a product, because then multiple slf4j versions are present. Luckily the Equinox/Felix resolver when then wire the bundles to the most recent version (hopefully).
I know we discussed this a few times in the past if features should include dependencies, but that is IMHO a reason that speaks against it.

merks · 2022-09-24T12:51:47Z

These are the dependencies on ch.quos.logback.*

Oddly it comes from here:

https://download.eclipse.org/efxclipse/runtime-released/3.7.0/site

But I don't efxclipse has an strict dependencies on those IUs, at least not from any IUs that it contributes to SimRel.

HannesWell · 2022-09-24T13:05:53Z

These are the dependencies on ch.quos.logback.*
...

Thank you. So it looks like M2E is the only active consumer, which makes at least that part simpler.

Oddly it comes from here:

https://download.eclipse.org/efxclipse/runtime-released/3.7.0/site

But I don't efxclipse has an strict dependencies on those IUs, at least not from any IUs that it contributes to SimRel.

Maybe that project stepped up because M2E required it but didn't provide it yet?
As part of eclipse-m2e/m2e-core#931 I also have the intention to change that and let m2e contribute logback and a more recent version of slf4j.
The updated slf4j version then probably also requires updates of the features that require it.

HannesWell · 2022-09-25T14:11:18Z

The following have requirements on the provided packages, with the displayed version range:

The list of package imports that would require changes is actually not that big as I expected it. Jetty already has a suitable version range for SLF4J 1 and 2 and some only define a lower bound and therefore don't need any change.

To me the question is, should we ask those projects to widen their version range or should we ask slf4j to export the packages with multiple versions? Like for example org.apache.felix:org.apache.felix.http.servlet-api:2.0.0, see also #239.

merks · 2022-09-25T15:20:24Z

Are the 3rd party ones in the list likely to expand their version range if asked? Would "bad things happen" if both versions are installed? I see no lower bounds of 2.0.0 so likely only the older one would get installed, given there are things constraining it to that version, unless the higher one is forced to be installed by a feature include such that both versions are installed...

HannesWell · 2022-09-26T07:35:43Z

Are the 3rd party ones in the list likely to expand their version range if asked?

We will probably only know until anyone asks them, at least I cannot judge this at all. Nevertheless since SLF4J 2 is a drop in replacement I don't see any reason that speaks against doing it.

Would "bad things happen" if both versions are installed? I see no lower bounds of 2.0.0 so likely only the older one would get installed, given there are things constraining it to that version, unless the higher one is forced to be installed by a feature include such that both versions are installed...

I think two versions of SLF4J should be avoided because it probably can cause unpredictable behavior. In general logger facades and implementations are always a bit special and picky and things are not getting simpler in OSGi.

Maybe @mickaelistria or @akurtakov can help in judging or have some advice.

akurtakov · 2022-09-26T07:50:31Z

I don't know of anything directly requiring slf4j or logback in Platform. So we get these as a dependency of a dependency (most likely jetty). With that said when the dependency moves Platform will have to move too.

mickaelistria · 2022-09-26T08:38:14Z

There is a org.eclipse.equinox.slf4j.stub which require slf4j in build, but what's fun is that it doesn't require slf4j.
The slf4j bundles are listed in the org.eclipse.equinox.core.sdk feature.xml. I'll look at replacing them with Maven ones.

HannesWell · 2022-09-27T08:28:33Z

I don't know of anything directly requiring slf4j or logback in Platform. So we get these as a dependency of a dependency (most likely jetty). With that said when the dependency moves Platform will have to move too.

That's right. I just choose this repo since it seemed to be the best one to open this umbrella issue. I don't know what is happening in Jetty but for M2E I'm about to migrate to SLF4J+Logback from maven-Central and plan to let M2E contribute that to SimRel. So it could be that M2E will be the driver here.

There is a org.eclipse.equinox.slf4j.stub which require slf4j in build, but what's fun is that it doesn't require slf4j. The slf4j bundles are listed in the org.eclipse.equinox.core.sdk feature.xml. I'll look at replacing them with Maven ones.

Thanks for the points. Maybe the stub is related to the slf4j from Orbit? Maybe it is not necessary when slf4j from Maven-Central is used. For context I found Bug 177851#c9, but the p2.inf mentioned there has already been removed in the meantime (you can find it in the git history of the project).

Regarding the inclusion of slf4j in features: In this case it seems to be more suitable to me to not include slf4j in features because otherwise the chances are high that multiple versions even with different metadata will end up in the SimRel repo and I suspect that this can cause chaos for those that have not fully understand how all these logging frameworks work in conjunction with OSGi.
Therefore I suggest to ask all the projects to just remove slf4j from there features. If you don't object I can create corresponding PRs/issues.

mickaelistria · 2022-09-27T13:18:26Z

Therefore I suggest to ask all the projects to just remove slf4j from there features.

OK. Would you have the opportunity to suggest such a PR for equinox?

HannesWell · 2022-09-27T17:33:42Z

Therefore I suggest to ask all the projects to just remove slf4j from there features.

OK. Would you have the opportunity to suggest such a PR for equinox?

Yes, I can do that.

If a Feature includes a Plugin, it usually includes it with a specific name and the version that was in the TP when the feature was build. This prevents consumers from using a slf4j bundle with different symbolic-name or different version in their TP or product. This is part of eclipse-platform/eclipse.platform.releng.aggregator#588

HannesWell · 2022-09-28T18:32:16Z

Therefore I suggest to ask all the projects to just remove slf4j from there features.

OK. Would you have the opportunity to suggest such a PR for equinox?

Created the following PRs to remove SLF4J from Eclipse Features:

Edit:
All required PRs/Gerrit-Changes to remove slf4j from features are now created and the list is maintained in the initial comment of this issue.

HannesWell · 2022-09-29T21:57:31Z

I just submitted eclipse-m2e/m2e-core#931 to migrate M2E to slf4j 1.7.36+logback 1.2.11 from Maven-Central and included both into M2E's p2 repo.
No I wonder if it is sufficient to add those artifacts into a P2 repo that contributes to SimRel or do those deps also have to be included in a feature in order to be supplied to the SimRel repo? One Fragment of M2E requires logback 1.2.0, which is higher than the version provided by Oomph, so it should at least fail to resolve without the version available in the M2E repo.

merks · 2022-09-30T05:56:48Z

The aggregator uses the planner to ensure that all dependencies are resolved using the same underlying mechanism that's used at install time. So it's sufficient that something requires it to be installed.

If you use the setup here to create a SimRel environment:

https://ci.eclipse.org/simrel/

You can open this simrel.aggr to try out your changes via a newer m2e repo. Change the repo here:

And then open the simrel.aggran:

This will logically do the aggregation, after turning to one of the secondary tabs, validating that aggregation works and presents the details about what's been aggregated.

If a Feature includes a Plugin, it usually includes it with a specific name and the version that was in the TP when the feature was build. This prevents consumers from using a slf4j bundle with different symbolic-name or different version in their TP or product. This is part of eclipse-platform/eclipse.platform.releng.aggregator#588

vogella · 2023-01-31T14:17:22Z

Thanks @HannesWell for the documenation, this helped me to move a client to Logback 1.3.5 and slf4j-api to 2.0.6.

Just for others to do the same:

Add the following to your target platform.

	<location includeDependencyDepth="infinite" includeDependencyScopes="compile" includeSource="true" label="logback libraries" missingManifest="generate" type="Maven">

			<feature id="maven.libraries" label="logback libraries" provider-name="Example" version="1.0.0.qualifier" />

			<!-- logback-classic and org.apache.aries.spifly.dynamic.bundle must also be activated so that their services
			     become active, this needs to be done via the product file on the configuration tab
			-->
			<dependencies>

				<dependency>
					<groupId>ch.qos.logback</groupId>
					<artifactId>logback-classic</artifactId>
					<version>1.3.5</version>
				</dependency>

				<!-- https://mvnrepository.com/artifact/org.slf4j/slf4j-api -->
				<dependency>
					<groupId>org.slf4j</groupId>
					<artifactId>slf4j-api</artifactId>
					<version>2.0.6</version>
				</dependency>

				<dependency>
					<groupId>org.apache.aries.spifly</groupId>
					<artifactId>org.apache.aries.spifly.dynamic.bundle</artifactId>
					<version>1.3.6</version>
				</dependency>

			
				<!-- -->
			</dependencies>
		</location>

and autostart the spifly and logback bundle in your product file.

 <plugin id="ch.qos.logback.classic" autoStart="true" startLevel="2" />
 <plugin id="org.apache.aries.spifly.dynamic.bundle" autoStart="true" startLevel="2" />

Since version 2.0.7 the slf4j.api bundle exports the user-api package 'org.slf4j' in version 2.x.y and 1.7.36. This allows to also use libraries, which are programmed against slf4j-1 and import the package 'org.slf4j' with an exclusive upper bound of 2 like '[1.7,2)', with the slf4-api version 2 in OSGi environments. According to SLF4J the client/user facing API is compatible with slf4j-1: - https://www.slf4j.org/faq.html#changesInVersion200 - https://www.slf4j.org/faq.html#compatibility Only the logging-backends/bindings/providers have match the requirements of the specific slf4j version. The corresponding SLF4J issue and change is - https://jira.qos.ch/browse/SLF4J-579 - qos-ch/slf4j#331 Fixes eclipse-platform#588 Fixes eclipse-platform#682

HannesWell · 2023-03-17T21:07:24Z

Great news. With qos-ch/slf4j#331 merged and released we can now migrate completely to slf4j 2 even if some libraries require the package org.slf4j in a version below 2.
See #981

Since version 2.0.7 the slf4j.api bundle exports the user-api package 'org.slf4j' in version 2.x.y and 1.7.36. This allows to also use libraries, which are programmed against slf4j-1 and import the package 'org.slf4j' with an exclusive upper bound of 2 like '[1.7,2)', with the slf4-api version 2 in OSGi environments. According to SLF4J the client/user facing API is compatible with slf4j-1: - https://www.slf4j.org/faq.html#changesInVersion200 - https://www.slf4j.org/faq.html#compatibility Only the logging-backends/bindings/providers have match the requirements of the specific slf4j-api version in use. Since version 2 the slf4j-api uses the ServiceLoader mechanism and requires a 'Service Loader Mediator' implementation in an OSGi runtime. Therefore the Apache Aries SPI Fly Dynamic Weaving Bundle is added with this change. The corresponding SLF4J issue and change is - https://jira.qos.ch/browse/SLF4J-579 - qos-ch/slf4j#331 Fixes eclipse-platform#588 Fixes eclipse-platform#682

Since version 2.0.7 the slf4j.api bundle exports the user-api package 'org.slf4j' in version 2.x.y and 1.7.36. This allows to also use libraries, which are programmed against slf4j-1 and import the package 'org.slf4j' with an exclusive upper bound of 2 like '[1.7,2)', with the slf4-api version 2 in OSGi environments. According to SLF4J the client/user facing API is compatible with slf4j-1: - https://www.slf4j.org/faq.html#changesInVersion200 - https://www.slf4j.org/faq.html#compatibility Only the logging-backends/bindings/providers have match the requirements of the specific slf4j-api version in use. Since version 2 the slf4j-api uses the ServiceLoader mechanism and requires a 'Service Loader Mediator' implementation in an OSGi runtime. Therefore the Apache Aries SPI Fly Dynamic Weaving Bundle is added with this change. The corresponding SLF4J issue and change is - https://jira.qos.ch/browse/SLF4J-579 - qos-ch/slf4j#331 Fixes #588 Fixes #682

HannesWell · 2023-05-26T19:05:37Z

N&N entry:

Add note about migration to slf4j-2 www.eclipse.org-eclipse-news#107

jonahgraham · 2023-05-26T19:19:18Z

Well done on seeing this to completion @HannesWell!

N&N for - eclipse-platform/eclipse.platform.releng.aggregator#588 - eclipse-platform/eclipse.platform.releng.aggregator#981

HannesWell · 2023-05-27T10:17:12Z

Well done on seeing this to completion @HannesWell!

Thank you Jonah!

By the way, I think the changes necessary for products mentioned in the SLF4J-2 N&N are probably also relevant for EPP.
Did you considered them already?
Unfortunately I cannot provide a PR for this now, because I'm on vacation for the next two weeks.

jonahgraham · 2023-05-31T13:10:19Z

Created eclipse-packaging/packages#27 for EPP work

jonahgraham · 2023-05-31T20:25:15Z

Unfortunately I cannot provide a PR for this now, because I'm on vacation for the next two weeks.

I am working on this, but I am hopelessly confused on my first pass - can we continue the discussion on eclipse-packaging/packages#27 (comment)

titou10titou10 · 2023-06-26T16:00:22Z

Add the following to your target platform.

	<location includeDependencyDepth="infinite" includeDependencyScopes="compile" includeSource="true" label="logback libraries" missingManifest="generate" type="Maven">
	   {...}
	</location>

and autostart the spifly and logback bundle in your product file.

 <plugin id="ch.qos.logback.classic" autoStart="true" startLevel="2" />
 <plugin id="org.apache.aries.spifly.dynamic.bundle" autoStart="true" startLevel="2" />

@vogella, it is the "official" way to go starting from eclipse 2023-06 for apps that uses slf4j+logback?
ie a specific eclipse target with logback v1.3 and org.apache.aries.spifly.dynamic.bundle has to be created?

If so, maybe this "vogella tutorial" should be updated : https://www.vogella.com/tutorials/EclipseLogging/article.html#configuring-logback

I hit a migration problem to 2023-06 as described on Stack overflow here: https://stackoverflow.com/questions/76556822/eclipse-rcp-2023-06-4-28-slf4j-logback-classcastexception-due-to-migrati and indeed managed to migrate my rcp app to slf4j v2.0 and logback v1.3.
If this is the right way to do it, I'll document the migration on StackOverflow as it is not so easy

HannesWell mentioned this issue Sep 24, 2022

Migrate to SLF4J + Logback and Gson from Maven-Central instead of Orbit eclipse-m2e/m2e-core#931

Merged

HannesWell changed the title ~~Migrate to SLF4J 2 and Logback from Maven-Central~~ Migrate to SLF4J-2 and Logback from Maven-Central Sep 24, 2022

HannesWell mentioned this issue Sep 24, 2022

Don't extract referenced bundles for Maven runtime classpath eclipse-m2e/m2e-core#926

Merged

HannesWell mentioned this issue Sep 26, 2022

Prepare for SLF4J 2.0 and require at least SLF4J 1.7 eclipse-m2e/m2e-core#941

Merged

mickaelistria changed the title ~~Migrate to SLF4J-2 and Logback from Maven-Central~~ Migrate to SLF4J-2 from Maven-Central Sep 28, 2022

mickaelistria linked a pull request Sep 28, 2022 that will close this issue

Use slf4j from upstream Maven instead of Orbit #598

Merged

This was referenced Sep 28, 2022

Remove SLF4J Plugin from o.e.equinox.core.sdk feature eclipse-equinox/equinox#123

Merged

Remove SLF4J Plugin from o.e.help feature eclipse-platform/eclipse.platform.releng#118

Merged

HannesWell mentioned this issue Sep 28, 2022

Remove SLF4J Plugin from o.e.passage.lic.oshi feature eclipse-passage/passage#1127

Merged

HannesWell mentioned this issue Sep 28, 2022

Remove SLF4J Plugin from all features eclipse-rap/org.eclipse.rap#61

Closed

mickaelistria closed this as completed in #598 Oct 1, 2022

HannesWell mentioned this issue Jan 30, 2023

Unresolved requirement: Require-Capability: osgi.extender; filter:="(&(osgi.extender=osgi.serviceloader.processor)(version>=1.0.0)(!(version>=2.0.0)))" eclipse-equinox/equinox#202

Closed

HannesWell mentioned this issue Mar 17, 2023

Update the Eclipse SDK TP's slf4j-api to 2.0.7 and remove 1.7 version #981

Merged

Mailaender mentioned this issue Mar 21, 2023

Update SLF4J and add Logback to diagnose thirdparty library problems eclipse/chemclipse#1361

Merged

HannesWell closed this as completed in #981 May 15, 2023

HannesWell mentioned this issue May 26, 2023

Add note about migration to slf4j-2 eclipse-platform/www.eclipse.org-eclipse-news#107

Merged

HannesWell added the noteworthy Noteworthy feature label May 26, 2023

HannesWell added a commit to eclipse-platform/www.eclipse.org-eclipse-news that referenced this issue May 26, 2023

Add note about migration to slf4j-2

9751398

N&N for - eclipse-platform/eclipse.platform.releng.aggregator#588 - eclipse-platform/eclipse.platform.releng.aggregator#981

jonahgraham mentioned this issue May 31, 2023

Update EPP for SLF4J v2 changes coming from platform eclipse-packaging/packages#27

Closed

jonahgraham mentioned this issue May 31, 2023

[#88] Fix: Grammar warnings spam stderr eclipse-cdt/cdt-lsp#90

Merged

jonahgraham mentioned this issue Jun 1, 2023

Enable logging in Eclipse Platform and Eclipse SDK products #1094

Closed

berezovskyi mentioned this issue Aug 11, 2023

Bump v.slf4j from 1.7.36 to 2.0.7 eclipse-lyo/lyo#302

Closed

Mailaender mentioned this issue Mar 21, 2024

Resolve the dependencies manually (again) eclipse/chemclipse#1714

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Migrate to SLF4J-2 from Maven-Central #588

Migrate to SLF4J-2 from Maven-Central #588

HannesWell commented Sep 24, 2022 •

edited

Loading

merks commented Sep 24, 2022

HannesWell commented Sep 24, 2022

merks commented Sep 24, 2022

HannesWell commented Sep 24, 2022

HannesWell commented Sep 25, 2022

merks commented Sep 25, 2022

HannesWell commented Sep 26, 2022

akurtakov commented Sep 26, 2022

mickaelistria commented Sep 26, 2022

HannesWell commented Sep 27, 2022

mickaelistria commented Sep 27, 2022

HannesWell commented Sep 27, 2022

HannesWell commented Sep 28, 2022 •

edited

Loading

HannesWell commented Sep 29, 2022

merks commented Sep 30, 2022

vogella commented Jan 31, 2023 •

edited

Loading

HannesWell commented Mar 17, 2023

HannesWell commented May 26, 2023

jonahgraham commented May 26, 2023

HannesWell commented May 27, 2023

jonahgraham commented May 31, 2023

jonahgraham commented May 31, 2023

titou10titou10 commented Jun 26, 2023 •

edited

Loading

Migrate to SLF4J-2 from Maven-Central #588

Migrate to SLF4J-2 from Maven-Central #588

Comments

HannesWell commented Sep 24, 2022 • edited Loading

Migration of SLF4J users/clients

Adjustments for clients to migrate from SLF4J from Orbit to SLF4J from Maven-Central

Adjustments for clients to Migrate from SLF4J 1 to SLF4J 2.0:

Migration of Logback

Migration from Logback 1.2 from Orbit to Maven-Central

Migration from Logback 1.2 to Logback 1.3 or 1.4

How to proceed

Associated changes

Migration of slf4j and logger bindings from Maven-Central

Changes to remove SLF4J from Eclipse Features

Changes to prepare bundles for SLF4J-2

merks commented Sep 24, 2022

HannesWell commented Sep 24, 2022

merks commented Sep 24, 2022

HannesWell commented Sep 24, 2022

HannesWell commented Sep 25, 2022

merks commented Sep 25, 2022

HannesWell commented Sep 26, 2022

akurtakov commented Sep 26, 2022

mickaelistria commented Sep 26, 2022

HannesWell commented Sep 27, 2022

mickaelistria commented Sep 27, 2022

HannesWell commented Sep 27, 2022

HannesWell commented Sep 28, 2022 • edited Loading

HannesWell commented Sep 29, 2022

merks commented Sep 30, 2022

vogella commented Jan 31, 2023 • edited Loading

HannesWell commented Mar 17, 2023

HannesWell commented May 26, 2023

jonahgraham commented May 26, 2023

HannesWell commented May 27, 2023

jonahgraham commented May 31, 2023

jonahgraham commented May 31, 2023

titou10titou10 commented Jun 26, 2023 • edited Loading

HannesWell commented Sep 24, 2022 •

edited

Loading

HannesWell commented Sep 28, 2022 •

edited

Loading

vogella commented Jan 31, 2023 •

edited

Loading

titou10titou10 commented Jun 26, 2023 •

edited

Loading