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

DoNotApprove: Gradle, Parameters, and Paging #237

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

kazetsukaimiko
Copy link

@kazetsukaimiko kazetsukaimiko commented Sep 20, 2018

I'd like to get your thoughts on the following modifications and perhaps get them merged at some point. This PR has a few features of note:

  • Gradle Support
    Builds and tests run via gradle. Several libraries required upgrade- mockito behaviors have changes (see tests) and the Java target/source version may be too high for the upstream author's liking (also seems to cause different date behaviors, still investigating). The project can still be built with Maven. The Gradle support allows me to reference this codebase as an out-of-project module to build instead of a Maven artifact that needs to be pushed to a repository first.

  • Auto-pagination on Agile
    If a board has more than (50/ page size) stories, your client lib currently has no way of retrieving them. This modification automatically submits paginated follow-ups until the entire dataset has been retrieved, see "Parameters" below. Example: If a board has 250 sprints and your page size is 10 items, 25 requests will be made when you call board.getSprints().

This currently is done using Stream.concat() and recursion, and preserves the order from paging. Ideally the method signature should change to Stream so that the paging can be invoked lazily as it is being requested (upon collection), but that's a JDK version question.

  • Parameters
    To get "extra" fields in JIRA, one needs to pass expand=field to the service at the request time. For me, I needed the changelog field on stories. These changes preserve the current API contract by using varargs(Parameter...) which is kinda nifty if I may say so myself. This one I think is pretty solid for cherry-picking.

Problems I'm currently solving:
Dates seem to be several hours off with the JDK version switch, investigating.

Other ideas:
I think switching from JodaTime to the java.time.* would be wise. You may be considering older JDKs, which is fine. Maven/Gradle no longer support 1.5 and the codebase could be cleaned up quite dramatically with things like Streams and Optionals. I wouldn't want to invest in a refactor effort without knowing how receptive upstream would be... as that would determine in large part how and what I'd choose to refactor.

public List<IssueType> getIssueTypes() throws JiraException {
return getIssueTypes(false);
}

/**
* Obtains the list of all issue types in Jira.
* @return all issue types
* @throws JiraException failed to obtain the issue type list.
Copy link
Author

Choose a reason for hiding this comment

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

This should be taking Parameter... parameters instead of a boolean. Hmm.

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.

1 participant