+1 and you have phrased the benefits and limitations well. We have plenty
of not-Google-related dependencies that use Guava and protobuf (I know of
Calcite, Cassandra, Kinesis, and Spark) so there's still work in managing
deps, but the BOM should make it a lot easier to upgrade all these tightly
coupled libraries that Google ships from their head.
Do Spark or Flink have BOMs? I wonder if there's an opportunity to catch
incompatible deps at a larger scale by comparing and merging a half dozen
BOMs (although in the limit it approximately expands to one per runner and
one per IO and projects mature and become independent)
Kenn
On Thu, Mar 5, 2020 at 10:05 AM Luke Cwik <lc...@google.com> wrote:
> How would the Apache Beam BOM and GCP BOM work together?
>
> On Thu, Mar 5, 2020 at 7:25 AM Filipe Regadas <filiperega...@gmail.com>
> wrote:
>
>> Big +1, this is a step in the right direction and checking with other
>> Beam's direct and transitive deps is crucial since the referred bom only
>> convers a small part of it. Apache Commons, Jackson, `com.google.{api,
>> apis, cloud}`, slf4j comes to mind.
>>
>> Filipe Regadas
>>
>>
>> On Thu, Mar 5, 2020 at 3:33 AM Ismaël Mejía <ieme...@gmail.com> wrote:
>>
>>> +1 Sounds like a good improvement for users and maintainers !
>>>
>>> On Thu, Mar 5, 2020 at 6:59 AM Alex Van Boxel <a...@vanboxel.be> wrote:
>>> >
>>> > +1, I can remember the countless hours that we fought with Google
>>> dependencies.
>>> >
>>> > On Thu, Mar 5, 2020, 04:07 Chamikara Jayalath <chamik...@google.com>
>>> wrote:
>>> >>
>>> >> +1 for this.
>>> >>
>>> >> This will make life easy for many of our users and will help us keep
>>> GCP related dependencies compatible (which has not been easy in the past).
>>> >>
>>> >> On Wed, Mar 4, 2020 at 2:16 PM Tomo Suzuki <suzt...@google.com>
>>> wrote:
>>> >>>
>>> >>> Hi Beam developers,
>>> >>>
>>> >>> Shall we use GCP Libraries BOM [1] to specify the Google-related
>>> library versions in Beam?
>>> >>>
>>> >>> I've been working on Beam's dependency upgrades in the past few
>>> months. It's time to consider a long-term solution to keep the libraries
>>> up-to-date with small maintenance effort. To achieve that, I propose Beam
>>> to use GCP Libraries BOM to set the Google-related library versions, rather
>>> than the current way of making changes in each of ~30 Google libraries with
>>> individual PRs [2].
>>> >>>
>>> >>> After the proposal is implemented, Beam project upgrades the BOM
>>> version to upgrade these Google-related libraries. This still needs to
>>> ensure the libraries in GCP Library BOM are compatible with Beam's other
>>> dependencies. (Linkage Checker will help with this job.) I believe
>>> onboarding GCP Libraries BOM will solve lots of incompatibilities which we
>>> have seen in gax, gRPC, google-cloud-core, and so on with minimal effort in
>>> Beam's developers.
>>> >>>
>>> >>> Created an issue to track this: BEAM-9444 [3]. I appreciate if you
>>> can share questions or feedback (thumbs-up / concerns).
>>> >>>
>>> >>> [1]:
>>> https://github.com/GoogleCloudPlatform/cloud-opensource-java/wiki/The-Google-Cloud-Platform-Libraries-BOM
>>> >>> [2]:
>>> https://github.com/apache/beam/pulls?page=1&q=is%3Apr+author%3Asuztomo
>>> >>> [3]: https://issues.apache.org/jira/browse/BEAM-9444
>>> >>>
>>> >>> --
>>> >>> Regards,
>>> >>> Tomo
>>>
>>
