Description of problem: jline2 doesn't follow Java packaging guidelines for compatibility packages. According to the guidelines all compatibility packages must have *versioned* JAR and POM files and they *must not* install unversioned versions. Additionally they should not provide depmaps. If jline2 should be considered as main package and jline as compatibility package then jline has to be renamed to jline1 and jline2 to jline. This is an important bug as it causes some FTBFS. Version-Release number of selected component (if applicable): 2.10-2 Additional info: See Java packaging guidelines [1]. [1] http://fedoraproject.org/wiki/Packaging:Java#Compatibility_packages
(In reply to comment #0) > Description of problem: > jline2 doesn't follow Java packaging guidelines for compatibility packages. > According to the guidelines all compatibility packages must have *versioned* > JAR and POM files and they *must not* install unversioned versions. > Additionally they should not provide depmaps. > > If jline2 should be considered as main package and jline as compatibility > package then jline has to be renamed to jline1 and jline2 to jline. > > This is an important bug as it causes some FTBFS. > > Version-Release number of selected component (if applicable): > 2.10-2 > > Additional info: > See Java packaging guidelines [1]. > > [1] http://fedoraproject.org/wiki/Packaging:Java#Compatibility_packages I believe I have example of ftbfs from this in bz#914544. The logs for that have been cleaned up, but I can summarize. Despite having correct (I believe) BR in spec and dependencies in maven build, I see things like: error: package jline.console does not exist and error: cannot find symbol [ERROR] symbol: class ConsoleReader at the point where the build fails (while upstream build using non-fedora jline2 dependency has no problems). Mikolaj, is there some workaround with xmvn I can use for thermostat package in the meantime? I would like to update that to newer upstream release.
(In reply to comment #1) > Mikolaj, is there some workaround with xmvn I can use for thermostat package > in the meantime? I would like to update that to newer upstream release. There is a workaround, but this bug causes FTBFS in other packages too. I would rather fix the real cause in one package than introducing workarounds in multiple packages. The fix is quite simple and should be ready before the end of the week. Marek, what's the status on this bug? Do you mind if I fix this bug as a provenpackager?
(In reply to comment #2) > (In reply to comment #1) > > Mikolaj, is there some workaround with xmvn I can use for thermostat package > > in the meantime? I would like to update that to newer upstream release. > > There is a workaround, but this bug causes FTBFS in other packages too. I > would rather fix the real cause in one package than introducing workarounds > in multiple packages. The fix is quite simple and should be ready before the > end of the week. > Even better. I will be patient :)
Created attachment 703840 [details] Proposed patch
Created attachment 703843 [details] Proposed patch
With this patch applies jline is correctly resolved by default, while jline2 is resolved when a specific version is requested. $ xmvn-resolve jline:jline /usr/share/maven-poms/JPP-jline.pom $ xmvn-resolve jline:jline:2.10 /usr/share/maven-poms/JPP-jline2-2.10.pom I believe the attached patch resolved the bug.
Mikołaj, please go ahead and apply your patch. Thanks!
Fixed in jline2-2.10-4
I believe that this bug is fixed in jline2-2.10-4, which is available in Fedora Rawhide, so I am closing this bug now. The build containing the fix can be found at Koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=398865