Skip to content
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

Simplify Dependency Resolution #13758

Open
codeconsole opened this issue Oct 16, 2024 · 1 comment
Open

Simplify Dependency Resolution #13758

codeconsole opened this issue Oct 16, 2024 · 1 comment

Comments

@codeconsole
Copy link
Contributor

codeconsole commented Oct 16, 2024

Cleanup in dependency resolution.

We are using excludes in too many locations. excludes, with a few exceptions, should not be necessary. If it is ever used, they should be very specific. For instance, if there is just 2 modules that have a specific dependency that needs to be excluded, the exclusion should only apply to those 2 modules.

Dependencies should not be transitive unless they are needed 100% of the time by the final application.
For instance, if a project uses ehcache, but it is optional and only turned on/off via a configuration option, it should not be transitive.

  1. identify plugins that use @AstTransformer and determine what imports are required for successful compilation.
  2. Use compileOnlyAPI, but only if that dependency is not already transitively resolved compileOnlyAPI by a dependency on an another plugin that it depends on.
  3. Identify all exclusions across the code base and determine why they are needed and what is necessary for their removal.
  4. Use the grails bom when able. Do not specify dependency versions in a plugin unless they are specific to that plugin.

https://docs.gradle.org/current/userguide/java_library_plugin.html

@codeconsole codeconsole moved this to Todo in Grails 7 Oct 16, 2024
@codeconsole
Copy link
Contributor Author

compileOnlyAPI is still not an ideal solution and should be avoided at all costs.
The reason for needing the dependency should be addressed first.

For instance, servlet api references should not be compiled into every controller class

just to reference a constant.

final MethodCallExpression sendErrorMethodCall = new MethodCallExpression(responsePropertyExpression, "sendError", new ConstantExpression(HttpServletResponse.SC_METHOD_NOT_ALLOWED));

Instead, the constant should be added to a separate class and referenced instead.

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

No branches or pull requests

1 participant