Reduce complexity in dependencies setup#15169
Merged
Conversation
🚨 TestLens detected 36 failed tests 🚨Here is what you can do:
Test Summary
🏷️ Commit: 4cd72a8 Test Failures (first 5 of 36)ArXivFetcherTest > findFullTextByTitleWithCurlyBracket() (:jablib:fetcherTest in Fetcher Tests / Fetcher tests)
ArXivFetcherTest > searchEntryByPartOfTitleWithAcuteAccent() (:jablib:fetcherTest in Fetcher Tests / Fetcher tests)
ArXivFetcherTest > supportsPhraseSearch() (:jablib:fetcherTest in Fetcher Tests / Fetcher tests)CompositeIdFetcherTest > performSearchByIdReturnsCorrectEntryForIdentifier(String, BibEntry, String) > 1 "performSearchByIdReturnsCorrectEntryForArXivId" (:jablib:fetcherTest in Fetcher Tests / Fetcher tests)
CrawlerTest > whetherAllFilesAreCreated() (:jablib:fetcherTest in Fetcher Tests / Fetcher tests)
Muted TestsSelect tests to mute in this pull request:
Reuse successful test results:
Click the checkbox to trigger a rerun:
Learn more about TestLens at testlens.app. |
Member
|
Need an AI which immediatly says to me, why JabRef needs a kotlin stdlib :) |
...and with that the need to require 'kotlin.stdlib'
This is not automatically wired by the GradleX plugins that interact here.
Collaborator
Author
jjohannes
force-pushed
the
reduce-complexity-in-dependencies-setup
branch
from
bfc3604 to
987b080
Compare
jjohannes
force-pushed
the
reduce-complexity-in-dependencies-setup
branch
from
987b080 to
8898165
Compare
...plus some general build file cleanup
jjohannes
commented
Feb 20, 2026
| configurations.named("${name}RuntimeClasspath") { | ||
| shouldResolveConsistentlyWith(mainRuntimeClasspath) | ||
| attributes.attributeProvider(TargetJvmVersion.TARGET_JVM_VERSION_ATTRIBUTE, jdkVersion) | ||
| } |
Collaborator
Author
There was a problem hiding this comment.
Learned something here and created follow ups to make this more concise in the future:
jjohannes
commented
Feb 20, 2026
| add("org.openjfx:jdk-jsobject") | ||
| } else { | ||
| removeIf { it.name == "jdk-jsobject" } | ||
| } |
Collaborator
Author
There was a problem hiding this comment.
This is solving the jsobject "issue" in a way @koppor and I talked about when this came up on slack. In theory, JavaFx could publish metadata that allows Gradle to automatically make a better decission.
This rule class is adding this metadata, which allows us to remove the copy-paste solution from individual build Gradle files.
Collaborator
Author
|
This worked better than I thought. 😅 Feel free to take a look at this and test whenever you have time. I propose to add the dependency check to the pipeline, but you can also revert that part if you do not want that (yet). Now, if code is modified, the check will tell if:
To add a new dependency in a module:
|
Contributor
Review Summary by QodoActivate full java-module-dependencies plugin and consolidate dependency definitions
WalkthroughsDescription• Activate java-module-dependencies plugin to define dependencies in module-info.java • Remove redundant dependencies blocks from build.gradle.kts files • Mark runtime-only dependencies with /*runtime*/ comments in module declarations • Add dependency analysis CI pipeline step to validate module-info consistency • Refactor test module configurations using testModuleInfo DSL • Handle platform-specific JavaFX variants and JDK version-specific dependencies Diagramflowchart LR
A["module-info.java files"] -->|define all dependencies| B["java-module-dependencies plugin"]
B -->|validates consistency| C["dependency-analysis plugin"]
C -->|reports unused/missing| D["checkAllModuleInfo task"]
E["build.gradle.kts files"] -->|remove redundant blocks| F["cleaner build config"]
G["Runtime-only deps"] -->|marked with comments| A
H["Platform-specific variants"] -->|handled by metadata rules| B
File Changes1. jabgui/src/main/java/module-info.java
|
Contributor
Code Review by Qodo
1. Commented-out Lucene directives
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
Comment on lines
+166
to
+170
| // uses org.apache.lucene.codecs.lucene103.Lucene103Codec; | ||
| // requires org.apache.lucene.analysis.common; | ||
| // requires org.apache.lucene.core; | ||
| // requires org.apache.lucene.highlighter; | ||
| // requires org.apache.lucene.queryparser; |
Contributor
There was a problem hiding this comment.
1. Commented-out lucene directives 📘 Rule violation ✓ Correctness
The PR introduces commented-out uses/requires lines in module-info.java, leaving dead code in place. This reduces readability and can cause confusion about which modules are actually required.
Agent Prompt
## Issue description
Commented-out `uses`/`requires` directives were introduced in `module-info.java`, which violates the rule against commented-out code.
## Issue Context
These directives appear in the Lucene region and were previously active module declarations.
## Fix Focus Areas
- jabgui/src/main/java/module-info.java[166-170]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Collaborator
Author
There was a problem hiding this comment.
This is a bit unclear to me. I could not find where this is needed. But maybe it cannot be completely removed (?)
If it is really not needed, we can remove this completely (and not comment it out).
Contributor
There was a problem hiding this comment.
Ask❓
This is a bit unclear to me. I could not find where this is needed. But maybe it cannot be completely removed (?) If it is really not needed, we can remove this completely (and not comment it out).
Answer:
In jabgui/src/main/java/module-info.java the Lucene directives were commented out because, after enabling checkAllModuleInfo / java-module-dependencies, the analysis apparently concluded that jabgui does not directly reference Lucene types anymore (or at least not in a way the module system sees), so the directives became “unused” from the perspective of that module.
Where Lucene is needed now is primarily jablib:
jablib/src/main/java/module-info.javastill has the Lucene block, including theuses org.apache.lucene.codecs.lucene103.Lucene103Codec;and therequires ...for the Lucene modules (with some switched totransitive).- That means consumers that need Lucene “through” jablib should get the right modules via jablib’s declarations (especially where
transitiveis used).
So to your question: yes, if jabgui truly doesn’t use Lucene directly, you can remove these lines completely. Keeping them commented out is just dead code and does not help the build; it only preserves a “hint” to humans, but it makes the module descriptor less clear.
Suggested cleanup options:
- Best: remove the entire commented-out block in the Lucene region from
jabgui/module-info.java. - If you want to retain the rationale, keep a short explanatory comment only, e.g.:
// Lucene is provided via jablib; jabgui does not depend on it directly.
One thing to double-check before deleting:
- Ensure
jabguidoes not import anyorg.apache.lucene.*classes directly (IDE “Find in module”). - If it does (e.g., a UI class directly uses a QueryParser or Analyzer), then the correct fix is not commented-out lines, but re-adding the required Lucene modules in jabgui (or making the relevant Lucene requirements
transitivein jablib if the types “leak” through exported APIs).
Given the diff as-is, there’s no indication that Lucene is “special runtime-only” for jabgui; it looks simply unused there, so removing it entirely should be safe and clearer.
jjohannes
commented
Feb 20, 2026
| api("org.glassfish.jersey.core:jersey-server") | ||
| api("org.glassfish.jersey.inject:jersey-hk2") | ||
| api("org.glassfish.jersey.test-framework:jersey-test-framework-core") | ||
| api("org.glassfish.jersey.test-framework.providers:jersey-test-framework-provider-grizzly2") |
Collaborator
Author
There was a problem hiding this comment.
This is generally not correct most of the time. If you add a dependency to a module (a JAR) here - i.e. a dependency without platform(...) – it means the dependency is used on all module paths. This is usually never what you want. For example, before this change the test dependencies listed here were also part of the runtime module path to package JabRef and likely ended up in the application package.
This file should only be used for versions. Only because a BOM is not a version on it's own, but metadata that contains versions, we have the dependencies {} block. But as a BOM does not contain a Jar (it's only metadata) it is correct to use the dependencies {} block only for BOM (platform) dependencies here.
The name is taken from module-info by default (by java-module-dependencies plugin that parses the file).
Member
|
CI is green - so let's get this in - and hope that JabGui is still usable 🤣 |
Siedlerchr
added a commit
that referenced
this pull request
Feb 22, 2026
…anner * upstream/tryToFixBanner: (194 commits) Enable loading of main.wxs Fix icon on Linux (#15188) chore(deps): update dependency org.apache.maven.plugins:maven-surefire-plugin to v3.5.5 (#15178) New Crowdin updates (#15173) Reduce complexity in dependencies setup (#15169) Start new development cycle snapcraft snapcraft use snapctl update metadata fiels try with mesa candidate fix snapcraft and skmanrc to use correct version Release v6.0-alpha.5 chore(sbom): update CycloneDX SBOM files (#15172) Chore(deps): Bump jablib/src/main/resources/csl-styles (#15171) Added "DOI" and URL to entry preview [#14193] (#15121) Fix condition to check running CI in workflow Add maintainer permission check to workflow Add debug output for running checks Fix matrix ...
Member
|
This broke jabref gui starting
|
Siedlerchr
added a commit
that referenced
this pull request
Feb 22, 2026
This reverts commit 10196d5.
Siedlerchr
added a commit
that referenced
this pull request
Feb 22, 2026
Member
|
I revered this for now |
2 tasks
Siedlerchr
added a commit
to LoayTarek5/jabref
that referenced
this pull request
Feb 23, 2026
…les-wizard-12709 * upstream/main: (106 commits) Merge common gating parts into composite action (JabRef#15197) Support protected institutional authors in PersonNamesChecker (JabRef#15175) adapt wix (JabRef#14969) Improve CI (JabRef#15189) Revert "Reduce complexity in dependencies setup (JabRef#15169)" (JabRef#15191) Fix compilation Fix heylogs test Fix icon on Linux (JabRef#15188) chore(deps): update dependency org.apache.maven.plugins:maven-surefire-plugin to v3.5.5 (JabRef#15178) New Crowdin updates (JabRef#15173) Reduce complexity in dependencies setup (JabRef#15169) Start new development cycle snapcraft snapcraft use snapctl update metadata fiels try with mesa candidate fix snapcraft and skmanrc to use correct version Release v6.0-alpha.5 chore(sbom): update CycloneDX SBOM files (JabRef#15172) ...
RakockiW
pushed a commit
to RakockiW/jabref
that referenced
this pull request
Mar 1, 2026
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
3 participants
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.
Related issues and pull requests
PR Description
As follow up to earlier updates on dependency management in the JabRef repo, with the goal to remove as much unnecessary complexity as possible from the dependencies setup. For that, this PR activates the full capabilities of the java-module-dependencies plugin, which is:
module-info.javafiles, effectively removing the redundantdependencies {}blocks frombuild.gradle.ktsfilescheckAllModuleInfoto check if the declarations in amodule-info.javafile are consistent with what is used (or not used) in the source code of the corresponding module.The PR removes or updates declarations depending on the advice
checkAllModuleInfogives.Steps to test
After this change, everything should build like before, but the module paths should be reduced to what is actually needed.
There is a risk that this accidentally removes a needed runtime only dependency that is not covered by tests (I'll try to be thorough). The
checkAllModuleInfotask can not know all things that are dynamically loaded at runtime. So some manual testing before integrating this would be good.Checklist
CHANGELOG.mdin a way that can be understood by the average user (if change is visible to the user)