Multiple Rescomp extentions with Service Loader#465
Closed
TheRoboZ wants to merge 2 commits into
Closed
Conversation
Contributor
|
@Stephane-D , what do you think about this? Describe what solution you think would be better - use a more abstract and complex one with ServiceLoader, or would it be better to make simple scans for all jar files. Or perhaps you would like to see some other improvements? I talked to @TheRoboZ and he doesn’t mind if someone finalizes this pull-request, I think I can try to do that. |
Owner
Contributor
|
@Stephane-D Got it! |
werton
added a commit
to werton/SGDK
that referenced
this pull request
Apr 3, 2026
ResComp: added support for multiple extensions. The implementation is based on TheRoboZ folders scan implementation Stephane-D#465 (implementation based on ServiceLoader was removed). ResComp version bumped to 4.0, rescomp.jar has been updated. Using: the name of the JAR extension file must be in the following format: '[your_extension_name]_ext.jar' (i.e. the file name must end with '_ext.jar').
Stephane-D
pushed a commit
that referenced
this pull request
Apr 12, 2026
ResComp: added support for multiple extensions. The implementation is based on TheRoboZ folders scan implementation #465 (implementation based on ServiceLoader was removed). ResComp version bumped to 4.0, rescomp.jar has been updated. Using: the name of the JAR extension file must be in the following format: '[your_extension_name]_ext.jar' (i.e. the file name must end with '_ext.jar').
Contributor
Author
|
Implemented by #479 |
TheRoboZ
pushed a commit
to TheRoboZ/SGDK
that referenced
this pull request
Apr 23, 2026
…) (Stephane-D#479) ResComp: added support for multiple extensions. The implementation is based on TheRoboZ folders scan implementation Stephane-D#465 (implementation based on ServiceLoader was removed). ResComp version bumped to 4.0, rescomp.jar has been updated. Using: the name of the JAR extension file must be in the following format: '[your_extension_name]_ext.jar' (i.e. the file name must end with '_ext.jar').
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reissue this with some cleanup.
This is a proposal on implementing advanced support for multiple rescomp extensions, through separate .jar files.
It uses Service Loader (which requires the wrapper class and other changes to avoid class isolation errors at runtime).
On the user side, each extension jar only need 1 additional manifest file (1 line) before compiling.
The implementation skips processor with missing manifests, duplicate processor etc.
I left it quite verbose to make clear what's happening.
If there's a rescomp_ext.jar file, it will default to legacy loading and only use that.
If the service loader is too much, i also left commented a multiple jar folder scan with legacy loading.
While in my tests it all worked well in various cases, this is more a starting point for you to decide how to go on with this.