Bug 1049900

Summary: bookkeeper: FTBFS in rawhide
Product: [Fedora] Fedora Reporter: Mikolaj Izdebski <mizdebsk>
Component: bookkeeperAssignee: Timothy St. Clair <tstclair>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: java-sig-commits, mizdebsk, rrati, tstclair
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: bookkeeper-4.2.1-6.fc21 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-28 05:06:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1010003    

Description Mikolaj Izdebski 2014-01-08 13:09:30 UTC 
Description of problem:
Package bookkeeper fails to build from source in rawhide.

Koji scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6372681

Quoting from build logs:

[ERROR] COMPILATION ERROR : 
[INFO] -------------------------------------------------------------
[ERROR] /builddir/build/BUILD/bookkeeper-4.2.1/hedwig-server/src/main/java/org/apache/hedwig/admin/console/HedwigConsole.java:[21,13] cannot find symbol
  symbol:   class ConsoleReader
  location: package jline

Version-Release number of selected component (if applicable):
4.2.1-5

Additional info:
[1] http://fedoraproject.org/wiki/Packaging:Java
[2] http://fedoraproject.org/wiki/Packaging:Guidelines
Comment 1 Timothy St. Clair 2014-01-08 17:18:51 UTC 
This appears to be a transitive overlap where a dependency now uses the new jline while the package itself calls out jline1.  

Is there a pattern to ensure classpath ordering to resolve, or is this going to be a thornier issue until folks transition to jline 2.
Comment 2 Mikolaj Izdebski 2014-01-08 22:17:26 UTC 
(In reply to Timothy St. Clair from comment #1)
> This appears to be a transitive overlap where a dependency now uses the new
> jline while the package itself calls out jline1.  
> 
> Is there a pattern to ensure classpath ordering to resolve, or is this going
> to be a thornier issue until folks transition to jline 2.

Usually it's best to port code using the old jline to jline2 and forward the patch upstream.
Comment 3 Timothy St. Clair 2014-01-09 16:27:39 UTC 
There is a bookkeeper 4.2.2 release that drops it's jline dependency, but it has some issues with HDFS. https://issues.apache.org/jira/browse/HDFS-541 

So any work to update to jline 2 would be wasted.  I'll circle back to this when I can think of something more creative. 

Ideally I would like to not update but ensure the classpath is correct, then eventually take the newer version.
Comment 4 Timothy St. Clair 2014-01-28 05:06:34 UTC 
Patched to support jline and netty3.   

Required a zookeeper rebuild which also had similar dependency issues.

Other dependent packages may want to rebuild sans mods (hadoop, etc)