Bug 1123055

Summary:	OSGi info duplicated/clashing across jars
Product:	[Fedora] Fedora	Reporter:	Gerard Ryan <fedora>
Component:	apache-commons-logging	Assignee:	Mikolaj Izdebski <mizdebsk>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	high
Version:	20	CC:	java-sig-commits, mat.booth, mizdebsk, msimacek, msrb, SpikeFedora
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	1.1.3-8	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-08-09 08:03:44 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Gerard Ryan 2014-07-24 18:10:18 UTC

Description of problem:
apache-commons logging installs 3 jars: apache-commons-logging-adapters.jar, apache-commons-logging-api.jar, and commons-logging.jar. OSGi metadata in META-INF/MANIFEST.MF for each of these is the same. This appears to cause a conflict when something depends on an OSGi bundle with BSN org.apache.commons.logging -- they all have that name, so it's not known which will be resolved. This is noticed in eclipse-webtools, where a plugin Require-Bundle's this...sometimes build works, sometimes it doesn't.

Actual results:
Sometimes an acceptable bundle is resolved.

Expected results:
Probably commons-logging.jar should be the only one that has the metadata for now. It's a combination of all the classes from the other two jars.


Additional info:
Thanks to Roland Grunberg for diagnosing this!

Comment 1 Gerard Ryan 2014-07-25 00:33:50 UTC

Upstream are using the same manifest for all three jars also:


http://search.maven.org/#artifactdetails|commons-logging|commons-logging|1.2|jar

Comment 2 Mat Booth 2014-07-29 15:02:44 UTC

This should probably be fixed in F20 too, right?

$ rpm -q apache-commons-logging
apache-commons-logging-1.1.3-7.fc20.noarch
$ for j in $(rpm -ql apache-commons-logging | grep -e "/a.*jar$") ; do echo $j ; unzip -p $j META-INF/MANIFEST.MF | grep SymbolicName ; done
/usr/share/java/apache-commons-logging-adapters.jar
Bundle-SymbolicName: org.apache.commons.logging
/usr/share/java/apache-commons-logging-api.jar
Bundle-SymbolicName: org.apache.commons.logging
/usr/share/java/apache-commons-logging.jar
Bundle-SymbolicName: org.apache.commons.logging

Comment 3 Mikolaj Izdebski 2014-07-30 06:54:01 UTC

(In reply to Mat Booth from comment #2)
> This should probably be fixed in F20 too, right?

Yep. I'll fix it in F20+

Comment 4 Mikolaj Izdebski 2014-07-30 10:51:15 UTC

Fixed in apache-commons-logging-1.2-2

Comment 5 Mikolaj Izdebski 2014-07-30 11:23:01 UTC

The fix is available in rawhide now:
http://koji.fedoraproject.org/koji/buildinfo?buildID=549109
I'll backport it to F21 and F20 once you confirm that it works for you.

Comment 6 Gerard Ryan 2014-07-30 19:05:16 UTC

Works for me. I've tried on Rawhide, and also installed the updated package to f21 and tried there since that's where I was experiencing the issue. Both appear to have built fine now.

Comment 7 Mikolaj Izdebski 2014-07-31 07:46:03 UTC

Fixed in apache-commons-logging-1.1.3-8

Comment 8 Fedora Update System 2014-07-31 08:08:51 UTC

apache-commons-logging-1.1.3-8.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/apache-commons-logging-1.1.3-8.fc20

Comment 9 Fedora Update System 2014-08-09 07:31:50 UTC

apache-commons-logging-1.1.3-8.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 Mikolaj Izdebski 2014-08-09 08:03:44 UTC

I believe that this bug is fixed in apache-commons-logging-1.1.3-8,
which is available in updates for Fedora 20, so I am closing this bug now.

The build containing the fix can be found at Koji:
http://koji.fedoraproject.org/koji/buildinfo?buildID=549346