getVersion returns null
This means the configuration hasn't been read or someone deleted the version key/value from the config.xml file.
Looks like invalid. But Jonathan, feel free to reopen the bug.
*** Bug 17817 has been marked as a duplicate of this bug. ***
So, is this a bug? I looked into config.xml, there is: <entry> <key>version</key> <value>FOP @version@</value> </entry> ??? But then, why does getVersion() return null?
The <value>FOP @version@</value> is in the source config.xml. This is filtered to get the real version into the file during build and packaged into the FOP jar. Therefore: look into the jar to see what really is in there. Furthermore, Version.getVersion() returns null unless either the config.xml is read or the version is explicitely set in the Configuration class (static method). The config.xml is loaded automatically from the jar during instanciation of an an Options object. If FOP is embedded, the FOP core will not automatically instanciate Options, the embedder must take care of this. Often an userconfig is loaded through a 'new Options("userconfig.xml")' or such, this will also load the config.xml from the jar. It's quirky but its supposed to work this way.
okay, thats FOP internal stuff - i'm just a user, so why do you set this bug to "Resolved Invalid"? as a user, i just call org.apache.fop.apps.Version.getVersion() that returns null ...
You are not supposed to call Version.getVersion() before you've instantiated an Options object. In fact, the original intention was that you weren't supposed to call Version.getVersion() at all. This is actually documented somewhere. FOP wasn't originally designed with an API in mind. This will change in some future release.
hm, okay but it's the same way like in apache Xerces: System.out.println("Version: "+org.apache.xerces.impl.Version.getVersion()); works flawlessly :-)
batch transition to closed remaining pre-FOP1.0 resolved bugs