-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
expand JSON test coverage; add datastore and cloud storage #443
Conversation
|
||
@Override | ||
public int hashCode() { | ||
return (groupId + ":" + artifactId + ":" + version).hashCode(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use Objects.hash()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer to avoid dependencies is possible. This seems simple enough and I like the connection with the Gradle dependency ID format.
if (o == null || !(o instanceof MavenCoordinates)) { | ||
return false; | ||
} | ||
MavenCoordinates other = (MavenCoordinates) o; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
equals()
needs to check repository
, classifier
, and type
. Use Object.equals()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did wonder about that. For this use case, I'm not sure I want those included. If we're pulling the same dependency from two repos, I want to flag that. Is it reasonable for us to have two different dependencies for the same artifact with different classifiers or types?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The classifier and type are pretty key coordinates. I think you should have a different method for identifying equivalence that ignores repository. Or perhaps the repository should not be a coordinate at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that you mention it, what I really need to verify here is that the groupId:artifactId is unique, not even including version.
Assert.assertTrue(status, | ||
"beta".equals(status) || "alpha".equals(status) || "GA".equals(status)); | ||
new URI(client.getString("apireference")); | ||
Assert.assertTrue("1.7.0".equals(client.getString("languageLevel"))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The precision seems odd.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is. ATM, we don't have anything else though. I do want to make this a check for a real version string, not just a string.
for (int i = 0; i < clients.size(); i++) { | ||
JsonObject client = (JsonObject) clients.get(i); | ||
String status = client.getString("status"); | ||
Assert.assertTrue(status, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could use Hamcrest's org.hamcrest.collection.IsArrayContaining
so the invalid value is shown in the failure message.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
|
||
import org.junit.Test; | ||
|
||
public class MavenCoordinatesTest { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need some tests for equals()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
The PR says it's expanding JSON test coverages but makes changes to a non-test class? Is there more going on here? |
We needed MavenCoordinates for the tests, or did at one point. Now I'm not so sure. I expect there'll be some libraries for processing the metadata, though I'm still not sure which piece swill land here and which in the IDE repos. |
If it's only being used for tests, can it be in the |
reverted MavenCoordinates now; it can come back later if needed |
|
||
private static final String[] statuses = {"alpha", "beta", "GA"}; | ||
|
||
private static void verifyApi(JsonObject api) throws URISyntaxException { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit : would using assertApi instead of verifyApi clarify that the intention of the method is to make assertions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
new URI(api.getString("documentation")); | ||
if (api.getString("icon") != null) { | ||
new URI(api.getString("icon")); | ||
Map<String, String> map = new HashMap<>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
name of map
maybe can be more descriptive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
} | ||
|
||
@Test | ||
public void testMavenCoordinates() throws FileNotFoundException, URISyntaxException { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could this be named testMavenCoordinate_fileIsValid or something? It's hard for me to tell (since I didn't really look at the previous CL) what this test is doing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
Codecov Report
@@ Coverage Diff @@
## master #443 +/- ##
=======================================
Coverage 66.28% 66.28%
=======================================
Files 67 67
Lines 1815 1815
Branches 281 281
=======================================
Hits 1203 1203
Misses 489 489
Partials 123 123 Continue to review full report at Codecov.
|
"language":"java", | ||
"site":"https://cloud.google.com/bigquery/docs/reference/libraries#client-libraries-install-java", | ||
"apireference":"https://googlecloudplatform.github.io/google-cloud-java/0.22.0/apidocs/com/google/cloud/bigquery/package-summary.html", | ||
"version" : "0.22.0", | ||
"apireference":"https://googlecloudplatform.github.io/google-cloud-java/latest/apidocs/com/google/cloud/bigquery/package-summary.html", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would this be clearer as a language-specific field called javadoc
?
Oh, actually we should have a javadoc
field for programmatic access (e.g., Eclipse javadoc hovers) as well as a the more human-meaningful API starting point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what would the difference be. For example, what javadoc URL would Eclipse need here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I try setting the Javadoc URL for a jar to this URL (right-click on a jar, like a bundle in the Plug-in Dependencies, and select Javadoc Location, and set as a URL), Eclipse shown an error:
The java docs have a specific layout, as does the HTML. So Eclipse is able to find and parse out the appropriate Javadoc to be shown in a hover.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To make that work, I think we first need to get google-cloud-java to publish individual javadoc for each API. The file it's looking for is at
https://googlecloudplatform.github.io/google-cloud-java/latest/apidocs/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably pull IDE readable source and javadoc jars from Maven Central rather than calling them out as a separate artifact.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to @elharo 's comment - then the javadoc and source will actually match the classes that the user is using.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CT for IntelliJ plans to expose these links to the end user so it needs human browsable URLs.
The links to the Maven source/javadoc jars don't need to be explicitly included here because they can be derived from the Maven coordinates.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good.
"language":"java", | ||
"site":"https://cloud.google.com/bigquery/docs/reference/libraries#client-libraries-install-java", | ||
"apireference":"https://googlecloudplatform.github.io/google-cloud-java/0.22.0/apidocs/com/google/cloud/bigquery/package-summary.html", | ||
"version" : "0.22.0", | ||
"apireference":"https://googlecloudplatform.github.io/google-cloud-java/latest/apidocs/com/google/cloud/bigquery/package-summary.html", | ||
"infotip":"The com.google.cloud.bigquery packages", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might be useful to encode in the metadata to enable UI discovery (e.g., a quick-fix on unresolved symbols)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you elaborate? I'm not sure exactly what you're proposing here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would be something different. This is human readable text for the infotip on the library.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good to have this in a machine readable format too for the tooling reasons above.
Maybe it would help to add additional information here. For example, there are sometimes alpha versions of libraries that users may want to try. Or if this is the Google API Client library, we could add a pointer to the Google Client library?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. How do we tell Eclipse about our packages when adding a library?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we'd have a quick-fix on an unresolved symbol like PDE's quick-fix. Our quick-fix would iterate on the library definitions to see if it can find a match.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oops, ping on this request too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
"name": "Google Cloud Datastore", | ||
"documentation": "https://cloud.google.com/datastore/docs/reference/libraries", | ||
"description":"Google Cloud Datastore is a NoSQL key-value database built for automatic scaling.", | ||
"transport": "http", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Should
transport
be an array? What do we do for libraries that support bothhttp
andgrpc
? - Shouldn't this really be in the
clients
section? We may have libraries that just use thehttp
REST APIs, even though the API supports both
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do any libraries support more than one transport? let me check with the api team.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
still waiting for a reply but the docs do say, "Clients in this repository use either HTTP or gRPC for the transport layer. The README of each client documents the transport layer the client uses."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Stepping back, what will we do with this information? Are we going to use it as a filter — e.g., if grpc
then cannot be used on AESv7?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, exactly that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So is better to encode this platform-compatibility knowledge into the consumers of this API, or to make it explicit in a compatibility/platform section? I lean towards the latter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That brings us back to where we were earlier with defining in this file all the possible platforms, and it all resolves to the transport anyway. For now, I'm inclined not to encode platforms. We can add those later if we need them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have turned this into an array though.
{ | ||
"name":"Google Cloud Storage Client Library for Java", | ||
"language":"java", | ||
"site":"https://cloud.google.com/storage/docs/reference/libraries#client-libraries-install-java", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't the #using_the_client_library
section be more appropriate, since the user will be using the consuming UI to automate the installation of this library?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I really wanted was the entire page, but that won't pick up Java as opposed to Python. This is the nearest link to the top.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me file a bug requesting a URL for the whole page.
((JsonObject) api.getJsonArray("clients").get(0)).getJsonObject("mavenCoordinates"); | ||
String mavenCoordinates = | ||
coordinates.getString("groupId") + ":" + coordinates.getString("artifactId"); | ||
if (apiCoordinates.containsValue(mavenCoordinates)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should be ok to provide different versions of an API library, shouldn't it? E.g., Java libraries for BigQuery 1.0.0 vs 2.0.0?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that would have a different group or artifact ID. I don't think we want both 1.3.0 and 1.4.0.
"site":"https://cloud.google.com/datastore/docs/reference/libraries#client-libraries-install-java", | ||
"apireference":"https://googlecloudplatform.github.io/google-cloud-java/latest/apidocs/index.html?com/google/cloud/datastore/package-summary.html", | ||
"infotip":"The com.google.cloud.datastore packages", | ||
"status" : "GA", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think releaseLevel
would be a more accurate description of the Alpha/Beta/GA values
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wikipedia seems to call this a "stage" though I can't say I've heard that before: https://en.wikipedia.org/wiki/Software_release_life_cycle#Stages_of_development
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like "launch stage" is actually the terminology used by Google Cloud Platform: https://cloud.google.com/terms/launch-stages
However, we have to keep in mind that the release level of client libraries will lag behind the service.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could offer separate statuses for the API and the client library. This one is specific to the client library. Meanwhile I'll change this to launchStage.
"mavenCoordinates" : { | ||
"groupId" : "com.google.cloud", | ||
"artifactId" : "google-cloud-datastore", | ||
"version" : "1.4.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this version have to be updated with every google-cloud-java release?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Of course clients do have the option to ignore the version here and query Maven central for the latest release version. CT4E contains code to do this.
"language":"java", | ||
"site":"https://cloud.google.com/bigquery/docs/reference/libraries#client-libraries-install-java", | ||
"apireference":"https://googlecloudplatform.github.io/google-cloud-java/0.22.0/apidocs/com/google/cloud/bigquery/package-summary.html", | ||
"version" : "0.22.0", | ||
"apireference":"https://googlecloudplatform.github.io/google-cloud-java/latest/apidocs/com/google/cloud/bigquery/package-summary.html", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good.
"name": "Google Cloud Storage", | ||
"documentation": "https://cloud.google.com/storage/docs/reference/libraries", | ||
"description":"Unified BLOB storage for developers and enterprises, from live data serving to data analytics/ML to data archiving.", | ||
"transport": ["http"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pluralize transports? since we have clients
and mavenCoordinates
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
Pinging everyone. Are there any final blockers that prevent us from checking this in and moving forward with the rest of the google-cloud-java APIs? We can easily add additional content later. Changing or removing existing fields should be done here if possible. If not, it needs an approval. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ping ping ping
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might also be a good time to begin the process of separating out our plugin support libraries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM too.
* expand JSON test coverage * add test for equals * hamcrest * redundant assert removed * fix loop * fix loop * regex versions * don't make repo a corrdinate * type to packaging * verify group ID artifact ID * checkstyle fixes * revert metadata for now * code review * add datastore api * toArray * GCS * make transport an array * make transport an array * launchStage * pluralize transports * pluralize transports * add packages
@briandealwis @loosebazooka @garrettjonesgoogle @eamonnmcmanus @lesv