Perhaps the intent was that :beam-sdks-java-core:buildDependents would
launch this. In any case, explicit > implicit. But we do depend on this to
avoid making changes to the Java SDK that would break other parts of the
project. If non-default Test configurations are not running, I worry about
Now that we are using Gradle, we can do what Robert suggests. With Maven it
created a (false) cyclic dependency. It could still be a little bit
confusing, but not too much.
The only modules that should currently use NeedsRunner are those that would
create such a cycle. These are sdks/java/core
Thanks Scott, I just tested and the errors I found are fixed and
everything seems to work now. Snapshots are being correctly updated
too.
On Wed, Jan 2, 2019 at 6:19 PM Scott Wegner wrote:
>
> Yes, I believe this will be fixed with the vendoring release.
>
> I am back from the holidays now and
Can you please create 2.11 tag in JIRA so we can move the JIRAs that
are not blocking. I have quite a bunch of pending code reviews that
hoped to get into this one but well now probably they shall wait. (My
excuses for the people who may be impacted, I had not checked that the
date was in the
My apologies. I got the terminology entirely wrong.
As you say, PubsubIO and other Beam components _do_ use the official Google
API client library (google-api-client). They do not, however, use the
higher-level Google Cloud libraries such as google-cloud-pubsub which
provide abstractions on top
I don't have enough context to answer all of the questions, but looking at
PubsubIO it seems to use the official libraries, e.g. see Pubsub doc [1]
vs Pubsub IO GRPC client [2]. Correct me if I misunderstood your question.
[1]
Thanks all for voting. The vote has passed with 7 +1 votes (6 binding) and
no -1 votes. I'll complete the remaining work and finalize the release.
On Wed, Jan 2, 2019 at 9:03 AM Ismaël Mejía wrote:
> Is this vote already closed and the artifacts published?
>
> On Fri, Dec 21, 2018 at 6:03 PM
Yes, I believe this will be fixed with the vendoring release.
I am back from the holidays now and ready to pick this up.
On Thu, Dec 27, 2018 at 10:56 AM Ismaël Mejía wrote:
> Thanks Andrew for the info.
> I think things can wait a bit considering the time of the year, I just
> wanted to raise
Is this vote already closed and the artifacts published?
On Fri, Dec 21, 2018 at 6:03 PM Connell O'Callaghan wrote:
>
> +1
>
> On Fri, Dec 21, 2018 at 9:02 AM Thomas Weise wrote:
>>
>> +1
>>
>>
>> On Fri, Dec 21, 2018 at 5:00 AM Robert Bradshaw wrote:
>>>
>>> +1, let's get this out.
>>>
>>> We
I'm building a high-volume Beam pipeline using PubsubIO and running into
some concerns over performance and delivery semantics, prompting me to want
to better understand the implementation. Reading through the library,
PubsubIO appears to be a completely separate implementation of Pubsub
client
It sounds good to me.
Regards
JB
On 02/01/2019 16:16, Kenneth Knowles wrote:
> Hi All,
>
> According to the release calendar [1] branch cut date for
> Beam 2.10.0 release is today, 2019 January 2. I'd like to volunteer to
> manage this release. Does anyone have any reason we should not release
Hi All,
According to the release calendar [1] branch cut date for Beam 2.10.0
release is today, 2019 January 2. I'd like to volunteer to manage this
release. Does anyone have any reason we should not release on schedule?
Otherwise, if you know of release-blocking bugs, please mark their "Fix
12 matches
Mail list logo
