Skip to content

VFS-859: Fix undeclared direct dependencies #680

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ppkarwasz
Copy link

Undeclared direct dependencies that are also transitive dependencies of an optional direct dependency, end up being declared by Moditect using requires <module> instead of requires static <module>.

This causes JPMS runtime errors, unless the optional dependency is present on the module path.

To solve this and rationalize the dependency tree, this change:

  • Adds two verification rules that check for undeclared dependencies and useless exclusions.
  • Adds undeclared dependencies to the POM files.
  • Remove unused declared dependencies.

Undeclared direct dependencies that are also transitive dependencies of an **optional** direct dependency, end up being declared by Moditect using `requires <module>` instead of `requires static <module>`.

This causes JPMS runtime errors, unless the optional dependency is present on the module path.

To solve this and rationalize the dependency tree, this change:

- Adds two verification rules that check for undeclared dependencies and useless exclusions.
- Adds undeclared dependencies to the POM files.
- Remove unused declared dependencies.
@ppkarwasz
Copy link
Author

Related to moditect/moditect#259

@garydgregory
Copy link
Member

Hi @ppkarwasz

Thank you for your help :-)

Some Java 8 and 11 builds fail with java.lang.ClassNotFoundException: javax.jcr.Binary

@ppkarwasz
Copy link
Author

Some Java 8 and 11 builds fail with java.lang.ClassNotFoundException: javax.jcr.Binary

I am fighting with jackrabbit-standalone, which is a shaded artifact with some strange versions of commons-logging and slf4j-api.

Should we still keep the provider for JackRabbit 1.x? The last release is almost 10 years old.

@garydgregory
Copy link
Member

Some Java 8 and 11 builds fail with java.lang.ClassNotFoundException: javax.jcr.Binary

I am fighting with jackrabbit-standalone, which is a shaded artifact with some strange versions of commons-logging and slf4j-api.

Should we still keep the provider for JackRabbit 1.x? The last release is almost 10 years old.

We can drop it for 3.0 IMO but I think we should do our best to keep it in 2.x since it just works.

Maybe there are non-uber jar JR artifacts we can depend on instead?

@ppkarwasz
Copy link
Author

Maybe there are non-uber jar JR artifacts we can depend on instead?

I'll try with jackrabbit-webapp

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants