Skip to content
This repository was archived by the owner on Nov 11, 2022. It is now read-only.

Conversation

@swegner
Copy link
Contributor

@swegner swegner commented Apr 25, 2016

No description provided.

swegner added 8 commits April 25, 2016 08:52
 * Add boolean-valued display data.
 * Implement equality for DislpayData.Item
 * Add ability to override namespace for included subcomponents.
 * Additional Matchers for testing display data
 * Update DisplayData inner class privacy

(cherry picked from commit 014a9a5)
- Support overriding namespace when adding display data
- Support inferring display data type during registration
- Add APIs to conditionally register display data if not null/default.
- Move additional matchers into DisplayDataMatchers

(cherry picked from commit 5da2292)
- Add additional overloads for conditionally registering null display data
- Serialize DisplayData using JSON primatives
- Fix checkstyle error
- Bind generic type parameter in DataflowPipelineTranslator#addDisplayData
- Add additional tests for new APIs
- Improve readability of DisplayDataTest#populateDisplayData

(cherry picked from commit dba82fe)
Expose NeverTrigger as package-private since it is necessary for display
data

(cherry picked from commit 450dd85)
(cherry picked from commit 77a77c9)
If more than one combineFn have the same namespace, add a sequential suffix.
This is necessary because each namespace/key pair must be unique within
the transform.

Add a `JavaClass` wrapper around a name/simple-name for a class. This is
necessary in cases where the class may be serialized to support
accessing `DisplayData` since `Class` is not serializable in some cases.

(cherry picked from commit b0baa4c)
@swegner
Copy link
Contributor Author

swegner commented Apr 25, 2016

R: @bjchambers


package com.google.cloud.dataflow.sdk.options;

import com.google.api.client.repackaged.com.google.common.base.Objects;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should not depend on repackaged versions of dependencies.

@bjchambers
Copy link
Contributor

Are there any possibly surprising changes here beyond just cherry-picking and fixing up packaging? I made a quick scan and everything seems sensible, want to make sure there isn't anything that merits further scrutiny.

@swegner
Copy link
Contributor Author

swegner commented Apr 25, 2016

Nope, the process was the cherry-pick each change and fix all the imports (added imports have org.apache.beam.* prefix). I'll take a pass to look for any other repackaged imports.

@swegner
Copy link
Contributor Author

swegner commented Apr 25, 2016

I didn't come across any other bad imports. Please take another look: @bjchambers

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants