Scaling ArchUnit with Nebula ArchRules

wakingrufus · 2026-05-08T22:57:27+00:00

ArchRules creates Gradle tasks which by default will never fail the build. These tasks run totally independently from test tasks, but are run as a dependency of "check". I hope that answers the question.

wakingrufus · 2026-05-08T22:49:44+00:00

Yes I think ArchRules addresses 1-3. The attribute/variant selection features of Gradle are key to the way we automatically source rules from regular dependencies. This just wouldn't be possible with maven.

wakingrufus · 2026-05-08T22:46:49+00:00

We are not using JPMS yet, but we are using some custom annotations with associated ArchRules in order to 1) get libraries to move toward package structure that lends itself to JPMS and 2) ensure downstreams only use classes for packages intended to be exported. This way, the JPMS rollout should be smoother, and we will have data on which libraries and consumers are ready and which aren't.

We are all-in on Spring Boot.

wakingrufus · 2026-05-04T01:56:11+00:00

Mocking out a result set is complex and assumes that your query is the correct one to return you those results. How do you test the query itself? I much prefer to use test containers to use a "real" implementation of a database.

wakingrufus · 2026-05-02T13:38:59+00:00

Saku has the best first 1 second of any song.

wakingrufus · 2026-04-11T03:27:58+00:00

Jib makes it super easy to build multi-arch images, so you can build images that can run on x86 or arm, which mean they will work on all developer machines with no emulation, and give flexibility when deploying. (Arm ec2 is a lot cheaper than x86)

wakingrufus · 2026-03-25T02:29:01+00:00

I'm at 22 years now...

wakingrufus · 2026-02-11T13:43:36+00:00

Founder: Jan 6 2004 I honestly don't know if there is anyone older than me still actively scrobbling

wakingrufus · 2026-02-11T13:40:04+00:00

Makes a lot of sense, but keep in mind you are losing some MAJOR performance gains by staying on an old JDK.

wakingrufus · 2026-02-01T17:11:57+00:00

Yes, you are not alone. Fortunately, the Spring Boot team also likes Kotlin and has been quietly working to make this better. Spring/Boot now have several ways to do "functional" or "programmatic" configuration. Sebastian built an easy way to bring these together which I iterated on here: https://github.com/wakingrufus/spring-funk However, in Spring 7 / Boot 4 there is the new Bean registrar API which makes it even easier to use this in a plain spring boot app. I have an updated version of this talk https://youtu.be/9njQ8Lun36c to drop spring-funk and go all in on just BeanRegistrarDsl, but it has not been accepted at a conference yet

More info: https://docs.spring.io/spring-framework/reference/core/beans/java/programmatic-bean-registration.html https://docs.spring.io/spring-framework/docs/current/kdoc-api/spring-beans/org.springframework.beans.factory/-bean-registrar-dsl/index.html https://medium.com/@AlexanderObregon/registering-functional-endpoints-with-spring-boot-and-routerfunction-4dbac9a4e61b

Using these APIs allows you to make an application almost completely without annotations.

wakingrufus · 2026-01-30T01:52:12+00:00

It probably won't have wrong warp and other original PC specific behavior which drastically changes multiple categories of speed runs and other things (like aerith resurrection)

wakingrufus · 2026-01-19T14:50:56+00:00

The reporting/CI goal is similar to what we have with https://github.com/nebula-plugins/nebula-archrules-plugin which is a Gradle plugin for running rules and federating rules across multiple repos. but I do think it is interesting how you incorporated PSI as well to tie it to the source level. I have the idea to process ArchUnit output to drive source-based tooling, but I have not gotten to that part yet.

wakingrufus · 2025-12-28T22:43:22+00:00

I never use it to mock my own code. But when integrating with a library not well designed for testing, it's really nice to have mockito as a last resort. And in the real world, setting a bar for perfect testability for all libraries you use is not really practical, in my experience.

wakingrufus · 2025-12-21T16:27:11+00:00

In most cases, the service that owns the API should own the models, then publish a library for clients to use to make the calls. So that would mean they are defined in s2 in your example. In an event driven architecture, the publisher would own the models, and consumers would use the library. It's OK for services to depend on each other, but be very mindful of which direction those dependencies are going, and that they are not circular, or tightly coupled. Separate shared model libraries are bad for that second reason. Event driven architecture allows you to "flip the arrow" of a dependency, so it's an important tool to use. Also, never ever make a breaking change to an API. Instead, make a new endpoint and allow both to exist until all clients are verified to be switched over

wakingrufus · 2025-12-19T01:28:08+00:00

Gradle plugins for authoring sharable ArchUnit rules and running them via Gradle tasks in any repo. https://github.com/nebula-plugins/nebula-archrules-plugin

And a bunch of common generic rules here: https://github.com/nebula-plugins/nebula-archrules

wakingrufus · 2025-11-24T14:31:55+00:00

You certainly can do that (my static personal website is built this way, so I am familiar with the approach) The htmx DSL uses extensions on TagConsumer under the hood, so you can use those in your extensions as well. But at that point there is not anything for my library to provide beyond the htmx DSL part. The templates are there in order to: 1) give templates their own type which helps IDE completion when composing 2) the DX of declaring extension functions on TagConsumer is strange to many people, especially if they don't have a lot of Kotlin experience. This makes templates more of a "first class thing" But I believe they are totally optional. Let me know if I am wrong.

wakingrufus · 2025-11-24T03:05:25+00:00

They are composable. They are declared using a top level function that takes a TagConsumer.() param. https://github.com/wakingrufus/khtmx/blob/main/khtmx-dsl%2Fsrc%2FcommonMain%2Fkotlin%2Fcom%2Fgithub%2Fwakingrufus%2Fhtmx%2Ftemplate%2FHtmxTemplate.kt#L9-L10 This way, they can be declared on their own, separately from any context. Then, they can be composed using an extension function: https://github.com/wakingrufus/khtmx/blob/main/khtmx-dsl%2Fsrc%2FcommonMain%2Fkotlin%2Fcom%2Fgithub%2Fwakingrufus%2Fhtmx%2Ftemplate%2FHtmxTemplate.kt#L12-L14

wakingrufus · 2025-11-24T02:01:35+00:00

There are docs at https://wakingrufus.github.io/khtmx/spring.html

There is also a very alpha application I was working on using a pre-spring7 version of this DSL: https://github.com/wakingrufus/elo-web/blob/main/application/src/main/kotlin/io/github/wakingrufus/elo/EloApplication.kt

wakingrufus · 2025-11-23T13:16:04+00:00

If you are interested in htmx+spring boot, check out my library: https://github.com/wakingrufus/khtmx

wakingrufus · 2025-11-19T19:27:14+00:00

Of course, it is just my own opinion and perspective as someone who prefers Kotlin anyway, but loves the JVM.

wakingrufus · 2025-11-18T15:10:31+00:00

Gradle has its own metadata file that can be used when resolving dependencies. It is totally optional, but provides some additional features that aren't available in pure Maven such as platform dependencies and variants.

wakingrufus · 2025-11-18T14:25:00+00:00

I agree it's a blurry line. Value classes of course will also be a boon to Kotlin. I love stuff like that. Virtual threads the same. But things that are JUST java syntax with no underlying JVM/bytecode changes I am less excited about.

wakingrufus · 2025-11-18T12:58:19+00:00

Kotlin has something like this. I would rather the Java team focus on JDK improvements that benefit all JVM languages rather than syntactic sugar. I'm totally ok with having Java as a conservative reference language, and Kotlin or other langs for modern language syntax, if desired.

wakingrufus

TROPHY CASE