Vyacheslav Rusakov

Initial articles version was published in my blog.

Now improved version (not just translation - text was reworked) published on Habr:

English version was also slightly correctred in part 2: added complete demonstration of my special case

Released guice-persist-orient 5.0 with OrientDB 3.2 and guice 7 support (release notes). There are actually no changes, except one custom types bug fix (which was the reason for the release).

Actualized examples repository.

Also, released dropwizard-orient-server 4.0 with OrientDB 3.2 and Dropwizard 5 support (release notes). It was not possible to release version also compatible with dropwizard 3 and 4 for technical resons (but no one asked for it so far).

Added new sample (todo app) demonstrating embedded server with guice-persist-orient and dropwizard-guicey. Sample use object API.

Generally speaking, OrientDB is alive (it is maintained and minor releases appear every few months). But we can't expect much evolution in the foreseing future (still developer(s) working on it). It's not very bad as we have pretty stable database without upcoming radical API changes but with all required bugfixes.

The problem is Object API: it is officcially discontinued already but there are no any good mapping alternative. I can't say it was a wrong desigion to deprecate Object API: it has all the same problems as Hibernate, but it was usable (making things simplier).

Soon there should be an interesting alternative: YouTrack DB from JetBrans (OrientDB fork by one of its core contributors).

Released guicey 8.0.0 for dropwizard 5: release notes

This release mainly introduce testing improvements: test client was reworked and now it has the same api for both ClientSupport and stub rest (RestClient). It is also possible now to call rest endopints with resource method calls (refactor-friendly way).

Guice now used without bundled ASM to avoid problems with the recent java versions.

All the same changes were also released for dropwizard 3 - 6.4.0 and dropwizard 4 - 7.3.0

The standalone sample app was also updated to dropwizard 5. Also, tests were updated to demonstrate new client api.

Created new simple (todo) application to demonstrate complete gradle application setup with tests and simple delivery.

As it is a very simple app (with just one rest service), it might be used for a new project setup (or, at least, as a reference).

Based on my experience with updating gradle plugins for configuration cache compatibility, I wrote a large article (in two parts):

* Gradle configuration cache by example. Part 1: behavior

* Gradle configuration cache by example. Part 2: problems

It is based on this examples repository demonstrating all major aspects of configuration cache (it was also a my learning playground).

Should help plugin authors in updating existing plugins for gradle 9

The plugin was reworked to:

- Fix configuration cache support

- Completely fix build cache support

- Simplify new tools support addition

Due to new restrictions (checkstyle 11 requires java 17, spotbugs 4.9 requires java 11), plugin now enable tools based on current java version (so on CI checkstyle would be executed on java 17, but not enabled on java 11 build).

And spotbugs plugin must be applied manually now - it was unavoidable in order to not loose java 8 support (e.g. for groovy projects, not using spotbugs at all).

As a follow up for the latest guicey release I wrote a blog post describing snapshots publication into maven central (from a github action).

Note that maven central keeps snapshots for 90 days, but it is enough for a very common need: run separate examples project with the latest snapshot on CI.

Released:

* 6.3.2 with javax.annotations requirement fix and dropwizard 3.0.14

* 7.2.2 with only dropwizard 4.0.14

* 8.0.0-rc.5 with dropwizard 5.0.0-rc.3

Also, snapshots for all branches now published to maven central (still custom repository configuration is required but without authorization; snapshot lives 90 days (maven central policy))

There is also a new blog post about maven central snapshots configuration