We generate https://fineract.apache.org/docs/develop/ with Asciidoctor
from asciidoc sources in
https://github.com/apache/fineract/tree/develop/fineract-doc .
The HTML version of the docs has grown over time, increasing
significantly in size with v1.15.0 and recent builds off develop
(1.16.0-SNAPSHOT).
From the sources for our project website
<https://github.com/apache/fineract-site/>, we find:
*Date* *Path* *Size*
Oct 11, 2025 docs/1.12.1/index.html 1.6M
Oct 13, 2025 docs/1.13.0/index.html 1.9M
Dec 22, 2025 docs/1.14.0/index.html 1.9M
Jul 10, 2026 docs/1.15.0/index.html 2.8M
Aug 31, 2026 docs/1.16.0-SNAPSHOT/index.html 5.6M
https://fineract.apache.org/docs/develop/ still loads OK for me on
desktop and mobile, but I think we should keep an eye on this size trend.
Besides the size, I think it's worth asking if the [new] content is useful.
https://fineract.apache.org/docs/develop/#_per_package_reference stands
out to me... that section alone adds 286 pages to the PDF output (550
pages without, 836 pages with). The section is generated from ./gradlew
architectureMetricsReport, saved in generated-package-overview.adoc, and
included by cross-feature-boundary-violations.adoc. It could instead be
generated on-demand / as-needed.
Thoughts?
And re: generated-package-overview.adoc / "Cross-Feature Boundary
Violations" overall... it looks interesting, but is it something we want
to keep in our docs, read often, refer back to ...? It seems more
appropriate for a blog post, case study, FSIP, or project page
specifically about modularizing Fineract. Side question: Was it
AI-generated? I'm noticing many em-dashes, ~85 character line wrapping
<https://issues.apache.org/jira/browse/FINERACT-2795>, and just the
length of the file itself (1,500 lines).
--
Adam Monsen
Software Engineer » Mifos Initiative
Release Manager » Apache Fineract
Author » Steadfast Self-Hosting
PGP key » 0xA9A14F22F57DA182
