twingly / twingly-search-api-java Goto Github PK

Like twingly/twingly-search-api-ruby#68, we could expose longitude and latitude on the Post object, to make things simpler for the user. We can keep the Coordinate class behind the scenes.

We should probably parse the strings returned from the API with longitude and latitude into a suitable data type. (Is Float good enough?)

I think we should do this before releasing the next version.

Precise (Ubuntu 12.04) is end of life. We should probably move to more recent environments like trusty or xenial.

I gave this a quick test in #37, but it didn't work due to some openjdk7 incompatibilities.

The README here, https://github.com/twingly/twingly-search-api-java#betamax, tells you to use keytool to modify Java's trust store, before running Betamax tests, but perhaps there's an alternative to that, that the tests could use, so the user doesn't have to care.

I saw this at https://github.com/shyiko/mysql-binlog-connector-java#using-ssl (haven't read anything more about this)

System.setProperty("javax.net.ssl.trustStore", "/path/to/truststore.jks");
System.setProperty("javax.net.ssl.trustStorePassword","truststore.password");
System.setProperty("javax.net.ssl.keyStore", "/path/to/keystore.jks");
System.setProperty("javax.net.ssl.keyStorePassword", "keystore.password");

Joda-Time seems to be much better than the built-in Java classes like Date. http://www.joda.org/joda-time/

Following SO thread is quite interesting: http://stackoverflow.com/questions/308683/how-can-i-get-the-current-date-and-time-in-utc-or-gmt-in-java

The jar file available for download here seems corrupted. Trying to open it on Linux gives the following error message:

End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.

We re-published with a better name, see: https://search.maven.org/#search%7Cga%7C1%7Ctwingly-search

• twingly-search-api-java/build.gradle

  Line 8 in c9de572

  version = "1.0.0"

• twingly-search-api-java/src/main/java/com/twingly/search/Constants.java

  Line 10 in c9de572

  public static final String VERSION = "1.0.0";

Not sure if we can do anything about it, but we should investigate.

We now have support for HTTP compression (e.g. gzip) for Twingly Blog Search API, but this client does not ask for compression.

In order for users of Maven to utilize artifacts produced by your project, you must deploy them to a remote repository. Many open source projects want to allow users of their projects who build with Maven to have transparent access to their project's artifacts. In order to allow for this, a project must have their artifacts deployed to the Central Repository.

https://maven.apache.org/guides/mini/guide-central-repository-upload.html
#3 should be done first though.

We need to, at least, update Gradle. Current version, which I believe is 3.5, fails out with:

Could not determine java version from '11.0.2'.

3.5 does not even support Java 9.

We need the 5.x series for Java 11: https://jaxenter.com/gradle-5-152369.html

We tried out https://docs.gradle.org/current/userguide/jacoco_plugin.html (it was fantastic!)

For instance: fromIsoCode method is not tested at all

https://github.com/twingly/twingly-search-api-ruby/blob/4d053df7bf9e477e964cb01dcea174bfd156be02/spec/fixtures/valid_empty_result.xml

Things to do before we can release the next version:

• Determine if next version is major or minor
• Update @since ... lines in the code with the correct version
• Update https://github.com/twingly/twingly-search-api-java/blob/master/src/main/resources/version.properties
• Add changelog

Just like twingly/twingly-search-api-ruby#21

Update the client to use the new Blog Search API v3.

Notable changes from the previous version of the Blog Search API are listed under https://developer.twingly.com/resources/search#changes-from-previous-version.

The ruby client was updated in twingly/twingly-search-api-ruby#65, which can be used as help. Some XML fixtures can also be copied from there if needed.

If possible, try to keep all classes/methods/properties backwards compatible with the previous version of the client by marking methods as deprecated. Similar to what was done in the Ruby client.

Did you help close this issue? Go claim the $50 bounty on Bountysource.

Implement a test suite with on-par coverage with our Ruby implementation.

We use VCR for two tests: one and two. It seems like the most obvious Java port, βetamax, is not really maintained anymore and it's also dependant upon Groovy. Perhaps it's possible to achieve the same degree of coverage using one of the following tools:

• http://wiremock.org/
• https://github.com/dreamhead/moco
• http://www.mock-server.com/