Skip to content
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

Convert Project to Multi Module #11

Merged
merged 3 commits into from
Oct 11, 2019
Merged

Convert Project to Multi Module #11

merged 3 commits into from
Oct 11, 2019

Conversation

Shah-Parth
Copy link
Contributor

  • Converting project to multi module
  • adding -SNAPSHOT to the release tag
  • improving README

* Converting project to multi module
* adding -SNAPSHOT to the release tag
* improving README
@Shah-Parth
Copy link
Contributor Author

closes #10

@Shah-Parth Shah-Parth requested review from ghershfield, a user and mikejlong60 October 1, 2019 19:40
</repository>
</repositories>
<dependencies>
<!-- Commons Libraries -->
Copy link
Contributor

Choose a reason for hiding this comment

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

My understanding is that provided scope dependencies will need to be explicitly added by programs using this library. Is this really what we want?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You're right... compiled is probably what we need to resolve the transitive dependencies.

<encoding>UTF-8</encoding>
<forceJavacCompilerUse>true</forceJavacCompilerUse>
</configuration>
</plugin>
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this commented out because it's optional?

</goals>
</execution>
</executions>
</plugin>
Copy link
Contributor

Choose a reason for hiding this comment

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

I recommend adding a comment/justification for commented out blocks. I prefer just removing them.

@jeffusan
Copy link
Contributor

jeffusan commented Oct 2, 2019

Are the p12 and truststore intended to be published with the OSS artifact?

@jeffusan
Copy link
Contributor

jeffusan commented Oct 2, 2019

The *ResponseHandlers seem to have duplicate logic, ie:

    @Override
    public ArrayList<ResponseMetadata> handleResponse(final HttpResponse response)
            throws IOException {
        final StatusLine statusLine = response.getStatusLine();
        final HttpEntity entity = response.getEntity();
        if (statusLine.getStatusCode() >= 300) {
            EntityUtils.consume(entity);
            throw new HttpResponseException(statusLine.getStatusCode(),
                    statusLine.getReasonPhrase());
        }
        return entity == null ? null : handleEntity(entity);
    }

    /**
     * Returns the entity as a body as a String.
     */
    @Override
    public ArrayList<ResponseMetadata> handleEntity(final HttpEntity entity) throws IOException {
        String entityString = EntityUtils.toString(entity);
        Gson gson = new Gson();

        return gson.fromJson(entityString, new TypeToken<ArrayList<ResponseMetadata>>() {
        }.getType());
    }

Why is this duplicated in several classes instead of being just one class?

@jeffusan
Copy link
Contributor

jeffusan commented Oct 2, 2019

GreyMatterCloseableHttpClient has a code block commented out:

    //TODO: uncomment once {@link GreyMatterDataStreamResponseHandler} is implemented
//    @Deprecated
//    public InputStream execute(final GreyMatterDataStreamRequest request) throws IOException, ClientProtocolException {
//        return execute(request, new GreyMatterDataStreamResponseHandler(), null);
//    }

GreyMatterDataStreamResponseHandler exists, but has a comment to the effect "this needs more thought".

What is the status of GreyMatterDataStreamResponseHandler and the intent going forward? Is it something that still needs to be implemented?

Copy link
Contributor

@jeffusan jeffusan left a comment

Choose a reason for hiding this comment

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

I'd prefer to see commented out code removed and replaced with issues.

@Shah-Parth
Copy link
Contributor Author

Shah-Parth commented Oct 2, 2019

GreyMatterCloseableHttpClient has a code block commented out:

    //TODO: uncomment once {@link GreyMatterDataStreamResponseHandler} is implemented
//    @Deprecated
//    public InputStream execute(final GreyMatterDataStreamRequest request) throws IOException, ClientProtocolException {
//        return execute(request, new GreyMatterDataStreamResponseHandler(), null);
//    }

GreyMatterDataStreamResponseHandler exists, but has a comment to the effect "this needs more thought".

What is the status of GreyMatterDataStreamResponseHandler and the intent going forward? Is it something that still needs to be implemented?

Yes, I need someone more familiar to take a look and tell me what I can do to provide users to leverage GreyMatterDataStreamResponseHandler instead of generic HttpResponse. If we can implement the logic inside GreyMatterDataStreamResponseHandler we can customize it to specific gm-data needs with standardized errors.

@Shah-Parth
Copy link
Contributor Author

The *ResponseHandlers seem to have duplicate logic, ie:

    @Override
    public ArrayList<ResponseMetadata> handleResponse(final HttpResponse response)
            throws IOException {
        final StatusLine statusLine = response.getStatusLine();
        final HttpEntity entity = response.getEntity();
        if (statusLine.getStatusCode() >= 300) {
            EntityUtils.consume(entity);
            throw new HttpResponseException(statusLine.getStatusCode(),
                    statusLine.getReasonPhrase());
        }
        return entity == null ? null : handleEntity(entity);
    }

    /**
     * Returns the entity as a body as a String.
     */
    @Override
    public ArrayList<ResponseMetadata> handleEntity(final HttpEntity entity) throws IOException {
        String entityString = EntityUtils.toString(entity);
        Gson gson = new Gson();

        return gson.fromJson(entityString, new TypeToken<ArrayList<ResponseMetadata>>() {
        }.getType());
    }

Why is this duplicated in several classes instead of being just one class?

All of these classes are there as a placeholder for the initial starting point, we can for sure improve these classes and handle specific errors based on the particular endpoints.
Yes, there is a lot of redundant code, but at the same time this is just an initial prototype of the SDK and it for sure needs more contribution. I don't think this is too critical at this point that it needs to be resolved in this PR.

* adding a comment for commented out plugin (it will get enabled once java docs are properly done)
@Shah-Parth
Copy link
Contributor Author

Can someone please approve the PR so I can merge it.

@jeffusan jeffusan self-requested a review October 11, 2019 15:23
@Shah-Parth Shah-Parth merged commit 20ed303 into master Oct 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants