Inlined On Wed, Jan 26, 2022 at 2:34 PM Nicholas Nezis <[email protected]> wrote:
> Could someone give me a second set of eyes here... > > 1. In the `scripts/packages/BUILD` I see the following heron-lib-api > closure: > > https://github.com/apache/incubator-heron/blob/abb2767e3df3ca6eba009f46efe1f1e83695617a/scripts/packages/BUILD#L418-L425 > > Should it have that reference to heron-apiserver? It seems like it should > be the API artifacts, but not the actual server, right? > ## It looks like there is some clinet code in this target, which may be why it is needed: https://github.com/apache/incubator-heron/blob/master/heron/tools/apiserver/src/java/org/apache/heron/apiserver/Runtime.java > 2. It seems we are only adding the `api-java` library, but this seems to > include only the functional (i.e. streamlet) code. There is another option > `api-java-low-level-functional` which includes both APIs. Is this what we > should be including in the package tars? There is also `api-unshaded` which > is a `java_binary` (not `java_library` like the former). Also `api-shaded` > which remaps the google protobuf namespace. > > Link to the referenced closures: > > https://github.com/apache/incubator-heron/blob/abb2767e3df3ca6eba009f46efe1f1e83695617a/heron/api/src/java/BUILD#L23-L81 > > I think I want to include the unshaded artifact which contains both "low > level" and "functional" Java APIs. So I'm leaning towards using > `api-java-low-level-functional` (with the output jar renamed to something > simple). Does this sound ok? > ## It sounds ok, but we also need to make sure that it references the ECO api as well. I remember there was a cyclical linking issue with Bazel, which is why we had to use the "neverlink" option. > > Does anyone with context for these rules have input on these two questions? >
