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

2019-01-16 Thread Thomas Pasch (JIRA)


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

Thomas Pasch commented on FOP-2733:
---

I opened [https://sourceforge.net/p/barcode4j/feature-requests/17/] 

But for me, it looks like that barcode4j is a dead project since somewhere in 
2012...

> [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] [Commented] (FOP-2733) [PATCH] Drop dependency on Avalon-Framework

2019-01-16 Thread simon steiner (JIRA)


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

simon steiner commented on FOP-2733:


There is

https://sourceforge.net/p/barcode4j/feature-requests/

> [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] [Commented] (FOP-2733) [PATCH] Drop dependency on Avalon-Framework

2019-01-16 Thread simon steiner (JIRA)


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

simon steiner commented on FOP-2733:


I made fixes for your PR on 
[http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_Avalon/]
[https://lists.apache.org/thread.html/874756880933d6d95dfca2f3f6ca6bb8da7d310a077ca57634042d1e@%3Cfop-dev.xmlgraphics.apache.org%3E]

 

> [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)


Re: [jira] [Commented] (FOP-2733) [PATCH] Drop dependency on Avalon-Framework

2019-01-16 Thread Syed Shahul
unsubscribe, please.

*Thanks & Regards,*
Syed Shahul

Please consider your environmental responsibility. Before printing this
e-mail message, ask yourself whether you really need a hard copy.


On Wed, Jan 16, 2019 at 12:09 PM Thomas Pasch (JIRA) 
wrote:

>
> [
> https://issues.apache.org/jira/browse/FOP-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743878#comment-16743878
> ]
>
> Thomas Pasch commented on FOP-2733:
> ---
>
> 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] [Commented] (FOP-2733) [PATCH] Drop dependency on Avalon-Framework

2019-01-16 Thread Thomas Pasch (JIRA)


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

Thomas Pasch commented on FOP-2733:
---

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] [Commented] (FOP-2733) [PATCH] Drop dependency on Avalon-Framework

2019-01-16 Thread Thomas Pasch (JIRA)


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

Thomas Pasch commented on FOP-2733:
---

Because you integrated BATIK-1249 :), I was forced to update my PR once more.

> [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] [Commented] (FOP-2733) [PATCH] Drop dependency on Avalon-Framework

2019-01-16 Thread simon steiner (JIRA)


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

simon steiner commented on FOP-2733:


It doesnt block us closing this ticket but is a limitation to keep in mind, if 
someone wants to be free of avalon.

> [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] [Commented] (FOP-2733) [PATCH] Drop dependency on Avalon-Framework

2019-01-16 Thread Thomas Pasch (JIRA)


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

Thomas Pasch commented on FOP-2733:
---

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] [Commented] (FOP-2733) [PATCH] Drop dependency on Avalon-Framework

2019-01-16 Thread Thomas Pasch (JIRA)


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

Thomas Pasch commented on FOP-2733:
---

On [https://github.com/aanno/db-toolchain] branch 
'feature/barcode-compatibility' I tested the barcode generation with barcode4j 
with com.github.aanno.dbtoolchain.BarcodeExample . 

Using barcode4j is possible without problems (when you include avalon), and I 
attached the pdf result. I guess your complain is invalid.

> [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] [Commented] (FOP-2733) [PATCH] Drop dependency on Avalon-Framework

2019-01-16 Thread Thomas Pasch (JIRA)


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

Thomas Pasch commented on FOP-2733:
---

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] [Commented] (FOP-2733) [PATCH] Drop dependency on Avalon-Framework

2019-01-16 Thread simon steiner (JIRA)


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

simon steiner commented on FOP-2733:


See 
http://barcode4j.sourceforge.net/2.1/fop-ext.html#Using+the+barcode+extension+for+Apache+FOP

> [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] [Commented] (FOP-2733) [PATCH] Drop dependency on Avalon-Framework

2019-01-16 Thread simon steiner (JIRA)


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

simon steiner commented on FOP-2733:


Normally I include barcode4j-fop-ext.jar barcode4j.jar in my classpath so I can 
render FO files which have a barcode inside them, barcode4j depends on avalon 
so fop fails to start.

Code is at

https://svn.code.sf.net/p/barcode4j/svn/trunk/barcode4j

> [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] [Commented] (FOP-2733) [PATCH] Drop dependency on Avalon-Framework

2019-01-15 Thread Thomas Pasch (JIRA)


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

Thomas Pasch commented on FOP-2733:
---

Dear Simon,

could you please be a bit more specific what the problem with barcode4j is? 
What would be my aim if I want to solve the problem?

At first glance, barcode4j seems to be a very aged project using fop-0.20.5 and 
avalon-4.2.0 (and other) as its dependencies. It also targets Java 1.4, and 
there is no official github mirror.

Regards,

aanno

> [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] [Commented] (FOP-2733) [PATCH] Drop dependency on Avalon-Framework

2019-01-15 Thread simon steiner (JIRA)


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

simon steiner commented on FOP-2733:


avalon still needed when barcode4j is used

> [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] [Commented] (FOP-2733) [PATCH] Drop dependency on Avalon-Framework

2019-01-14 Thread simon steiner (JIRA)


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

simon steiner commented on FOP-2733:


Added http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_Avalon/

> [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] [Commented] (FOP-2733) [PATCH] Drop dependency on Avalon-Framework

2019-01-11 Thread Thomas Pasch (JIRA)


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

Thomas Pasch 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.

> [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] [Commented] (FOP-2733) [PATCH] Drop dependency on Avalon-Framework

2019-01-08 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on FOP-2733:
-

GitHub user aanno opened a pull request:

https://github.com/apache/fop/pull/43

FOP-2733: remove avalon

I removed avalon (a project that is dead for over a decade now) from the 
code base. For this to happen, I've written a clean-room (i.e. I didn't looked 
at the avalon code) implementation of the few bits of avalon that are still in 
use by FOP. After that I fixed the tests.

Apart from some minor stuff that is only used for testing, the main thing 
of avalon that was still in use was the Configuration stuff.

I also renamed the packages name of the (now embeded) avalon stuff like 
this:

* `org.apache.avalon.framework.configuration` moved to 
`org.apache.fop.configuration`
* `org.apache.avalon.framework.activity` moved to `org.apache.fop.activity`
* `org.apache.avalon.framework.container`also moved to 
`org.apache.fop.activity`

This rename is completely optional, i.e. if there are concerns against it, 
I will update my change request and keep the original package names.

I would be glad if you could consider my patch for merge into the `trunk` 
branch.

Kind regards,

aanno

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/aanno/fop feature/pr-remove-avalon-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/fop/pull/43.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #43


commit 6ea0e7f79e4f5fd4056c727bd786db53b61b5ffd
Author: Thomas Pasch 
Date:   2019-01-08T18:30:52Z

FOP-2733: remove avalon

commit abf5af144477c7d6975e9ce74d6a8bb0743fb7c7
Author: Thomas Pasch 
Date:   2019-01-08T19:12:59Z

fixes




> [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] [Commented] (FOP-2733) [PATCH] Drop dependency on Avalon-Framework

2018-12-28 Thread Thomas Pasch (JIRA)


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

Thomas Pasch commented on FOP-2733:
---

I'm not sure if this issue is handled appropriate. Avalon is gone for more than 
a _decade_ now. If the configuration stuff of avalon is still needed (I rather 
suspect nobody is using that anyway), the right solution is to copy the bits of 
avalon still used right into the project.

> [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] [Commented] (FOP-2733) [PATCH] Drop dependency on Avalon-Framework

2018-11-30 Thread Vikram Sherigar (JIRA)


[ 
https://issues.apache.org/jira/browse/FOP-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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?

> [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] [Commented] (FOP-2733) [PATCH] Drop dependency on Avalon-Framework

2017-11-22 Thread Glenn Adams (JIRA)

[ 
https://issues.apache.org/jira/browse/FOP-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.

> [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)


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

2017-11-22 Thread simon steiner (JIRA)

[ 
https://issues.apache.org/jira/browse/FOP-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.

> [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)


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

2017-11-22 Thread Sibin Paul (JIRA)

[ 
https://issues.apache.org/jira/browse/FOP-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.

> [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)


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

2017-08-21 Thread simon steiner (JIRA)

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

simon steiner commented on FOP-2733:


Added part of the changes 
http://svn.apache.org/viewvc?view=revision=1805622

> [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)