Both of which get packaged under org.partiql.lang.ast.
This fails the build when a customer enables compile time validation for duplicated class in the classpath.
This PR removes the StaticTypeMeta in the lang package as a short term fix for the issue.
We anticipate issue of similar pattern will not occurs once we complete the split of packages, but it is still worthy for us to consider adding a check for similar issue in the future. Unfortunately, a cursor search does not reveal a good gradle-plugin for this purposes, hence this PR does not include such check.
Note that the issue only happens when a compile time check as described is included in the build process, this is because the two classes are identical and at runtime, it does not matter which class gets loaded...
Also, worth to call out that this PR should not be considered backward-incompatible:
This is: one can access the StaticTypeMeta is only taking dependency from partiql-ast package, and one can still access StaticTypeMeta when takiing dependency from partiql-lang package. The APIs are exposed because partiql-ast is a dependency of partiql-lang.
Other Information
Updated Unreleased Section in CHANGELOG: [YES/NO]
No.
Any backward-incompatible changes? [YES/NO]
< If YES, why? >
< For this purpose, we define backward-incompatible changes as changes that—when consumed—can potentially result in
errors for users that are using our public APIs or the entities that have public visibility in our code-base. >
No.
Any new external dependencies? [YES/NO]
< If YES, which ones and why? >
< In addition, please also mention any other alternatives you've considered and the reason they've been discarded >
No.
Relevant Issues
Description
Previously, the class
StaticTypeMetais duplicated the ast package and in the lang package.Both of which get packaged under
org.partiql.lang.ast.This fails the build when a customer enables compile time validation for duplicated class in the classpath.
This PR removes the
StaticTypeMetain the lang package as a short term fix for the issue.We anticipate issue of similar pattern will not occurs once we complete the split of packages, but it is still worthy for us to consider adding a check for similar issue in the future. Unfortunately, a cursor search does not reveal a good gradle-plugin for this purposes, hence this PR does not include such check.
Note that the issue only happens when a compile time check as described is included in the build process, this is because the two classes are identical and at runtime, it does not matter which class gets loaded...
Also, worth to call out that this PR should not be considered backward-incompatible: This is: one can access the
StaticTypeMetais only taking dependency frompartiql-astpackage, and one can still accessStaticTypeMetawhen takiing dependency frompartiql-langpackage. The APIs are exposed becausepartiql-astis a dependency ofpartiql-lang.Other Information
Updated Unreleased Section in CHANGELOG: [YES/NO]
Any backward-incompatible changes? [YES/NO]
publicvisibility in our code-base. > No.Any new external dependencies? [YES/NO]
Do your changes comply with the Contributing Guidelines and Code Style Guidelines? [YES/NO] Yes.
License Information
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.