[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=17052100#comment-17052100
]
Mathieu Malaterre edited comment on FOP-2733 at 3/5/20, 12:51 PM:
--
Could someone please confirm this is fixed in 2.4.
Here is what I see on my side:
{code}
$ grep -r avalon-framework
fop/test/createpdf.sh:$JAVA_HOME/bin/java -cp
../build/fop.jar:../lib/batik.jar:../lib/xalan-2.0.0.jar:../lib/xerces-1.2.3.jar:../lib/avalon-framework-4.0.jar:../lib/logkit-1.0b4.jar:../lib/jimi-1.0.jar
org.apache.fop.tools.TestConverter -pdf -b ./ basictests.xml
fop/test/createpdf.sh:$JAVA_HOME/bin/java -cp
../build/fop.jar:../lib/batik.jar:../lib/xalan-2.0.0.jar:../lib/xerces-1.2.3.jar:../lib/avalon-framework-4.0.jar:../lib/logkit-1.0b4.jar:../lib/jimi-1.0.jar
org.apache.fop.tools.TestConverter -pdf -b ./ bugtests.xml
fop/examples/hyphenation/analyse.cmd:set
LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\avalon-framework-4.2.0.jar
{code}
was (Author: malaterre):
Could someone please confirm this is fixed in 2.4.
Here is what I see on my side:
{{$ grep -r avalon-framework
fop/test/createpdf.sh:$JAVA_HOME/bin/java -cp
../build/fop.jar:../lib/batik.jar:../lib/xalan-2.0.0.jar:../lib/xerces-1.2.3.jar:../lib/avalon-framework-4.0.jar:../lib/logkit-1.0b4.jar:../lib/jimi-1.0.jar
org.apache.fop.tools.TestConverter -pdf -b ./ basictests.xml
fop/test/createpdf.sh:$JAVA_HOME/bin/java -cp
../build/fop.jar:../lib/batik.jar:../lib/xalan-2.0.0.jar:../lib/xerces-1.2.3.jar:../lib/avalon-framework-4.0.jar:../lib/logkit-1.0b4.jar:../lib/jimi-1.0.jar
org.apache.fop.tools.TestConverter -pdf -b ./ bugtests.xml
fop/examples/hyphenation/analyse.cmd:set
LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\avalon-framework-4.2.0.jar}}
> [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
>Assignee: Simon Steiner
>Priority: Major
> Attachments: barcode.pdf, 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
(v8.3.4#803005)
[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=16917540#comment-16917540 ] edwin george edited comment on FOP-2733 at 8/28/19 8:22 AM: Does this code got released ??? I can still see the PR on github is not merged . if this code is released can please give the version for that ?? ./Edwin was (Author: edwingsm): Does this code got released ??? I can still see the PR on github is not merged . What version of fop should i used to avoid conflicts ??? ./Edwin > [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 >Assignee: simon steiner >Priority: Major > Attachments: barcode.pdf, 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 (v8.3.2#803003)
[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=16743878#comment-16743878 ] Thomas Pasch edited comment on FOP-2733 at 1/16/19 11:09 AM: - I would be good if one would open a avalon-remove ticket with barcode4j. However, I did not find a issue tracker... was (Author: aanno): I would be a good if one would open a avalon-remove ticket with barcode4j. However, I did not find a issue tracker... > [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 >Assignee: simon steiner >Priority: Major > Attachments: barcode.pdf, 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)
[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=16743862#comment-16743862 ] Thomas Pasch edited comment on FOP-2733 at 1/16/19 11:04 AM: - Ah, I forgot that I have encountered a few java 6 compilation problems before that and added them to my PR. was (Author: aanno): Ah, I forgot that I have encounter a few java 6 compilation problems before that and added them to my PR. > [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 >Assignee: simon steiner >Priority: Major > Attachments: barcode.pdf, 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)
[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=16743789#comment-16743789 ] Thomas Pasch edited comment on FOP-2733 at 1/16/19 9:27 AM: Well, barcode4j still depends on avalon. Hence, if you want to use, you have to include avalon api and impl in the classpath as well. Perhaps you can provide the test fop xml (with an barcode included) so that I've get a test case... was (Author: aanno): Well, barcode4j still depends on avalon. Hence, if you want to use, you had to include avalon api and impl in the classpath as well. Perhaps you can provide the test fop xml (with an barcode included) so that I've get a test case... > [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 >Assignee: simon steiner >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)
[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=16740765#comment-16740765 ] Thomas Pasch edited comment on FOP-2733 at 1/11/19 8:46 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 packages would be preserved. And for more fun `FopFactoryBuilder.setConfiguration` isn't in trunk any more. 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 packages 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)
[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=16740765#comment-16740765 ] Thomas Pasch edited comment on FOP-2733 at 1/11/19 8:43 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 packages 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)
[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=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)
[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=16262539#comment-16262539 ] simon steiner edited comment on FOP-2733 at 11/22/17 1:55 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 was (Author: ssteiner1): 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. > [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 > 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)
