Publish BOM

[abelsromero]

Just dropping idea here, would it make sense to publish a BOM with related jRuby and related projects?
Aligning jRuby is an issue in other projects like AsciidoctorJ or the maven-examples because there's no way for contributors to know if jRuby is not in not the latest for some reason, or for automatic tools like dependabot to avoid unnecessary PRs.

We get something for free for Gradle with the module descriptor, but not for Maven infrastructure.
Optionally, we could also include related projects (asciidoctorj-pdf, asciidoctorj-diagram,... ) so users know which are the official supported versions and make configuration easier.

[robertpanzer]

That sounds like a good idea.
That opens the question of how we would version that. Do you already have an idea how that would look like?

[abelsromero]

That sounds like a good idea.

There are pros and cons, not sure myself:thinking:

Do you already have an idea how that would look like?

Thinking it through it should be a thing on its own if we add pdf, diagram, etc. in the BOM. It should be a project with integration tests that ensure the combinations are supported, and given each component has different lifecycles the BOM should not be tied to Asciidoctorj version. But that requires a lot of work for a feature no one seems to require.

The idea to me comes from the struggles to keep jRuby aligned with the provided version in AsciidoctorJ which requires manual validation. But having jRuby dependency explicitly comes from the past, where we found that certain issues were fixed with specific versions of JRuby and AsciidoctorJ run on older jRuby versions. So having it explicit made sense to run on newer version to fix issues with pdf for example.
But this hasn't been the case lately, AsciidoctorJ runs on pretty recent jRuby versions and I can't remember the last time we suggested using a different jRuby to a user.
Maybe it's time to change it and just import AsciidoctorJ?