Chris West created FOP-2733:
-------------------------------

             Summary: Drop dependency on Avalon-Framework
                 Key: FOP-2733
                 URL: https://issues.apache.org/jira/browse/FOP-2733
             Project: FOP
          Issue Type: Bug
            Reporter: Chris West
         Attachments: fop-no-avalon-1.patch

FOP depends on avalon-framework, an old Apache project officially abandoned in 
2004. Nearly nobody uses avalon-framework anymore, and I'd like to see it laid 
to rest.

avalon-framework no-longer compiles with Java 9. Fixing it yet again seems like 
insanity. This isn't a problem for Maven users, who can keep using the old 
binary (and suffer slow verification on startup), but is a problem for distros 
like Debian, who want to be able to build everything.

Others have asked about this before, e.g. 
http://apache-fop.1065347.n5.nabble.com/FOP-and-Avalon-td44302.html

I propose removing the dependency on Avalon entirely, fixing the couple of 
cases where it breaks, and inlining the two packages that are actually still 
used.. I have created a patch here: 
https://github.com/apache/fop/compare/trunk...FauxFaux:trunk , also attached.

It's not great to read in patch form, so here's a summary of the changes:

 * Remove dependence on avalon-framework from Maven, classpath variables etc.
 * Add Avalon's configuration package as main:org.apache.fop.configuration 
directly, and keep using it essentially unmodified.
 * Add Avalon's logging framework as test:org.apache.fop.threading.logger. This 
is only used in test code, in the threaded test code runner. It is essentially 
source compatible with log4j/commons-logging, so could probably be deleted.
 * Change `CIDFontType` from a Avalon enum to a Java5 `enum`. This appears to 
be source, but not binary, compatible.
 * Remove some use of lifecycle management interfaces in test code, which are 
not doing anything.
 * Change some exception printing in test code to print the full exception 
(using the Java api), instead of a truncated exception. The output is not 
asserted upon, just sent to stderr.
 * Stop using Cascading*Exception in tests, and for ConfigurationException. I 
doubt anyone will notice, as it offers no real functionality.

That's it!

The most controversial thing here is probably adding the configuration package, 
and the extra lines of code it drags along with it. I am happy to give it a bit 
of a polish; make significant changes to fop to remove all the unused 
interfaces / abstract classes (which are just waste); put some generics and 
formatting in, etc.?




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to