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

Distribution JARs must be uniquely identified by their Maven coordinates #184

Open
lolski opened this issue Jun 5, 2022 · 1 comment
Open

Comments

@lolski
Copy link
Member

lolski commented Jun 5, 2022

Some JARs in the distribution are not uniquely identified by Maven coordinates. It may cause one JAR to be overwritten by another, if they happen to have the same name.

Consider the following example: Suppose Console depends on @vaticle_typedb_client_java//common and @vaticle_typedb_common//common. When bazel build is invoked bazel-bin/external/vaticle_typedb_client_java/common/libcommon.jar and bazel-bin/external/vaticle_typedb_common/common/libcommon.jar will be generated, respectively. During the assembly process, both JARs will be placed within the lib directory and given that both JARs have identical names, one will overwrite the other.

Therefore, we must ensure that all JARs are uniquely identified by assigning Maven coordinates to each of them.

@lolski
Copy link
Member Author

lolski commented Jun 5, 2022

However, some Bazel targets are intentionally not given Maven coordinates if they are meant to be compiled upwards into a single top-level Bazel target as a single fat JAR.

Client Java, for instance, uses this fat JAR approach in order to make it easy for our users to include it as a dependency in their program, ie., they only need to declare one dependency instead of multiple in their pom.xml.

My proposal is to only depend on JARs that have Maven coordinates. In this case, Console should depend on Client Java's fat JAR produced by assemble_maven.

@lolski lolski self-assigned this Jun 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant