Support for GitLab model extensions

[DaBlick]

I'm writing a GitLab dashboard that decorates the models with properties "derived" from examining the sources. For example, there's a Maven plugin that decorates a branch model it with information from the POM in the branch head (there are already plugins for NPM, Terraform, Spring Boot, Angular, etc.).

_Note: I'm hoping to open-source this dashboard. I'm deliberately architecting it to make it easily/trivially extensible to support _new use cases and avoiding putting nor hard-coding any of my employe's IP. You configure it for your needs via Spring Boot configs.__

I would LIKE to use gitlab4j but the challenge I have is that I need to EXTEND the models with a field that points to these derived properties. But the way gitlab4j is coded makes that hard:

• The models aren't tied together via a base class that you could easily put such an extension
• The code that takes a response and deserialized into a class are hardcoded to a specific class (rather than using, say, a factory pattern)

return (response.readEntity(Commit.class));

So what I'm seeking here in this ticket is a bit of discussion:

1. Do the owners and consumers of this effort see this as valuable?
2. What would be a good way to accomplish this?

I can offer some suggestions for people to comment on:

1. I think, even aside from this, it would be valuable to tie all the models together with a common type: either via an abstract ase class or maybe an interface (I'd vote in THIS case for an abstract type). SCOPE: TRIVIAL and low risk
2. Encapsulation: A base class could offer a method that supports this via encapsulation. You call the method to get the additional derived properties. How a derived property would be as associated with a particular instance of a model seems moderately challenging and perhaps a significant memory management issue. (A Map). I don't really like this approach
3. Factory methods. Rather than hard-code the target model classes for a request, a factory is method. A default factory method is provided that just returns the gitlab4j model classes, but consumers of this project could have the option of providing an alternative factory that offers user classes.

My current thinking is that the best way to do do this is to have a GENERIC base class for models that looks somehwat like this:

package org.gitlab4j.api.models;

public class AbstractBaseModel<T> {
    private T derivedProperties;

    public T getDerivedProperties() {
        return derivedProperties;
    }

    public void setDerivedProperties(T derivedProperties) {
        this.derivedProperties = derivedProperties;
    }
}

There would also be some sort of default for T which I suppose might best be a Map although it would be nice to find a way to be able to have a client-defined type instead. The challenge there is that the type has to be specified in each of the concrete classes.

[DaBlick]

Another suggestion: Introduce "Lombok" to the project :-)