[
https://issues.apache.org/jira/browse/FINERACT-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102499#comment-17102499
]
Michael Vorburger commented on FINERACT-938:
--------------------------------------------
I see:
{noformat}$ ./gradlew dependencies
(...)
+--- com.mockrunner:mockrunner-jms -> 2.0.4
| \--- com.mockrunner:mockrunner-core:2.0.4
| +--- jdom:jdom:1.0
| +--- oro:oro:2.0.8
| +--- com.kirkk:jaranalyzer:1.2
| | +--- bcel:bcel:5.1
| | +--- jakarta-regexp:jakarta-regexp:1.4
| | \--- ant:ant:1.6.5
| \--- nekohtml:nekohtml:0.9.5 -> 1.9.6.2
| \--- xerces:xercesImpl:2.8.1
| \--- xml-apis:xml-apis:1.3.03{noformat}
This IMHO is pretty ugly. I can think of a few choices:
A. force exclude nekohtml (and more.. jaranalyzer?) from the mockrunner-jms. I
bet it will still do enough for what we actually need.
B. what do we actually need mockrunner-jms for? Only in
org.apache.fineract.notification.SenderTest. But... what does that actually
really "test"? Nothing, really, if we are honest, doesn't it? I've raised
https://github.com/apache/fineract/pull/832 proposing to just ditch it! Very
small loss, for a classpath simplification that will avoid trouble in future
library upgrades.
C. use ActiveMQ's testing support, with Spring Boot's ActiveMQ starter? This
may be the way to go if we had any need for serious full JMS integration
testing. But as far as I know, this project does not currently have that need.
> Document (or drop) use of Xerces2 (without requiring NekoHTML)
> --------------------------------------------------------------
>
> Key: FINERACT-938
> URL: https://issues.apache.org/jira/browse/FINERACT-938
> Project: Apache Fineract
> Issue Type: Bug
> Reporter: Michael Vorburger
> Assignee: Michael Vorburger
> Priority: Major
> Fix For: 1.4.0
>
>
> FINERACT-846 added a new dependency to
> [Xerces2|https://xerces.apache.org/xerces2-j/] - but only for scope test.
> While reviewing https://github.com/apache/fineract/pull/820/, I thought that
> was curious (both the fact that it was required at all, and that it only for
> tests), but I didn't want to hold up the merge of that important PR just
> because of that.
> Let us use this issue to either clearly document why we need it (inline in
> build.gradle and dependencies.gradle) - or see if it could perhaps be removed
> again after all?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
