java-pkg-simple.eclass: Allow compilation of multiple modules in one pkg

[2Kmm]

Auto generate parameter --module-source-path if needed.

Closes: https://bugs.gentoo.org/925691
Closes: https://bugs.gentoo.org/923599
Closes: https://bugs.gentoo.org/923608

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2024-04-18 11:26 UTC
Newest commit scanned: 17bf1d5
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/5c0892be66/output.html

[2Kmm]

I am not exactly sure, how the policy is. Should I revbump the fixed ebuilds?

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2024-04-18 11:49 UTC
Newest commit scanned: 46c9163
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/4236fa44e7/output.html

[gentoo-bot]

Pull Request assignment

Submitter: @2Kmm
Areas affected: ebuilds, eclasses
Packages affected: dev-java/cdi-api, dev-java/jaxb-runtime

dev-java/cdi-api: @gentoo/java
dev-java/jaxb-runtime: @gentoo/java

Linked bugs

Bugs linked: 923608, 925691, 923599

---

In order to force reassignment and/or bug reference scan, please append [please reassign] to the pull request title.

Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide

[vaukai]

I am not exactly sure, how the policy is. Should I revbump the fixed ebuilds?

Sorry, it looks like you've worked on the old approach still producing the "ignoreme.jar" file. Would it also work for the newer approach using JAVADOC_SRC_DIRS like the upcoming byte-buddy?

See the comment in the second commit of master...vaukai:gentoo:javadoc. I did not yet find the time to proceed with those works ...

EDIT:
Back to your question. Think of a user having cdi-api or jaxb-runtime already installed. Your changes on the ebuilds are strongly related to that change on the eclass. For the user, the eclass change will run in immediately on next sync. But there is nothing triggering an update of the packages unless their commits contain a revbump.
In this case, for rbumb is recommended to use like git mv cdi-api-4.0.1-r2.ebuild cdi-api-4.0.1-r3.ebuild.

[2Kmm]

Sorry, it looks like you've worked on the old approach still producing the "ignoreme.jar" file. Would it also work for the newer approach using JAVADOC_SRC_DIRS like the upcoming byte-buddy?

Yes, my work is mostly decoupled from your work. Mainly, it obsoletes the need for a JAVA_MODULE_SOURCE_PATH variable because it auto-generates it. So our changes should work nicely together.

Back to your question. Think of a user having cdi-api or jaxb-runtime already installed. Your changes on the ebuilds are strongly related to that change on the eclass. For the user, the eclass change will run in immediately on next sync. But there is nothing triggering an update of the packages unless their commits contain a revbump.

That is the point why I am asking. For users with USE=-doc, nothing changes, and therefore there is no need to recompile. For users with USE=doc, the ebuilds failed before and therefore should not be installed in the first place. So, a revbump would only trigger an update for those users, that don't need it...