The gitlab api provides numerous parameters. Most are currently not offered by java-gitlab-api.
The current design provides API parameters individually as method parameters. This is not very future proof and clumsy.
Instead, one could directly accept a query object. In order to get at least a certain abstraction, one simply derives sub-classes for the respective use cases.
Because I did not "hide" the query (as implemented in the old pagination class), it is also possible to add parameters that may be added to the API in the future. This would basically make the methods forward-compatible.
The gitlab api provides numerous parameters. Most are currently not offered by java-gitlab-api.
The current design provides API parameters individually as method parameters. This is not very future proof and clumsy.
Instead, one could directly accept a query object. In order to get at least a certain abstraction, one simply derives sub-classes for the respective use cases. Because I did not "hide" the query (as implemented in the old pagination class), it is also possible to add parameters that may be added to the API in the future. This would basically make the methods forward-compatible.
I made the whole example of the
GitlabAPI#getProjects()
(GitlabAPI, ProjectsQuery) and the newly addedGitlabAPI#getProjectPipelines()
(GitlabAPI, PipelinesQuery).