Bonjour à moi-même,
J’ai codé une grande partie d’un cadriciel (Taack-UI, mais chuuut! pour le moment, dont le site est down… ). Je souhaite savoir plusieurs choses concernant le choix des licences, sachant que :
- Le cadriciel a été codé par moi, on va dire à 95% du code significatif, je peux monter à 100%, mais je suis encore salarié (+ou-, bref) ;
- Ce cadriciel se base sur un autre, en spécialisant son usage, le cadriciel de base est en Apache v2 ;
-
Les dépendances supplémentaires sont isolées en fait, chargée via
gradle, mais comment influence t-elle mon choix de licence si :- elles sont utilisées lors du build ;
- elles sont chargées au runtime ;
- lors des tests ;
Comment apposer une licence ? Réellement pour ne pas être embêté ? Doit-on créditer tous les imports? faire des exceptions et cetera, comme au bon vieux temps ?
Dans l'idéal, que feriez-vous pour le choix de la licence et pour gérer le problème des dépendances ? J’aime bien la licence Apache v2, si ce n’est pas un bon choix, quelle serait un meilleur choix ?
Pour que tout ceci soit valable dans la plupart des zones juridiques, comment, précisément, apposer les licences (et en fonction de quelle licence ??) en fonction de ces zones ?
Merci à vous, Vous avez 2 heures !
# ptit correction
Posté par YBoy360 (site web personnel) . Évalué à 1.
Je suis désolé, j'ai été un peu vite :
Si vous en voyez d'autres …
# Automatiser sa gestion des licences
Posté par devnewton 🍺 (site web personnel) . Évalué à 10. Dernière modification le 12 avril 2024 à 07:55.
Tu peux collecter les licences de tes dépendances avec un plugin Maven.
Si tu as un doute, tu peux lancer un outil comme Scancode pour détecter des dépendances qui seraient embarquées dans le code principal.
Si tu dois produire un rapport pour le service conformité de ton entreprise, il y a LicenseFinder.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Automatiser sa gestion des licences
Posté par YBoy360 (site web personnel) . Évalué à 3.
Top, merci.
# statut salarié
Posté par Paul POULAIN (site web personnel, Mastodon) . Évalué à 8.
Hello,
Si tu es salarié et que tu as fait ce dev dans le cadre de ton boulot, c'est ton employeur qui a les droits sur le développement. C'est donc qqc à voir avec lui.
Tu ne dis rien à ce sujet, alors c'est peut-être clair entre vous, mais il me semblait utile de le préciser.
[^] # Re: statut salarié
Posté par YBoy360 (site web personnel) . Évalué à 5.
Je suis mon propre employeur en quelques sortes.
[^] # Re: statut salarié
Posté par B r u n o (site web personnel) . Évalué à 6.
Excuse moi de rebondir là-dessus, mais à partir des infos de ce journal, du journal précédent qui annonce taack-ui et des infos disponibles sur le net, il y a un lien entre l'entreprise Taack et l'entreprise industrielle Citel et l'éditeur Axelor.
Ça pourrait faire un bel article sur LinuxFR ça : Je ne sais pas quel est ton rôle là dedans, mais une entreprise industrielle qui fait le choix d'une solution open-source encore naissante (Axelor), puis qui semble développer ce cadriciel taack aussi en open-source, ça serait intéressant d'en savoir plus :)
Désolé pour ta question sur les licences, il y aura certainement des esprits plus éclairés pour y répondre convenablement, mais cela pique ma curiosité !
[^] # Re: statut salarié
Posté par YBoy360 (site web personnel) . Évalué à 5. Dernière modification le 12 avril 2024 à 13:08.
Ce n'est pas le sujet. Mais oui, de quoi faire. Il y a même du macabre.. Je suis celui ayant choisi Axelor. T'en sais déjà trop.
On va éviter de trop creuser.
[^] # Re: statut salarié
Posté par volts . Évalué à 4.
T'as combien sur ton banque bancaire pour pouvoir acheter le silence de toutes les moules ici présentes ? 😈
[^] # Re: statut salarié
Posté par YBoy360 (site web personnel) . Évalué à 3.
Ololo, non seulement je suis a découvert, mais en plus mon encours est supérieure à ce que j'ai en début de mois, mais mes dépenses mensuelle devraient diminuer… On attends le mois prochains, si tu veux.
# L’audace c’est ça
Posté par Marotte ⛧ . Évalué à 3.
Annoncer son logiciel sans mettre de lien (à part ton site perso associé à ton pseudo peut-être), c’est la première fois que je vois ça. Je salue la performance. Un peu frustrant pour le lecteur mais ça rend indéniable la confiance que tu as dans ton travail, et suggère donc celle qu’on peut espérer en tant qu’utilisateur ;). Bravo !
Le site c’est https://taack.org/en je suppose ? Il a l’air UP now. Bien.
[^] # Re: L’audace c’est ça
Posté par YBoy360 (site web personnel) . Évalué à 1.
Les 3 mots importants étaient "pour le moment".
[^] # Re: L’audace c’est ça
Posté par Marotte ⛧ . Évalué à 3.
Pas les plus importants àma mais je les avais bien vu, je maintiens mon commentaire. :)
J’espère que tu ne l’as pas mal pris, c’était pas le but, c’était un… commentaire. Si tu l’as mal pris je joins la présentation de mes excuses au renouvellement de mes félicitations.
# De la condition de dinosaure
Posté par Marotte ⛧ . Évalué à 7. Dernière modification le 12 avril 2024 à 22:00.
C’est pas une critique, juste une constatation. Je trouve que le développement web est devenu une sacrée usine à gaz, on dit aussi « cathédrale » quand on veut être plus positif. On constate que le cadriciel que tu proposes, Taack-UI est :
Basé sur Grails, lui-même basé sur Groovy, lui-même destiné à la création d’application SpringBoot, qui lui-même repose sur l’écosystème Java. Et bien sûr je suppose qu’au final ça ne crée pas des applications dites « natives » donc on a pour les fondations XHTML et Javascript. (sous réserve que je ne dis pas trop de conneries, vous me corrigerez).
On a quand même quatre cadriciels empilés (Taack, Grails, Groovy et SpringBoot). C’est peut-être totalement injustifié et passablement idiot, et certainement intuitif car je ne suis pas développeur, mais je trouve que ça part un peu en mode inception… ^^
[^] # Re: De la condition de dinosaure
Posté par YBoy360 (site web personnel) . Évalué à 2.
Pour déterminer si c'est une usine à gaz, ou à bière, je t'invite à me trouver des sites plus rapide à afficher que citel.fr, ou obsta.com, par exemple, qui sont des extranets basé sur ce FW (avec portail clients et tutti..).
Bref, pas tant que ça…
[^] # Re: De la condition de dinosaure
Posté par BAud (site web personnel) . Évalué à 2.
ah bah — forcément — un FireWall ça aide à répondre plus rapidement :-)
/me qui en a marre des abréviations ~~~> [ ]
c'est si long à écrire cadriciel ? cf. traductions-classiques
[^] # Re: De la condition de dinosaure
Posté par YBoy360 (site web personnel) . Évalué à 3.
FW c'est FrameWork (cadriciel en FR).
Je n'ai pas dit que ce FW est léger, ni mieux, ni pire, voila…
[^] # Re: De la condition de dinosaure
Posté par BAud (site web personnel) . Évalué à 2. Dernière modification le 13 avril 2024 à 00:22.
à ajouter sur FW et FW qui ne le connaissent pas ;-)
je ne dis pas le contraire
ah mais, si en plus il est intégré à LibreOffice, ce sera bienTM :-)
[^] # Re: De la condition de dinosaure
Posté par Marotte ⛧ . Évalué à 0.
Le contexte ici rendait évident le sens de FW, si même moi j’ai compris sans difficulté ! Mais de manière générale, hormis des acronymes absolument communs, comme TGV ou RATP (pour des interlocuteurs français), ou UV (si le contexte ne laisse aucun doute), j’ai du mal avec les acronymes. Le dernier en date, je n’ai pas trouvé en cherchant cinq minutes sur le web au point de demander à la personne l’ayant utilisé de me le traduire. Celle-ci l’a fait, en s’excusant, ce que je ne trouve pas utile mais qui me laisse penser qu’elle a bien conscience que ça peut être pénible pour les autres :
ADR (je vous laisse la devinette pour ceux qui ne savent pas, c’est un objet relativement lié à l’informatique mais qui peut probablement se trouver dans d’autres domaines).
[^] # Re: De la condition de dinosaure
Posté par jmiven . Évalué à 2. Dernière modification le 15 avril 2024 à 10:19.
C'est sûr qu'il ne faut pas s'attendre à un miracle avec un sigle de trois lettres, mais ajouter un mot ou deux de contexte règle généralement le problème pour moi. Là c'est parce que je m'attendais à un sigle anglais, mais une recherche en français fonctionne aussi, même si c'est un peu noyé dans les résultats transport :)
Ceci dit, oui bien sûr, introduire le sens d'un sigle quand il n'est pas d'usage courant dans la situation reste une bonne idée.
[^] # Re: De la condition de dinosaure
Posté par Marotte ⛧ . Évalué à 3. Dernière modification le 16 avril 2024 à 01:03.
Alors perso quand je clique sur le lien que tu as mis je tombe effectivement sur du jargon de la guilde des conducteurs de charrettes à beauf, sauf que dans mon cas c’était ce qui arrive en 2e ou 3e lien (en tous cas chez moi et possiblement parce que je l’ai recherché il y a quelques jours afin de m’assurer que j’allais pas écrire un connerie ^^).
ADR signifie, en matière d’organisation du travail, en particulier le développement logiciel, mais ça ratisse large : Architecture Decision Record, ça consiste simplement à tenir un journal de toutes les décisions qu’une équipe, un service, une société secrète, bref n’importe qu’elle organisation, peut prendre au fil du temps, en y consignant les tenants et aboutissants de telle et telle décision, de tel et tel choix. En fait de les mettre toutes systématiquement c’est ça l’idée.
On dirait presque que de brillants esprits de ce siècle ont affublé d’un terme 2.0 une pratique probablement aussi vieille que la collaboration humaine elle-même, depuis l’avènement de l’écriture. On pourrait croire qu’ils tentent de faire passer ça pour une innovation toute récente, méritant au minimum une formation avec des spécialistes, pour saisir ce concept si novateur…
[^] # Re: De la condition de dinosaure
Posté par Marotte ⛧ . Évalué à 4.
Ceci dit il est vrai que si tu ne pratiques pas couramment l’acronyme aujourd’hui t’es foutu :
L’Europe tu l’aimes ou tu la transcris !
[^] # Re: De la condition de dinosaure
Posté par Marotte ⛧ . Évalué à 4. Dernière modification le 16 avril 2024 à 01:28.
J’avoue que je ne suis pas très doué mais d’un autre côté bien que ce fusse un informaticien qui nous ait gratifié (on pourrait dire éduqué) avec cette acronyme anglophone et que pour ma part je trouve un poil pompeux par rapport à « Journal de l’architecture », « Historique », voire "Main courante", ou plus évident : « Historique des choix pour l’architecture ».
si on doit en arriver à normaliser ce genre de truc pour produire un travail, de la documentation, de qualité, c’est qu’on est vraiment devenu des des robots, des clones.
Je note dans mon MNTR (Miscellaneous Noticiable Thought Record) que les humains se métamorphosent en moutons, c’est positif, la transformation en cafard semble aujourd’hui relever de l’histoire ancienne.
[^] # Re: De la condition de dinosaure
Posté par Marotte ⛧ . Évalué à 4.
Ça c’est une chose mais je pensais surtout à la complexité pour le développement et la maintenance. Un framework a bien pour but de faciliter le développement. On échange la tâche d’écrire et maintenir un code « évident » représentant une valeur ajoutée inférieure à celle du code plus spécifique que l’on développe, contre quelques contrainte du framework choisi (rythme des mises à jour, choix techniques). C’est évidement bien souvent un choix parfaitement judicieux, et j’aurais même tendance à dire que pour un site « avec tutti quanti » comme tu dis, c’est indispensable de recourir à un, voire plusieurs frameworks pour arriver à un résultat satisfaisant.
Je me demande juste si à en utiliser trop, potentiellement assez différenciés dans leur approche/architecture (je ne dis pas que c’est le cas des frameworks que tu utilises, je n’en sais rien), le gain effectif, en performance de l’application comme en temps de développement et de maintenance, ne finit pas par devenir négatif.
Rapide, je confirme. Et sans recours à 36 sites externes, juste deux CDN, aujourd’hui c’est devenu presque rare de ne pas en avoir plus, et des trackers, etc… C’est mon impression en tous cas. Ça pourrit bien les temps de réponse souvent (là aussi, alors qu’un CDN permet généralement de les améliorer, c’est l’un de ses buts).
[^] # Re: De la condition de dinosaure
Posté par barmic 🦦 . Évalué à 2.
Pas simple, il peut :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: De la condition de dinosaure
Posté par abriotde (site web personnel, Mastodon) . Évalué à 3.
Qu'il y ait plusieurs couches n'est pas forcément usine à gaz si chacune apporte quelque chose. Quelques part c'est plus KISS puisque les projets sont indépendant et chacun apporte un petit plus..
Un empilement de couches n'est pas forcément toujours utiles mais là en l’occurrence, cela me semble justifié.
Groovy est juste un langage qui tourne sur JVM pour bénéficier de l’interopérabilité et de la compatibilité avec tout ce qui existe en Java. Parmi les lib Groovy il y a Grails et c'est juste celle qui est utilisé. Ce n'est donc pas un empilement extraordinaire.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: De la condition de dinosaure
Posté par barmic 🦦 . Évalué à 5.
Groovy est un langage de programmation et si j'ai bien compris Grails se veut être la façon sympa d'utiliser Spring quand on veut utiliser groovy. Ça ne m'a pas l'air plus compliqué que ça.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Zone juridique
Posté par Marotte ⛧ . Évalué à 4. Dernière modification le 12 avril 2024 à 22:31.
Il me semble qu’en France, bien que deux parties puissent souscrire à un contrat (ce qu’est une licence logicielle au final) rédigé dans une autre langue que le français c’est tout à fait légal, cependant, en cas de litige le jury peut exiger une traduction, et une traduction en français, une traduction « assermentée », et paraît-il que ça coûte bonbon (à la partie qui perd le procès ou à celle qui a rédigé le contrat* ça je ne sais pas). Or, je peux me tromper mais je sais que la GPL, v2 comme v3, n’est pas traduite en français et n’a pas vocation à l’être, donc si un contrat commercial repose en partie sur elle, ou plus largement pour faire valoir ses clauses, ça peut (ce n’est qu’une probabilité faible certes) poser problème.
Je ne sais pas si la licence Apache, ou d’autres, ont des traductions. Mais je sais que la langue anglaise des licences libres disponibles il y a 20 faisait partie des principale motivations ayant conduit à la création de la CeCILL par des organismes de recherche français.
Il me semble que l’usage c’est au minimum de lister dans un fichier toutes les licences impliquées et à quel composant elles correspondent.
Ensuite, mais là je n’émet que des hypothèses, pour ce qui concerne build et tests c’est limité au simple usage des logiciels et n’a donc probablement aucune influence sur le logiciel que tu produis/publies avec aucune licence reconnue par l’OSI. Pour ce qui est du runtime, pas sûr que ce soit différent.
Donc à mon humble avis c’est cette licence là qui peut avoir le plus d’influence sur le choix que tu dois faire mais je la connais trop mal pour donner un quelconque avis. Si j’étais décideur pressé (Ô Satan mon âme est tienne si tu m’épargnes ce triste sort !) je dirais :
Certainement un bon choix de viser à être ton propre décideur, tu peux au moins décider de ton rythme. ^^
[^] # Re: Zone juridique
Posté par YBoy360 (site web personnel) . Évalué à 1.
Merci, le mieux est l'ennemi du bien… ça me parait compliqué dans mon cas de mettre une licence moins restrictive (avec plus de liberté), ce serait une sorte de contamination inverse du cadriciel de base….
Donc choisir la même licence me parait pas forcément dénué de sens. D'autant plus qu'une partie du code doit être adaptée par l'utilisateur final (Crew par exemple, mais aussi les autres modules), et la licence Apache v2, dans ce cas, peut-être pertinente. J'aime que la configuration soit dans le code (définition des filiales par exemple, des monnaies, des langues supportées…), donc redistribué ça n'a pas de sens.
Pour l'apposition de la licence, je pense devoir l'ajouter à tous les fichiers en en-tête, pour commencer. Pas forcément tout traduire. Mais à voir… Je me rappelle juste de Windows 2000 et ses dll contenant la licence BSD, c'était en anglais uniquement.
Et enfin, pour info, je ne suis pas vraiment en danger niveau taff et financier, ça va. J'ai plus envie de faire ça pendant un temps tout en aidant lorsque c'est nécessaire, pour éviter la surcharge. Merci pour ce commentaire en tout cas.
[^] # Re: Zone juridique
Posté par Marotte ⛧ . Évalué à 4.
Je me demandais aussi si du code de ton cadriciel pouvait éventuellement intéresser un jour les auteurs du cadriciel de base, pour remonter d’un niveau en quelque sorte. Dans ce cas il me semble qu’une licence moins restrictive, typiquement, BSD, empêcherait que ça puisse se faire (sans devoir changer de licence), du moins que tu doives de fait publier ce bout de code sous les deux licences, ça paraît compliqué.
Ça ferait en tous cas un mélange de licence bien bordélique et n’ayant potentiellement plus aucun sens. Puisque le code sous la première licence doit rester sous celle-ci (sauf si l’auteur du code en question permet qu’il n’en soit pas ainsi). Mais bon, je ne connais pas la licence Apache en détail.
C’est pratiquement la seule obligation de la licence BSD, pour la redistribution des sources comme des binaires. Et avec l’interdiction d’utiliser le nom de l’université ou des auteurs pour faire de la publicité, c’est tout (en tous cas depuis 1999). Elle a le mérite d’être simple c’est indéniable. :)
[^] # Re: Zone juridique
Posté par Marotte ⛧ . Évalué à 3.
À moins que la licence Apache ait une clause qui fasse que les clauses de la BSD puissent être respectées si je ne m’abuse.
[^] # Re: Zone juridique
Posté par BAud (site web personnel) . Évalué à 4. Dernière modification le 14 avril 2024 à 22:35.
Pour préciser : seule la BSD-4 clause inclut la clause de publicité (pour un projet libre : à éviter, généralement, car complique la mise en application et la réutilisation) :
https://choosealicense.com/licenses/bsd-4-clause/
la BSD-3 clause est pas mal et (suffisamment) légitime
la BSD-2 clause se rapproche de la licence MIT
# Marche à suivre
Posté par Sébastien Dinot (site web personnel) . Évalué à 8.
Bonjour,
Savoir si tu es à ton propre compte ou non ne suffit pas à déterminer si tu es en droit de décider de la licence de ton cadriciel, ni même de sa publication. Par exemple, si tu as développé ce cadriciel dans le cadre d'un contrat de prestation qui prévoit la cession des droits patrimoniaux à ton client (cas de figure assez fréquent), la décision appartient entièrement à ton client, et il n'a aucunement à te consulter ou à obtenir ton approbation pour cela.
Si ce n'est pas le cas (i.e. si tu as développé ce cadriciel de ta propre initiative, en le finançant sur fonds propres, ou si le contrat de prestation ne prévoit pas la cession des droits patrimoniaux), tu es en droit de décider de publier ton cadriciel sous licence libre.
La licence choisie doit être compatible avec celles des composants intégrés. Il faut donc commencer par établir leur liste. Selon les langages considérés et les outils disponibles, cette liste en profondeur – que l'on appelle un « Software Bill of Materials » (SBOM) ou « Software Supply Chain » – peut être établie de manière automatique ou non. De nos jours, il est de bon ton de publier ce SBOM au format CycloneDX. Publier le SBOM va même devenir une obligation en Europe avec la publication récente du « Cyber Resilience Act » (CRA).
Je ne l'ai jamais utilisé, mais je sais qu'un greffon Maven permet effectivement d'établir la liste exhaustive et en profondeur des composants intégrés. En effectuant une recherche rapide, je suis tombé sur l'article How to create SBOMs in Java with Maven and Gradle.
Si aucun des composants intégrés n'a de licence plus exigeante que la licence permissive Apache v2.0, tu peux décider de diffuser ton cadriciel sous cette licence ou sous une licence diffusive (faiblement, comme la licence GNU LGPL ou fortement, comme la licence GNU GPL). S'agissant d'un cadriciel, je déconseille le recours à une licence fortement diffusive qui dissuaderait beaucoup de personnes de l'utiliser (cette licence se diffusant alors à leur propre application), mais ce choix peut être une stratégie assumée.
La licence Apache v2.0 exige qu'une copie de la licence soit fournie à la racine du projet, dans un fichier nommé LICENSE(.txt), ainsi qu'un fichier NOTICE(.txt) contenant la liste des composants intégrés (liste de premier niveau, ceux que tu utilises explicitement et non ceux qui se trouvent intégrés en cascade, du fait des dépendances de dépendances).
Il est ensuite de bon ton de placer à la racine du projet un fichier README(.txt|.md|.rst) dans lequel tu auras inséré une mention de copyright et de licence (en renvoyant vers le fichier LICENSE(.txt).
Pour terminer, il est recommandé de placer une entête de copyright au début de chaque fichier dont le format le permet. Pour la licence Apache, cet entête peut être :
À ce stade, tu commences à avoir fait les choses plutôt bien. Reste éventuellement à choisir une licence différente et plus adaptée pour la documentation, les exemples et les ressources tierces. Pour plus d'informations à ce sujet, cf. mon article Projet libre : à chaque ressource sa licence.
[^] # Re: Marche à suivre
Posté par Sébastien Dinot (site web personnel) . Évalué à 3.
J'oubliais, il est recommandé d'exclure du SBOM les composants qui ne sont utilisés qu'en phase de développement (JUnit par exemple) et ne sont pas liés aux versions de ton outil distribuées sous forme binaire.
Cf. un exemple de SBOM au format CycloneDX pour un composant Java :
https://github.com/CycloneDX/bom-examples/blob/master/SBOM/dropwizard-1.3.15/bom.xml
[^] # Re: Marche à suivre
Posté par YBoy360 (site web personnel) . Évalué à 1.
Merci pour toutes ces informations. Il y a un point que j'ai omis de préciser : Certains modules sont sur Maven (Taack-UI et le composant JDBC), là, on y coupe pas, il faut étudier dépendance par dépendance, donc on peut mettre certains service en GPLv3, et laisser le reste en Apache v2.
Par contre les plugins comme Crew, et les autres apps qui arriveront auront très peu de dépendances directes. Je peux mettre en (L?)GPL v3 les service qui devraient être immuables chez les utilisateurs. Laisser le reste en Apache v2 pour ne rien imposer d'ennuyeux.
Une question :
Grandement merci pour ton aide !
[^] # Re: Marche à suivre
Posté par Sébastien Dinot (site web personnel) . Évalué à 1. Dernière modification le 13 avril 2024 à 18:06.
Ne connaissant rien à Java et aux composants évoqués, ce que tu écris reste assez opaque pour moi. Il me faudrait un petit diagramme d'architecture.
Pour commencer, à ma connaissance, Maven est un outil de gestion des dépendances et d'automatisation du build, et d'aucune manière un composant lié à l'exécutable généré. Sa licence importe donc peu ici.
Ensuite, il me semble que JDBC est une simple abstraction, une interface définissant une API utilisée par les applications Java pour se connecter à des bases de données. Cette API est incluse dans la plateforme standard (sauf erreur de ma part, on la trouve donc aussi bien dans OracleJDK que dans OpenJDK). Mais cette interface ne permet rien en elle-même. Il faut ajouter un connecteur (« driver »), spécifique à chaque SGBDR. C'est donc la licence de ce connecteur qui importe. Quel SGBDR, et donc quel connecteur, utilises-tu ?
Oui ou non. Cela dépend de la licence des différents composants, de leur assemblage et de leur mode d'interaction.
Je ne sais pas ce qu'est un service immuable.
Par contre, ce que je peux te dire, c'est que si la compilation de ton code aboutit à la génération de composants diffusés sous des licences différentes, tu as intérêt, pour le bien de tout le monde à commencer par le tien, à scinder le code desdits composants dans plusieurs dépôts et à les gérer séparément. Ton projet sera bien plus lisible sur le plan juridique.
[^] # Re: Marche à suivre
Posté par YBoy360 (site web personnel) . Évalué à 3.
Java est une plateforme, et pas seulement un langage :
Gradle gère tout un tas de choses, peut être étendu, générer du code ou autres.
Donc, sans parler du composant JDBC ou de l'architecture, j'ai maintenant suffisamment d'éléments. La bonne solution est de regarder du coté des imports et de tester les plugins que vous m'avez décrit. Merci à vous.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.