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.