Quali file di progetti NetBeans devono essere inseriti nel controllo del codice sorgente?

Normalmente utilizziamo Eclipse per un particolare progetto Java, ma recentemente ho importato il progetto in NetBeans per utilizzare le sue funzionalità di creazione di finestre di dialogo.Quali file di progetti NetBeans devono essere inseriti nel controllo del codice sorgente?

Poiché probabilmente tornerò su questo, volevo memorizzare i file di progetto NetBeans nel controllo di versione. Tuttavia, non voglio trasferire file che sono "miei" o "progetti", cioè file con le mie impostazioni personali che potrebbero entrare in conflitto con un altro utente.

NetBeans creato la seguente struttura nella zona di progetto di primo livello:.

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

Chiaramente nbbuild è costruire in uscita, in modo che non andrà nel file nb-build.xml sembra probabile, come fa la maggior parte di nbproject. Tuttavia, nbproject/private suggerisce che è "mio". Sbirciando a "configs", non è chiaro per me se questo è il mio o il progetto ...

Qualcuno ha alcune linee guida?

fonte

2009-08-12 Peter Cardona

Il NetBeans knowledge base article on project files & version control discute i file di progetto NetBeans, con consigli sciolti su quali file sono specifici del progetto (cioè possono essere condivisi tramite controllo di versione) e quali sono specifici dell'utente.

Qui è la sezione sul controllo di versione:

Se il progetto viene controllato da un sistema di controllo di versione, le build (o nbbuild), dist (o nbdist), e il nbproject/private cartelle non dovrebbe essere controllato in quel sistema di controllo della versione.

Se il progetto è sotto i sistemi di controllo versione CVS, Subversion o Mercurial, i file "ignorati" appropriati vengono creati o aggiornati per queste directory quando il progetto viene importato.

Anche se nbproject/private deve essere ignorato, nbproject deve essere controllato nel sistema di controllo versione. nbproject contiene metadati di progetto che consentono ad altri utenti di aprire il progetto in NetBeans senza dover prima importare il progetto.

fonte

2009-08-12 17:32:37

L'inchiostro fornito è rotto. Rende essenzialmente questa risposta inutile. – Kenneth

Trovata una copia del collegamento archiviato all'indirizzo https://web.archive.org/web/20090216193025/http://www.netbeans.org/kb/docs/java/import-eclipse.html. – Nathan2055

Che dire di 'nbactions.xml'? –

Nessuno.

Solo i file di origine, gli script di compilazione e la documentazione che non viene generata automaticamente (ad es. L'output di strumenti come JavaDoc e Doxygen) devono essere controllati in un repository. Cose come file di progetto, file binari e documentazione generata non devono essere archiviati.

Il motivo è duplice. Innanzitutto, non vuoi sovrascrivere le impostazioni del progetto di un altro sviluppatore con le tue. In secondo luogo, altri sviluppatori potrebbero non utilizzare lo stesso IDE come te (o addirittura un IDE), quindi non dare loro più del necessario (il progetto o la documentazione associata) o eseguire il progetto.

fonte

2009-08-12 17:01:02

Evidentemente non aggiungerà output di compilazione (inclusi JavaDocs). Ma dubito che la risposta migliore sia "nessuno". Ogni sviluppatore dovrebbe quindi configurare localmente le impostazioni di progetto comuni, incluse le cose semplici come quali dir sono l'origine o il livello di JDK da creare. Non condividere quel tipo di informazioni sulla configurazione del progetto ci avrebbe creato problemi. Ad esempio, scrivo codice che funziona per 1.6 ma il nostro progetto viene fornito per 1.5. Lo commetto e rompere la build. –

Quando importare un progetto con Eclipse, per me è banale identificare le directory di origine e il JDK da creare. Inoltre, dovrebbe esserci uno script di compilazione che lo faccia per me, dal momento che potrei non utilizzare affatto un IDE (ma piuttosto un editor di testo: Notepad ++, emacs, vim). Ogni lavoro che ho mai utilizzato per il controllo del codice sorgente ha impegnato solo file di origine e documentazione generata dall'uomo nel repository e non ho mai visto un problema. –

Non sono d'accordo con questo. Penso che renda le cose molto più semplici se tutti gli sviluppatori di un progetto utilizzano lo stesso IDE e la stessa versione. I file di progetto devono essere archiviati - significa che ogni dev non deve saltare attraverso i circuiti che impostano il proprio ambiente ogni volta che devono lavorare sulla sorgente. Se tutti esaminano progetti e progetti dipendenti e JAR nella stessa posizione o struttura del percorso relativo, dovrebbero essere in grado di eseguire il checkout e fare clic su build in un unico passaggio. troppo tempo se tutti devono riconfigurare un progetto e correggere le dipendenze interrotte tutto il tempo –

Si scopre che entrambi Thomas & Petercardona sono corretti, in un certo senso. NetBeans consiglia di importare solo codice sorgente e/o documentazione. Oh e la cartella nbproject ma non le cartelle * nbproject/private **.

Dal NetBeans Knowledge Base article on importing Eclipse projects:

Considerazioni controllo della versione

Se il progetto viene controllato da un sistema di controllo versione, build (o nbbuild), dist (o nbdist), e le cartelle nbproject/private non devono essere controllate nel sistema di controllo versione .

Se il progetto è sotto il CVS, Subversion , o Mercurial sistemi di controllo versione , i file "ignora" appropriate vengono creati o aggiornati per queste directory quando il progetto viene importato.

Anche se nbproject/privato dovrebbe essere ignorato , nbproject deve essere controllato nel sistema di controllo di versione. nbproject contiene i metadati del progetto che consentono ad altri utenti di aprire il progetto in NetBeans senza dover importare prima il progetto da .

fonte

2009-08-25 12:26:52

Questo è lo stesso link che ho postato sopra, no? Penso che ci sia una distinzione tra * importazione * solo sorgente e * verifica in * file di progetto. Mentre lo leggevo, il primo significa portare i file nell'IDE di NetBeans, quest'ultimo significa mettere i file nel controllo della versione e include i file di installazione del progetto. La mia domanda riguardava quest'ultima. Voglio condividere i file che controllano il modo in cui viene prodotta la build (posizioni jar standardizzate, livello jdk), ma non controllano cose come le preferenze di formattazione, i layout delle finestre IDE, ecc. –

Come testato con Netbeans 6.8, solo il project.xml, configurations.xml e il makefile principale (quello personalizzabile nella directory principale della 'nbproject' dir, con le definizioni di riferimento pre/post) deve essere distribuito tramite il repository. Tutti gli altri file verranno automaticamente (ri) generati da Netbeans (Makefile-impl.ml, Makefile-variables.ml, tutti gli Makefile-$CONF, Package-$CONF.bash). Anche la dir 'privata' dovrebbe essere ignorata, ovviamente.

fonte

2009-12-20 01:09:22

Quali file di progetti NetBeans devono essere inseriti nel controllo del codice sorgente?

risposta

Problemi correlati