Journal Spring Boot vers RPM (un bricolage)

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
18
13
déc.
2022

Je poste rarement ici, et c’est bien dommage. Je vient de terminer un petit bricolage qui pourrait intéresser quelqu’un ici.

Ça part d’un besoin perso, comme tous mes bricolages que je publie, n'y voyez surtout pas le fantasme de l'homme mais plutôt… Comment dirais-je… La recherche créative, le délire du développeur et un peu l’admin que je suis, en quelque sorte : j’ai écrit un script en bash pour passer un projet Java/Maven/Spring Boot écrit en tant que service, en paquet RPM, et un installeur Windows (parce ce que oui).
Rien de bien fou, mais très spécifique, qui vous passera certainement à 15 km au dessus de votre tête, et ça sera tant mieux. D’ailleurs je suis sûr que d’autres l’on mieux fait que moi.
Mais c’est pas grave, du moment ou ça me suffit.

Y’a un README, c’est sur GitHub, pour pouvez reprendre une vie normale et oublier tout ça !

https://github.com/hdsdi3g/linux-springboot-packager

  • # rpm-maven-plugin ?

    Posté par  (site web personnel) . Évalué à 5. Dernière modification le 13 décembre 2022 à 14:59.

    Pourquoi ne pas utiliser un plugin maven pour ça ?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: rpm-maven-plugin ?

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      Déjà parce que c’est un peu galère le dev de plugins maven, surtout pour tester ça bien.
      Je sais qu’il existe deja des choses de ce côté, mais rien d’assez pratique pour mes besoins.

      Mon code produit une page man, un service systemd, adduser pour le service, une conf quasi prête pour le lancer juste après l’install. J’ai même prévu l’appel à liquibase pour mettre à jour la BDD si besoin.

      Ensuite parce que je bricole ce code/concept depuis longtemps, ce qui est récent ici, c’est le RPM produit.
      Et un jour le deb.

      Le dev d’installeurs, c’est ingrat.

  • # C'est bien

    Posté par  (site web personnel) . Évalué à 4.

    En tout cas je trouve tes scripts Shell bien lisibles (pour ce que permet Bash ..), sans doute portable et optimisé (si il y a du Bash. Et oui, j'entends ceux du fond dire que le KornShell c'est plus mieux). L'utilisation des intrinsics au lieu de forker des commandes dans tous les sens, j'en connais plus d'un qui pourrait en prendre de la graine.

    Encore une news sur Spring Boot et nous rendons Open Source notre Framework utilisé en interne (utilisant Spring Boot), avec une news ici en prime.

    • [^] # Re: C'est bien

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      J’ai hâte de lire ta future News.
      Et merci pour ton soutien.

      Oui j’ai bien gardé en tête la lisibilité maximale, car c’est vite fait en bash de s’embrouiller… même si j’ai un peu de rouge encore dans shellcheck.

      Après pour la portabilité, je vise bash et seulement lui. Ce code est sensé tourner sur une machine proche du dev, je m’autorise alors « quelques » dépendances !
      L’idée est aussi de pouvoir forker et modifier facilement mon code pour des besoins annexes, comme changer le fichier de service fourni par défaut : d’où l’importance que les choses soient les plus claires possible. Pas envie de me reprendre la tête dans 6 mois (quand je ferait le deb 😄), surtout au vu du temps qu’il m’a fallu pour écrire tout ça  !

    • [^] # Re: C'est bien

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Et oui, j'entends ceux du fond dire que le KornShell c'est plus mieux

      Promis, on va pas refaire la discussion
      Encore que la mode c'est pas de dire que Zsh est plus plus mieux ?

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.