You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by "Thomas Pasch (JIRA)" <ji...@apache.org> on 2019/01/11 20:43:00 UTC

[jira] [Comment Edited] (FOP-2733) [PATCH] Drop dependency on Avalon-Framework

    [ https://issues.apache.org/jira/browse/FOP-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16740765#comment-16740765 ] 

Thomas Pasch edited comment on FOP-2733 at 1/11/19 8:42 PM:
------------------------------------------------------------

??FopFactoryBuilder.setConfiguration takes avalon object as a param so this change would break end user code. Maybe someone could fork Avalon and remove bits we dont use then we can link with that.??

??[https://xmlgraphics.apache.org/fop/trunk/embedding.html#config-external]??

Only right if the packages are renamed. Wrong if the original package would be preserved.

Frankly, I just can't see any reason for insisting on keeping avalon as dependency.


was (Author: aanno):
> FopFactoryBuilder.setConfiguration takes avalon object as a param so this change would break end user code. Maybe > someone could fork Avalon and remove bits we dont use then we can link with that.

> [https://xmlgraphics.apache.org/fop/trunk/embedding.html#config-external]

Only right if the packages are renamed. Wrong if the original package would be preserved.

Frankly, I just can't see any reason for insisting on keeping avalon as dependency.

> [PATCH] 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
>            Priority: Major
>         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
(v7.6.3#76005)