Note that building the same erlang package for f14 and f15 works, it is just rawhide which fails. This might be connected to fop-1.0 vs fop-0.9x

Created attachment 486887 [details]
build.log of failing erlang build

The build.log from the failed koji build of the erlang package.

Ping?

Hi Hans, yes, this is almost certainly due to a difference between FOP 0.9 and FOP 1.0; I've seen a similar error in another tool that uses FOP (Publican). I'll update as soon as I know more.

Cheers
Rudi

Ah, good to see confirmation.

I have just implemented a workaround for the erlang package build (using prebuilt docs instead of of rebuilding them).

I will keep that workaround for the time being until fop works again and will keep tracking this bug in the mean time.

*** Bug 700709 has been marked as a duplicate of this bug. ***

If it helps, here's the full exception it throws for me when building locally:

publican-2.5-2.fc15.noarch





SEVERE: Exception
java.util.MissingResourceException: File event-model.xml not found
	at org.apache.fop.events.DefaultEventBroadcaster.loadModel(DefaultEventBroadcaster.java:83)
	at org.apache.fop.events.DefaultEventBroadcaster.getEventProducerModel(DefaultEventBroadcaster.java:114)
	at org.apache.fop.events.DefaultEventBroadcaster.createProxyFor(DefaultEventBroadcaster.java:142)
	at org.apache.fop.events.DefaultEventBroadcaster.getEventProducerFor(DefaultEventBroadcaster.java:129)
	at org.apache.fop.fonts.FontEventProducer$Provider.get(FontEventProducer.java:43)
	at org.apache.fop.fonts.FontEventAdapter.getEventProducer(FontEventAdapter.java:44)
	at org.apache.fop.fonts.FontEventAdapter.fontLoadingErrorAtAutoDetection(FontEventAdapter.java:56)
	at org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:262)
	at org.apache.fop.fonts.FontAdder.add(FontAdder.java:60)
	at org.apache.fop.fonts.FontDetector.detect(FontDetector.java:90)
	at org.apache.fop.fonts.FontInfoConfigurator.configure(FontInfoConfigurator.java:92)
	at org.apache.fop.render.PrintRendererConfigurator.buildFontList(PrintRendererConfigurator.java:106)
	at org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:129)
	at org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:165)
	at org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:181)
	at org.apache.fop.area.RenderPagesModel.<init>(RenderPagesModel.java:73)
	at org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:130)
	at org.apache.fop.area.AreaTreeHandler.<init>(AreaTreeHandler.java:102)
	at org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:359)
	at org.apache.fop.fo.FOTreeBuilder.<init>(FOTreeBuilder.java:105)
	at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:101)
	at org.apache.fop.apps.Fop.<init>(Fop.java:79)
	at org.apache.fop.apps.FopFactory.newFop(FopFactory.java:271)
	at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:109)
	at org.apache.fop.cli.Main.startFOP(Main.java:174)
	at org.apache.fop.cli.Main.main(Main.java:204)
	Finished pdf


No .pdf file is written to tmp/.. when this error occurs.

(In reply to comment #7)
  
> No .pdf file is written to tmp/.. when this error occurs.

Acknowledged (See Comment 6 of this bug).

So, the various event-model.xml files that should be packed into fop-1.0.jar are not getting generated by the ant resourcegen task at build time. Still working on this.

Comparing the package built on Koji with the binary available upstream, it seems that there should be one of these event model files for most of the classes in the .jar, but they're simply not created at build time.

The problem is in our EventProducerCollector, which is patched to use a different version of qdox (1.12) from the one that upstream bundles with FOP (1.6). Specifically, clazz.getParentClass() is always null and would result in a null pointer exception:

/home/rlandmann/rpmbuild/BUILD/fop-1.0/build.xml:374: java.lang.NullPointerException
        at com.thoughtworks.qdox.model.JavaMethod.getReturnType(JavaMethod.java:464)
        at com.thoughtworks.qdox.model.JavaMethodDelegate.getReturnType(JavaMethodDelegate.java:26)
        at com.thoughtworks.qdox.model.JavaMethodDelegate.getReturnType(JavaMethodDelegate.java:166)
        at org.apache.fop.tools.EventProducerCollector.createMethodModel(EventProducerCollector.java:142)
        at org.apache.fop.tools.EventProducerCollector.processEventProducerInterface(EventProducerCollector.java:130)
        at org.apache.fop.tools.EventProducerCollector.scanFile(EventProducerCollector.java:99)
        at org.apache.fop.tools.EventProducerCollectorTask.processFileSets(EventProducerCollectorTask.java:213)
        at org.apache.fop.tools.EventProducerCollectorTask.execute(EventProducerCollectorTask.java:69)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
        at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:390)
        at org.apache.tools.ant.Target.performTasks(Target.java:411)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
        at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
        at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
        at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
        at org.apache.tools.ant.Main.runBuild(Main.java:809)
        at org.apache.tools.ant.Main.startAnt(Main.java:217)
        at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
        at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)

...except that we have a check at lines 125-127 that just quits if clazz.getParentClass() is null.

Alex Kurtakov and I took a look at this today.  svn revision 1066078 is the one where upstream moved to the version of qdox we have in Fedora.  Alex has already added that as a patch.  We tried building a trunk checkout and not surprisingly this works.  When we try to use the JARs that Fedora ships for the dependencies, it fails because fop trunk is using an SVN snapshot JAR of xmlgraphics-commons.

Has anyone spoken with upstream about the situation?

(In reply to comment #11)
> Alex Kurtakov and I took a look at this today.  svn revision 1066078 is the one
> where upstream moved to the version of qdox we have in Fedora.  Alex has
> already added that as a patch.  We tried building a trunk checkout and not
> surprisingly this works.  When we try to use the JARs that Fedora ships for the
> dependencies, it fails because fop trunk is using an SVN snapshot JAR of
> xmlgraphics-commons.
> 
> Has anyone spoken with upstream about the situation?

Ah, I (obviously) hadn't spotted the difference in xmlgraphics-commons.

I posted to fop-dev list a couple of days ago with the same information I included in comment #10 above; no reply yet.

I'll fine-tune the question to the list in light of this new information -- many thanks! :)

FWIW, this seems related to https://issues.apache.org/bugzilla/show_bug.cgi?id=50575.

In both cases, it seems that the Fedora/RHEL packages are missing the event models, while the binaries provided upstream contain them.

After further investigation of this it seems that taking the source tgz (un-patched) and gradually removing each of the bundled libs (modifying the classpaths in build.xml accordingly) I was able to build against the Fedora packaged versions of the library and still got event-model.xml files generated out of the build.

The notable exception of course is qdox which requires the bundled patch to handle an NPE - unfortunately it then fails silently and no event-model.xml files are generated as was previously the case.

It seems based on the above, and Rudi's verification of my results, that the xmlgraphics-common bundling while poor form is probably a furphy. That said it remains unclear as to what has changed that has made the qdox patch ignore more classes than i did previously.

This is fixed with fop-1.0-16.fc16  on rawhide. Downgraded to fop-1.0-14.fc16 things failed. Reinstall fop-1.0.16.fc16 and able to generate pdf file.

I can confirm that fop 1.0-16 indeed fixed the problem.

fop-1.0-16.fc16.noarch from rawhide is working for me, too.
My java version fwiw is java-1.6.0-openjdk-1.6.0.0-58.1.10.2.fc15.x86_64

Confirmed, 1.0-16.fc16 solves this and bug #704298 for me on f15.

(In reply to comment #13)
> FWIW, this seems related to
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50575.
> 
> In both cases, it seems that the Fedora/RHEL packages are missing the event
> models, while the binaries provided upstream contain them.

Debian too now; I've updated the upstream bug to point here.

Unfortunately, we can't ship the (working) 1.0-16 to get around this issue, since building it relies on a really ugly hack: basically, I just extracted the various event-model.xml files from the upstream binary, tarred them up, then inserted them in the appropriate places at build time; they weren't actually generated during the build.

I don't think we should be shipping stuff that we can't build without resorting to such tricks :(

fop-1.0-17.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/fop-1.0-17.fc15

Package fop-1.0-17.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing fop-1.0-17.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/fop-1.0-17.fc15
then log in and leave karma (feedback).

fop-1.0-17.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.