Discussion:
[jira] [Created] (FOP-2733) Drop dependency on Avalon-Framework
(too old to reply)
Chris West (JIRA)
2017-08-21 10:14:00 UTC
Permalink
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)
simon steiner (JIRA)
2017-08-21 10:32:02 UTC
Permalink
[ https://issues.apache.org/jira/browse/FOP-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

simon steiner updated FOP-2733:
-------------------------------
Summary: [PATCH] Drop dependency on Avalon-Framework (was: Drop dependency on Avalon-Framework)
[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.
* 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)
simon steiner (JIRA)
2017-08-21 11:54:00 UTC
Permalink
[ https://issues.apache.org/jira/browse/FOP-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16135073#comment-16135073 ]

simon steiner commented on FOP-2733:
------------------------------------

Added part of the changes http://svn.apache.org/viewvc?view=revision&revision=1805622
Post by simon steiner (JIRA)
[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.
* 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)
Sibin Paul (JIRA)
2017-11-22 13:26:00 UTC
Permalink
[ https://issues.apache.org/jira/browse/FOP-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16262509#comment-16262509 ]

Sibin Paul commented on FOP-2733:
---------------------------------

Hi,

Is there any update on this issue?
Our organizations compliance team has raised concern regarding the usage of apache FOP in one of our product. Their concern is with the usage of avalon framework as it is a closed project.
Any help would be appreciated.

Paul.
Post by simon steiner (JIRA)
[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.
* 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)
simon steiner (JIRA)
2017-11-22 13:56:00 UTC
Permalink
[ https://issues.apache.org/jira/browse/FOP-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16262539#comment-16262539 ]

simon steiner commented on FOP-2733:
------------------------------------

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.
Post by simon steiner (JIRA)
[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.
* 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)
simon steiner (JIRA)
2017-11-22 13:56:00 UTC
Permalink
[ https://issues.apache.org/jira/browse/FOP-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
Post by simon steiner (JIRA)
[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.
* 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)
Glenn Adams (JIRA)
2017-11-22 14:28:00 UTC
Permalink
[ https://issues.apache.org/jira/browse/FOP-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16262596#comment-16262596 ]

Glenn Adams commented on FOP-2733:
----------------------------------

In other words, the earliest we could apply this patch is when moving to the next major version, FOP 3.0, which is not under consideration at all at this juncture.
Post by simon steiner (JIRA)
[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.
* 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)
Vikram Sherigar (JIRA)
2018-11-30 16:39:00 UTC
Permalink
[ https://issues.apache.org/jira/browse/FOP-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16705001#comment-16705001 ]

Vikram Sherigar commented on FOP-2733:
--------------------------------------

Any plans of Apache FOP v3.0 yet? Or resolution to this issue in a minor release maybe?
Post by simon steiner (JIRA)
[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.
* 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)

Loading...