Introducing Deder Build Tool

Announce
1

Hello everyone,

This is a blog post about my experimental build tool.

I would appreciate if someone tries it and give honest feedback. :slight_smile:

2

OK, honest feedback from grug of low intelligence follows:

OS/X - Tahoe 26.5.1. Repository: GitHub - sageserpent-open/plutonium: CQRS providing bitemporal object modelling for Java POJOs and Scala too. · GitHub

  1. I tried installing via the GitHub - sake92/deder: Config based client-server JVM build tool · GitHub approach.
  2. After I had renamed the deder-client.jar to deder and did a chmod u+x deder on it, running it with the PATH setup gave me:
zsh: exec format error: deder

Looking in the JAR, I didn’t see a bootstrap preamble to invoke java -jar ...

  1. No bother, I just ran it as java -jar deder.jar, after renaming it again to add the suffix. That worked, and it told me about available commands. I saw import…

  2. java -jar deder.jar import. It hummed and whirred and said:

Discovered 1 modules
Resolved 1 module groups, 1 id mappings (skipped 0 aggregate-only roots)
Sorted order: plutonium
=== Import Summary ===
Module groups: 1 (2 concrete modules)
Dependencies mapped: 28
Ignored (auto-added by Deder): 1
Build import from 'sbt' succeeded.

Seems alright…

  1. java -jar deder.jar modules
plutonium
plutonium-test

OK, this is different from SBT where there would just be one module and two scopes, but whatever…

  1. I look at the cheatsheet, and come up with: java -jar deder.jar exec -t test

(Have to say, why do I have to type exec -t here? I find typing hard as it is, it doesn’t come naturally to my fingers.)

Executing 'test' task on module: plutonium-test
plutonium-test skipped — plutonium failed
Failed ...
  1. Wait, I have two modules - back to the cheatsheet: java -jar deder.jar exec -t test -m plutonium-test

(Again, that’s a lot to type.)

Executing 'test' task on module: plutonium-test
plutonium-test skipped — plutonium failed
Failed ...

At this point I thought that I’ll stick with SBT, because it already works.

Now, please excuse the negative tone - I am only too aware of how it feels when you’ve worked on a magnum opus and the first thing you hear is somebody making a low-effort whine, but bear in mind that everyone is busy being distracted by a multitude of other things, so first impressions have to be quite good to get folk hooked.

At least you got someone to try it and provide feedback. I’m still working on that problem for my own things. :grinning_cat:

Good luck with your endeavours…

(Oh and by the way - where is the magic bit in your GitHub actions that publishes to Brew and Scoop? I could learn a thing or two there.)

2 Likes
3

No worries, I love honesty, it is what it is! :smiley:
Thanks for trying it out! :folded_hands:

Re 1: Why didn’t you go with the brew install? It works on Mac and Linux.
The early-access is just for testing latest main branch stuff..
If you did, then you’d just type `deder exec -t test` etc.

Re 5: Yeah that’s the point of simplifying, no “test scope” or whatever. Mill does the same, completely separate modules.

Re 6: I was following https://clig.dev/ for best CLI experience. Ok it does need a bit more typing, but at least you are not guessing. The exec command is for executing tasks, the other commands are for something else, don’t want to smush everything under same command.

Re 7. There is a wildcard e.g. deder exec -t test -m %test , this would run test on all modules whose id ends with test. There’s also negation with `~`.

Of course you will stay with sbt/mill, this is still very fresh and WIP.
I thought I got the install part easy, seems like I was wrong (a bit at least haha).
Will remove that early-access for client install section.. (was there from the start, before graalvm executables)

The magic bit is the GH actions plus https://jreleaser.org/
See deder/jreleaser.yml at main · sake92/deder · GitHub file.
And brew repo for example GitHub - sake92/homebrew-tap: Sake92 homebrew tap · GitHub

I did try your project, seems like there is a bug with test classpath.
It kinda works with deder exec -t testInMemorytho.. will see.

Again, thanks for giving it a chance, appreciate it! :slight_smile:

1 Like
4

How does it compare to bleep? GitHub - oyvindberg/bleep: A bleeping fast scala build tool! · GitHub It makes similar promises.

1 Like
5

Why didn’t you go with the brew install? It works on Mac and Linux.

Ah, I was being very conservative, as while I do have brew installed, I don’t really understand it beyond the absolute basics, so I was concerned about whether your instructions would introduce a new update channel.

If I understand correctly, you’re implying that the last updates are packaged as a pure JAR, whereas the ones from Brew etc have a startup preamble that allows them to be invoked directly. It’s worth calling that out in your instructions.

Anyway, glad you found the response useful, consider it a possible bug report regarding the Plutonium build.

I will say that you may have quite a slog pushing yet another build tool alternative against the likes of SBT and Gradle, not to mention Mill already trying to encroach upon their territory.

There is Maven too, but you don’t have to work hard to persuade me not to use it!

Maybe some kind of killer use case in your documentation would help call out the USP, if you’re serious about carrying on with this.

To amplify what I wrote before, the hard lesson I’ve learned recently is that not only can you not take it with you, you can’t even give it away. It seems the freegan community of software developers are very discerning indeed. Make sure you lay on candles, black tie service and discreet music when you proffer your dishes…

ATB.

1 Like
6

I didnt try Bleep in a while, last time I tried it wasnt working for some reason.. They did a big overhaul recently, need to have a look again. Biggest surface difference is build definition. They use ad hoc yaml templates, kinda a meta language (similar to new Mill yaml builds..), while Deder uses plain Pkl always.

7

Not a brew expert either.. AFAIK it’s just a small Ruby script that pulls the client exe and verifies its hash.. Yes you need to trust random taps. But all my code is OSS, so you can check it.. :smile:

Thanks, those are good suggestions, I’ve updated the README with clarifications.

Yeah, only “killer USP”s? for now are:

  • running apps in multiple terminals at once (client-side processes)
  • fine-grained locking per tasks
  • web dashboard? pretty unique I think
  • simplicity? :smiley:
  • would love to harden the BSP/IDE support but it is really hard.. (not sure if Metals is bad or skill issue on my side, or both)

Haha, first time hearing “freegan community”, had to Gemini that.. (noted) :laughing:
Yes, yes, michelline software with 3 stars.. :man_tipping_hand: #working_on_it