Generated project pom.xmls should declare more explicit dependencies
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 243
- Forks
- 171
- Avg merge
- 30m
- Merged PRs (30d)
- 4
Description
(Minor issue; didn't want it to get lost.)
Most of the subprojects in the OCI SDK look to me like they're generated. If so, whatever template it is that makes their pom.xmls should be updated to also include the following explicit dependencies. Here I've also assumed that relevant ones are managed in the root pom.xml's <dependencyManagement> section (which PR #388 implements if I remember right):
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</dependency>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.connectors</groupId>
<artifactId>jersey-apache-connector</artifactId>
</dependency>
<dependency>
<groupId>com.oracle.oci.sdk</groupId>
<artifactId>oci-java-sdk-circuitbreaker</artifactId>
<version>${project.version}</version>
</dependency>
Here is an arbitrary place where bmc-circuitbreaker classes are used explicitly:
Here is an arbitrary place where Jackson classes are used explicitly:
Here is an arbitrary place where Guava is used explicitly (which could easily be replaced by Java 8 constructs):
Here is an arbitrary place where Jersey Apache connector stuff is used explicitly:
It's good Maven practice to add an explicit dependency on the containing artifact when you import some class. It makes it clearer to a customer what exactly is being used directly by the project.
I see in the root pom.xml that a few dependencies get inherited by all projects (lombok, slf4j and jakarta.ws.rs-api). It would be better, too, if these were explicitly placed in every pom.xml. Ordinarily this wouldn't be at all worth it because of the sheer number of subprojects, but if they're all generated anyway it strikes me that it shouldn't be a big deal.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the root pom.xml, especially its dependencyManagement section, then locate the template or generator responsible for the subproject pom.xml files. Compare generated poms with the dependencies and inherited entries listed in the issue, and verify the resulting Maven projects declare their direct dependencies explicitly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- build-system
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100