1. I am curious what functions are exposed. It makes sense to me that the user topologies (hence the artifact) don't need to know the ApiServer. I am wondering if there are some convenience functions for tools that users may build.
2. I think I have touched the api-java before. I don't remember the reasons, but I agree with you that it could be cleaner just to include both low level and functional APIs. On Wed, Jan 26, 2022 at 12: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? > > 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? > > Does anyone with context for these rules have input on these two questions? >
