On 02/10/2017 02:39 AM, oStorybook wrote:
Non, justement, ce "nouveau" code permet de se détacher encore plus de
Netbeans et de faire abstraction de ses outils. Je vais adopter la
démarche qui consiste, pour des nouvelles interfaces, à utiliser les
outils Netbeans durant la mise au point, puis de convertir selon les
principes adoptés ailleurs dans le code.
Quant aux dossiers "nbproject" ".dist" ".settings" je viens de les
exclure du GIT.
Grand Merci ! Ce genre de choses aidera beaucoup les gens à entrer dans
le projet (comprendre l'organisation du repository est simplement
impossible).
En fait ce qui me dérangeait c'est moins d'avoir des dépendances que de
ne pas savoir les modifier sans effet de bord possible.
Exemple: Si le build.xml dépend d'un second xml généré automatiquement
par une appli X utilisée par un développeur, il est impossible de savoir
ce qui est faisable ou non sur ce second fichier:
Si je le modifie pour le rendre lisible, est-ce que les modifs ne seront
pas à nouveau écrasées "automatiquement" par X lors d'un commit à venir
? Ou est-ce que mes modifs seront prises en compte par le logiciel X ?
Impossible à deviner à priori.
En fait ceci est le cas pour tous les fichiers qui ne sont pas la vraie
"source".
Dans le répertoire "doc", il y a un PDF. Si je le modifie, rien ne dit
que mes modifs ne seront pas écrasées, car, évidemment, il a été généré
par un logiciel spécifique qui a le vrai "source" du PDF.
Ou autrement dit (je mets le lib.zip de côté pour l'instant) : Tout
fichier du repository "source" (notre code.git) est supposé être
modifiable par tous, car il est supposé justement être "le" fichier
source (dans le sens "fichier d'origine" : Un ".odt" pour une doc me
semble valide, bien que ce ne soit qu'un "blob" techniquement parlant,
comme l'est un ".pdf", qui pourtant me convainc beaucoup moins).
br, pas certain d'être clair :-)