54 votes

Quels fichiers de projets NetBeans doivent être placés dans le contrôle de la source ?

Nous utilisons normalement Eclipse pour un projet Java particulier, mais j'ai récemment importé le projet dans NetBeans pour utiliser ses fonctions de création de dialogues.

Comme je vais probablement y revenir, je voulais stocker les fichiers du projet NetBeans dans le contrôle de version. Cependant, je ne veux pas commiter des fichiers qui sont "les miens" par rapport au "projet", c'est-à-dire des fichiers avec mes propres paramètres qui entreraient en conflit avec ceux d'un autre utilisateur.

NetBeans a créé la structure suivante dans la zone de projet de premier niveau :

nbbuild
nb-build.xml
nbproject
    <various files>
    configs
    private

Clairement nbbuild est une sortie de construction, donc ça n'entrera pas. Le site nb-build.xml semble probable, comme la plupart des nbproject . Cependant, nbproject/private suggère que c'est "le mien". En jetant un coup d'oeil à "configs", je ne sais pas si c'est le mien ou celui du projet...

Quelqu'un a-t-il des directives à donner ?

57voto

Peter Cardona Points 1109

El Article de la base de connaissances NetBeans sur les fichiers de projet et le contrôle de version traite des fichiers du projet NetBeans, avec des conseils vagues sur les fichiers spécifiques au projet (c'est-à-dire qui peuvent être partagés via le contrôle de version), et ceux qui sont spécifiques à l'utilisateur.

Voici la section sur le contrôle de version :

Si le projet est extrait d'un système de contrôle de la version, l'adresse de l'utilisateur est la suivante build (o nbbuild ), dist (o nbdist ), et le nbproject/private ne doivent pas être enregistrés dans ce système de contrôle de version.

Si le projet est sous les systèmes de contrôle de version CVS, Subversion ou Mercurial, les fichiers "ignore" appropriés sont créés ou mis à jour pour ces répertoires lorsque le projet est importé.

Bien que nbproject/private doivent être ignorés, nbproject doit être enregistré dans le système de contrôle de version. nbproject contient les métadonnées du projet qui permettent aux autres utilisateurs d'ouvrir le projet dans NetBeans sans avoir à importer le projet au préalable.

4 votes

L'encre fournie est cassée. Cela rend essentiellement cette réponse inutile.

2 votes

J'ai trouvé une copie du lien archivé à web.archive.org/web/20090216193025/http://www.netbeans.org/kb/ .

1 votes

Qu'en est-il nbactions.xml ?

19voto

Richard Hurt Points 985

Il s'avère que Thomas et Petercardona ont tous deux raison, d'une certaine manière. NetBeans recommande de n'importer que le code source et/ou la documentation. Oh et le nbproject mais pas les dossiers *nbproject/private**.

De la Article de la base de connaissances NetBeans sur l'importation de projets Eclipse :

Considérations sur le contrôle des versions

Si le projet est extrait d'un système de contrôle de version, le build (ou nbbuild), dist (ou nbdist), et l'attribut nbproject/private ne doivent pas être enregistrés dans ce système de contrôle de version. de version.

Si le projet est sous le CVS, Subversion, ou Mercurial de version, les fichiers fichiers "ignore" appropriés sont créés ou mis à jour pour ces répertoires lorsque le projet est importé.

Bien que nbproject/private devrait être ignorés, nbproject devrait être vérifié dans le système de contrôle de la version. nbproject contient les métadonnées du projet qui permettent à d'autres utilisateurs d'ouvrir le fichier projet dans NetBeans sans avoir à importer le projet au préalable.

2 votes

C'est le même lien que j'ai posté plus haut, non ? Je pense qu'il y a une distinction entre Importation de seule source et l'enregistrement les dossiers de projets. D'après ce que j'ai lu, le premier consiste à introduire les fichiers dans l'EDI NetBeans, le second à les placer dans le contrôle de version et à inclure les fichiers de configuration du projet. Ma question concernait le dernier point. Je veux partager des fichiers qui contrôlent la façon dont la compilation est produite (emplacements de jar standardisés, niveau de jdk), mais qui ne contrôlent pas des choses comme les préférences de formatage, la disposition des fenêtres de l'EDI, etc.

2voto

Thomas Owens Points 45042

Aucun.

Seuls les fichiers sources, les scripts de compilation, et la documentation qui n'est pas générée automatiquement (par exemple - la sortie d'outils tels que JavaDoc et Doxygen) doivent être archivés dans un référentiel. Les choses comme les fichiers de projet, les binaires et la documentation générée ne doivent pas être archivées.

La raison est double. Premièrement, vous ne voulez pas écraser les paramètres du projet d'un autre développeur avec les vôtres. Deuxièmement, les autres développeurs peuvent ne pas utiliser le même IDE que vous (ou même un IDE tout court), donc ne leur donnez pas plus que ce dont ils ont besoin pour construire (le projet ou sa documentation associée) ou exécuter le projet.

9 votes

Il est clair que nous n'allons pas ajouter les résultats de la construction (y compris les JavaDocs). Mais je doute que la meilleure réponse soit "aucune". Chaque développeur devrait alors configurer localement les paramètres communs du projet, y compris des choses simples comme les répertoires des sources, ou le niveau du JDK pour lequel il faut construire. Ne pas partager ce genre d'informations sur la configuration du projet nous mettrait en difficulté. Par exemple, j'écris du code qui fonctionne pour 1.6 mais notre projet est livré pour 1.5. Je fais un commit et je casse la compilation.

0 votes

Lorsque j'importe un projet avec Eclipse, il est trivial pour moi d'identifier les répertoires sources et le JDK à compiler. D'ailleurs, il devrait y avoir un build script qui fait cela pour moi, puisque je n'utilise peut-être pas du tout un IDE (mais plutôt un éditeur de texte - Notepad++, emacs, vim). Tous les emplois que j'ai eus qui utilisaient le contrôle de la source n'engageaient que les fichiers sources et la documentation générée par l'homme dans le référentiel et je n'ai jamais vu de problème.

6 votes

Je ne suis pas d'accord avec ça. Je pense que cela rend les choses beaucoup plus faciles si tous les développeurs d'un projet utilisent le même IDE et la même version. Les fichiers du projet devraient être archivés - cela signifie que chaque développeur n'a pas à faire des pieds et des mains pour configurer son environnement chaque fois qu'il a besoin de travailler sur les sources. Si tout le monde enregistre les projets, les projets dépendants et les JARs au même endroit ou dans la même structure de chemin relatif, alors ils devraient être en mesure d'extraire et de construire en une seule étape. Trop de temps est perdu si tout le monde doit re-configurer un projet et réparer des dépendances cassées tout le temps.

2voto

bohan Points 522

Telle que testée avec Netbeans 6.8, seule l'option project.xml , configurations.xml et le makefile principal (celui qui est personnalisable et qui se trouve dans le répertoire parent de l'application 'nbproject' dir, avec des définitions de pré/post cible) doit être distribué via le référentiel. Tous les autres fichiers seront automatiquement (re)générés par Netbeans ( Makefile-impl.ml , Makefile-variables.ml tous les Makefile-$CONF , Package-$CONF.bash ). Le répertoire "privé" doit également être ignoré, évidemment.

0voto

Yajli Maclo Points 926

Vous pouvez également vérifier
https://github.com/github/gitignore/blob/master/Global/NetBeans.gitignore

Ce projet open source contient
Une collection d'informations utiles .gitignore modèles

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X