Hello,
My research showed that we have a problem with adding higher versions of SLF4J. Currently we have logback 1.0.0 and 1.0.3 and slf4j 1.6.4. There is only one
ch.qos.logback.slf4j fragment for both versions of logback and it has version 1.0.0. This works fine.
But adding slf4j 1.7.2 breaks ch.qos.logback.slf4j_1.0.0 fragment. This happens like this:
logback.slf4j 1.0.0 imports ch.qos.logback.classic package with version range [1.0.0, 1.0.4), which makes it wire to 1.0.3. but ch.cos.logback.classic 1.0.3
exports this package with a uses directive to org.slf4j package (among others). However, ch.cos.logback.classic 1.0.3 bundle imports org.slf4j package with version “1.6.4”, so this import gets wired to the highest version present, which is 1.7.2.
ch.qos.logback.slf4j 1.0.0 imports org.slf4j package with version “1.6.4”, so it gets wired to 1.7.2 as well. But it is a fragment of org.slf4j.api 1.6.4 and
it fails to attach to the host because conflict of the bundle versions. I tried to make the version range of the import of org.slf4j in ch.qos.logback.slf4j 1.0.0 [1.6.4, 1.6.5) and then it gets wired to 1.6.4, but this leads to package uses conflict related
to ch.qos.logback.classic package, which requires the higher version of org.slf4j.
The error in the build are different, but I think it is caused by the same root cause. In the case of the build the imports of org.slf4j packages with version
1.6.4 cannot be resolved, although the bundle is there. I suspect that the attachment of the fragment, importing version 1.7.2 of the same package, succeeds and the host packages are substituted with the higher version. So version 1.6.4 is not provided by
any bundle and cannot be resolved.
Probably this could be fixed if in ch.qos.logback.classic bundle the imports are with version range, limited to 1.7.0, but this is obviously not the intention
of the logback providers.
I opend a bug for this (https://bugs.eclipse.org/bugs/show_bug.cgi?id=395802), because it is a general situation and we will be facing it as long as we have
more than one version of org.slf4j.api. You could write there any suggestions or comments.
Regards,
Lazar
From: orbit-dev-bounces@xxxxxxxxxxx [mailto:orbit-dev-bounces@xxxxxxxxxxx]
On Behalf Of Kirchev, Lazar
Sent: Tuesday, December 04, 2012 5:27 PM
To: Orbit Developer discussion
Subject: Re: [orbit-dev] Unstable Builds Coming!
First I thought the same, but it seems that the problem is different.
The symptoms in the bug are different, and when I debug the local setup there is no race for two fragments to attach to one and the same host – there are two
fragments and two hosts and each fragment qualifies only for one host – the version ranges are given in an unambiguous way.
I am continuing to debug. Although I don’t reproduce exactly the same problem, I think that what I observe in the local setup is related to the problem in the
build.
In the meanwhile I removed logback 1.0.7/ slf4j 1.7.2 from the build to fix it.
From: orbit-dev-bounces@xxxxxxxxxxx [mailto:orbit-dev-bounces@xxxxxxxxxxx]
On Behalf Of David M Williams
Sent: Tuesday, December 04, 2012 5:17 PM
To: Orbit Developer discussion
Subject: Re: [orbit-dev] Unstable Builds Coming!
Are these the same issues discussed in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=388140
(involving fragments only being allowed to attach to one host?)
From: "Kirchev, Lazar" <l.kirchev@xxxxxxx>
To: Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>,
Date: 12/04/2012 09:29 AM
Subject: Re: [orbit-dev] Unstable Builds Coming!
Sent by: orbit-dev-bounces@xxxxxxxxxxx
Hello all,
The log of the failing build shows that if logback 1.07 and slf4j.api 1.7.2 bundles are present, org.slf4j.log4j, org.slf4j.jul, org.slf4j.jcl and org.slf4j.ext all have unsatisfied imports:
[orbit-set1] generateScript:
[orbit-set1] [eclipse.buildScript] Some inter-plug-in dependencies have not been satisfied.
[orbit-set1] [eclipse.buildScript] Bundle org.slf4j.log4j:
[orbit-set1] [eclipse.buildScript] Unsatisfied import package org.slf4j_[1.6.4,1.7.0).
[orbit-set1] [eclipse.buildScript] Unsatisfied import package org.slf4j.spi_[1.6.4,1.7.0).
[orbit-set1] [eclipse.buildScript] Bundle org.slf4j.jul:
[orbit-set1] [eclipse.buildScript] Unsatisfied import package org.slf4j_[1.6.4,1.7.0).
[orbit-set1] [eclipse.buildScript] Unsatisfied import package org.slf4j.spi_[1.6.4,1.7.0).
[orbit-set1] [eclipse.buildScript] Bundle org.slf4j.jcl:
[orbit-set1] [eclipse.buildScript] Unsatisfied import package org.slf4j_[1.6.4,1.7.0).
[orbit-set1] [eclipse.buildScript] Unsatisfied import package org.slf4j.spi_[1.6.4,1.7.0).
[orbit-set1] [eclipse.buildScript] Bundle org.slf4j.ext:
[orbit-set1] [eclipse.buildScript] Unsatisfied import package ch.qos.cal10n_0.7.2.
[orbit-set1] [eclipse.buildScript] Unsatisfied import package org.slf4j_[1.6.4,1.7.0).
[orbit-set1] [eclipse.buildScript] Unsatisfied import package org.slf4j.helpers_[1.6.4,1.7.0).
[orbit-set1] [eclipse.buildScript] Unsatisfied import package org.slf4j.spi_[1.6.4,1.7.0).
The imports are unsatisfied although the bundles org.slf4j.api 1.6.4, which exports them, is there.
Any ideas what could be the problem?
I try to reproduce this in a local setup containing only logback/slf4j related bundles, but it does not reproduce. However, in the setup ch.cos.logback.slf4j 1.0.0 cannot be resolved and attached to the host org.slf4j.api 1.6.4 due to "conflicting constraints
with the host". I suspect that this could be related to the above problem.
Regards,
Lazar
-----Original Message-----
From: orbit-dev-bounces@xxxxxxxxxxx [mailto:orbit-dev-bounces@xxxxxxxxxxx] On Behalf Of Kirchev, Lazar
Sent: Tuesday, December 04, 2012 12:00 PM
To: Orbit Developer discussion
Subject: Re: [orbit-dev] Unstable Builds Coming!
Hi,
I found two suspicious manifests, which could eventually cause the failures:
1.
ch.cos.logback.slf4j_1.0.0 imports org.slf4j.* packages with version "1.6.4" - which is open interval to infinity and should be resolved to 1.7.2, since this is the higher version. However, it is a fragment of org.slf4j.api, version 1.6.4, which exports
the packages the same packages with version 1.6.4. Probably it is better to import the packages with range, so that there are no ambiguities?
2.
ch.cos.logback.slf4j_1.0.7 has no imports, however it has an exports with a uses clause. Is the import header missing?
Regards,
Lazar
-----Original Message-----
From: orbit-dev-bounces@xxxxxxxxxxx [mailto:orbit-dev-bounces@xxxxxxxxxxx] On Behalf Of Gunnar Wagenknecht
Sent: Monday, December 03, 2012 2:34 PM
To: Orbit Developer discussion
Subject: [orbit-dev] Unstable Builds Coming!
Sorry folks,
Lazar and I want to investigate the SLF4J resolution issues at build
time. None of us is able to setup an Orbit builder quickly on a local
machine. Thus, we'd like to use build.eclipse.org for a few test builds.
Sorry for any upcoming build breakage mails.
-Gunnar
--
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx
http://wagenknecht.org/
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev
