Project Lombok provides an easy way to generate java beans with
\nUsing this has the following implications:
\nhashCode and equals a lot of code with a high complexity is generated.\nThis has implications for test coverage. Even though lombok supports the generation of Generated\nannotations (own or jakarta), this has no effect in Sonar.First, this will be used for data transfer objects (DTO) in the REST endpoints. To avoid the mentioned\ncomplexity of hashCode and equals, these should not be generated.
The following lombok annotations will be used for DTOs:
\n@Getter@Setter@AllArgsConstructor and @NoArgsConstructor (if needed; by default only the default constructor\nwill be present. Because this one is necessary for deserialization, this one has to be created\nexplicitly when the all-args constructor is declared)The URI-format for accessing a repository, be it with a browser, or cloning/pulling via git/hg/svn, is defined to\nbe /repo/:namespace/:name. The decision was made to allow users to choose namespaces as they please. If there would\nnot be a prefix, some namespaces (e.g. user, users) would have to be reserved, since the names are already in use by\nSCM Manager itself. The /repos URI linked to a list of repositories, as well as operations such as creating a\nrepositoriy (/repos/create).
In v1 error handling was somewhat diverse. Some checks were made explicitly in the web resource classes leading\nto direct responses, some were made using exceptions and matching exception mappers.
\nIn v2 we have decided to
\nsortBy parameters using dedicated exceptions,isValid method (taken from v1) without an extra mapping\n(so that this will lead to 500 errors indicating a missing validation in the web resource)The following generic exceptions will be used:
\nNotFoundException,AlreadyExistsException,ConcurrentModificationExceptionTechnical errors, for example io errors or other exceptions during the low level repository access are wrapped\nin runtime exceptions like RepositoryException and will lead to internal server errors (http status 500).
For simple objects like users and groups we don't think that we will need more exceptions.
\nLogging can be cucial when it comes to identify bugs in test or production environments. At implementation time one\ncannot foresee all possible error cases and therefore cannot determine with full certanty what informations will be\nneeded and what can be neglected. Logging only crucial errors leaves the developer with no idea what events might have\nlead to the error. On the other hand logging too much will overburden the log, making it harder to handle and maybe\nhiding interesting steps.
\nTherefore it is best practice to be able to select the detail level of informations to log (called the \"log level\"). To\nsupport this feature SCM-Manager uses slf4j. Using this library one can log informations with\nthe following log levels:
\nAs a default the log level for SCM-Manager is INFO, so that by default all logs with the levels ERROR, WARN and INFO are\nstored. Finer levels can be enabled manually.
\nWe have agreed to apply to the following guidelines regarding log levels:
\n