Bug 227055 - Review Request: fop - XSL-driven print formatter
Review Request: fop - XSL-driven print formatter
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Fitzsimmons
Fedora Package Reviews List
: 332871 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2007-02-02 12:35 EST by Rafael H. Schloming
Modified: 2014-12-01 18:13 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-27 10:01:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
fitzsim: fedora‑review+
kevin: fedora‑cvs+

Attachments (Terms of Use)
Fixed wrapper script. (655 bytes, application/octet-stream)
2007-11-26 13:08 EST, Thomas Fitzsimmons
no flags Details

  None (edit)
Description Rafael H. Schloming 2007-02-02 12:35:44 EST
Spec URL: http://people.redhat.com/rafaels/specs/fop-0.20.5-9jpp.spec
SRPM URL: ftp://jpackage.hmdc.harvard.edu/JPackage/1.7/generic/SRPMS.free/fop-0.20.5-9jpp.src.rpm
Description: FOP is the world's first print formatter driven by XSL formatting
objects. It is a Java application that reads a formatting object tree
and then turns it into a PDF document. The formatting object tree, can
be in the form of an XML document (output by an XSLT engine like XT or
Xalan) or can be passed in memory as a DOM Document or (in the case of
XT) SAX events.

Javadoc for fop.
Comment 1 Matthias Saou 2007-03-22 08:18:53 EDT
The latest version is now 0.93.

You might also want to start by cleaning up the spec file, since it still
contains a lot of jpackage-isms, which I don't think are really relevant to
Fedora (jpp release tag, long copyright notice for instance).
Comment 2 Jason Tibbitts 2007-06-21 16:44:49 EDT
Clearing FE-NEW since this is under review, although it's been an awfully long
time without any review comments.
Comment 3 Thomas Fitzsimmons 2007-10-15 13:48:54 EDT
*** Bug 332871 has been marked as a duplicate of this bug. ***
Comment 4 Lillian Angel 2007-10-15 14:05:33 EDT
Updated to the new upstream release:
Comment 5 Lillian Angel 2007-11-22 15:37:13 EST
Updated these files again:

Just to clarify, running the testsuite in %build is not a good idea because not
all tests pass, causing the build to fail.
Comment 6 Thomas Fitzsimmons 2007-11-22 16:49:14 EST
- rpmlint:

$ rpmlint fop-0.94-1.src.rpm

$ rpmlint /notnfs/fitzsim/rpmbuild/RPMS/noarch/fop-0.94-1.noarch.rpm
fop.noarch: W: class-path-in-manifest /usr/share/java/fop-0.94.jar

The Class-Path field in this manifest is added by fop-manifest.patch, but it
should not be:

$ rpmlint -i RPMS/noarch/fop-0.94-1.noarch.rpm 
fop.noarch: W: class-path-in-manifest /usr/share/java/fop-0.94.jar
The META-INF/MANIFEST file in the jar contains a hardcoded Class-Path.
These entries do not work with older Java versions and even if they do work,
they are inflexible and usually cause nasty surprises.

- package name fine

- spec file name matches package name

- package meets packaging guidelines

The BuildRoot line is non-standard.

- package meets licensing guidelines

- license field matches actual license

- license marked %doc

- spec file uses American English

- spec file legible

%define section devel

Remove the top two lines.

(cd $RPM_BUILD_ROOT%{_javadir} && for jar in *-%{version}*; do ln -sf ${jar}
`echo $jar| sed "s|-%{version}||g"`; done)

This should be done as a pushd/popd block.  In general, spec file lines should
wrap at the 80th column.

- source and upstream md5sum match

- package builds successfully on i386

- all build requirements listed

No, none are listed.

- no locales

- no shared libraries for ldconfig

- not relocatable

- directories:
  - owns %{_javadocdir}/%{name}-%{version} and %{_datadir}/fop, which
    it creates
  - requires jpackage-utils for %{_javadir} into which it installs jar files

- no duplicate files

- permissions

Replace 0644 and 0755 in the %defattr lines with - to use the default values.

- %clean section fine

- consistent use of macros

- contains code

- doc subpackage

- docs don't affect runtime

- no header files

- no static libraries

- no pkgconfig files

- no library files

- no devel package

- no .la files

- no desktop files

- doesn't own other packages' directories

- removes buildroot at start of %install

- filenames valid UTF-8

- license text included

- no description/summary translations available

- builds in mock on i386

No.  Missing BuildRequires lines cause the build to fail.

- other architectures not tested, but this is a noarch package

- did not test proper functioning, since fop requires batik

- no scriptlets

- javadoc package doesn't require base package -- fine

- no pkgconfig files

- packages required, rather than individual files
Comment 8 Thomas Fitzsimmons 2007-11-23 16:21:51 EST

export JAVA_HOME=/usr/lib/jvm/java-icedtea

in the build environment, I can build with rpmbuild on i386.

When I try /usr/bin/fop, I get this:

$ /usr/bin/fop 
Exception in thread "main" java.lang.NoClassDefFoundError:
        at org.apache.fop.apps.FopFactory.<clinit>(FopFactory.java:63)
        at org.apache.fop.cli.CommandLineOptions.<init>(CommandLineOptions.java:100)
        at org.apache.fop.cli.Main.startFOP(Main.java:153)
        at org.apache.fop.cli.Main.main(Main.java:196)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.logging.LogFactory
        at java.net.URLClassLoader$1.run(URLClassLoader.java:220)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:208)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:323)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:268)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:336)
        ... 4 more
Comment 9 Lillian Angel 2007-11-26 11:30:42 EST
I tested out the mock build, and uploaded the new spec file and srpm.

Also, to run fop you need to set CLASSPATH up properly:
export CLASSPATH=$CLASSPATH:/usr/share/java/commons-logging.jar:
Comment 10 Thomas Fitzsimmons 2007-11-26 13:08:32 EST
Created attachment 269141 [details]
Fixed wrapper script.

/usr/bin/fop failed on startup due to the classpath issues you mentioned.  Here
is an updated wrapper script that handles all the classpath setup.
Comment 11 Thomas Fitzsimmons 2007-11-26 13:09:57 EST

Please update the wrapper script before committing.
Comment 12 Lillian Angel 2007-11-26 13:16:39 EST

Uploaded the new spec file and srpm.
Comment 13 Lillian Angel 2007-11-26 13:16:57 EST
New Package CVS Request
Package Name: fop
Short Description: XSL-driven print formatter
Owners: langel
Branches: F-8
InitialCC: fitzsim
Cvsextras Commits: yes
Comment 14 Kevin Fenzi 2007-11-26 23:01:05 EST
(corrected the Summary to have just the package name in it, you shouldn't put
versions in there). 

cvs done. 
Comment 15 Alex Lancaster 2008-01-16 20:52:18 EST
Can we please have an update pushed to the F-8 branch via bodhi?  Thanks.
Comment 16 Alex Lancaster 2008-01-16 20:53:17 EST
I didn't even see a build in bodhi:


even though the CVS F-8 branch is done.

Note You need to log in before you can comment on or make changes to this bug.