2009-03-13 23 views
1

Ich habe endlich geschafft, ein Netbeans-Projekt aus einer alten eigenständigen (nicht Web-) Java-Anwendung, die nur aus einzelnen .java Quellen bestand. Jetzt habe ich im Grunde zwei Fragen in Bezug auf Netbeans Subversion Interaktion und Bereitstellung von Anwendungen:Deploy Java (Befehlszeile) App mit Netbeans/ant

  1. Kontrollieren Sie, in allen Netbeans Projektdateien in das Repository, in der Regel?

  2. Wenn ich das Projekt mit Netbeans (oder ant) ​​erstellen, erhalte ich eine .jar-Datei und einige zusätzliche Jar-Bibliotheken. Damit die App ordnungsgemäß auf dem Server ausgeführt werden kann, sind einige zusätzliche Konfigurationsdateien und -verzeichnisse (z. B. log /) erforderlich. Die Anwendung selbst ist eine J2SE-Anwendung (keine Frameworks), die von der Befehlszeile auf einer Linux-Plattform ausgeführt wird. Wie würden Sie eine solche Anwendung bereitstellen und installieren? Es wäre auch schön, wenn ich sehen könnte, welche Version der App derzeit installiert ist (möglicherweise durch Anhängen der Versionsnummer an den installierten App-Pfad).

Danke für irgendwelche Tipps.

Antwort

2
  1. Nein, normalerweise nicht. Alles, was für NetBeans (oder Eclipse, IntteliJ usw.) spezifisch ist, checke ich nicht ein; versuche es mit dem ant-Skript von der Kommandozeile aus zu erstellen und produziere genau das, was du willst. Die build.xml ist etwas, das für andere IDEs oder in Verbindung mit Anthill oder CruiseControl für automatisierte Builds/kontinuierliche Integration verwendet werden kann, sodass diese eingecheckt werden sollten. Überprüfen Sie, was zur Herstellung/Erstellung Ihrer Artefakte benötigt wird.

  2. Sie geben nicht an, welche Art von Server oder welcher genaue Anwendungstyp verwendet wird. Einige Apps werden über JNLP/WebStart bereitgestellt, um von mehreren Benutzern heruntergeladen zu werden, und sie haben andere Regeln als eine eigenständige Anwendung für einen Benutzer auf einem Server, die ohne GUI als Überwachungsanwendung ausgeführt wird. Ich kann Ihnen damit nicht weiterhelfen, wenn Sie nicht mehr Details zu Ihrer Anwendung, der Serverumgebung usw. geben können. Wie können Sie auf die Konfigurationsdateien zugreifen? Sind sie statisch und werden sich nie ändern (etwas, das Sie mit einem ResourceBundle laden können)? ? Sie können sie zur JAR-Datei hinzufügen, um sie im ResourceBundle nachzuschlagen, aber alles hängt davon ab, was Sie dort tun. Wenn sie sich außerhalb der JAR-Datei befinden müssen, um sie zu ändern, ohne sie erneut zu kompilieren, lassen Sie sie mit einem Installer-Skript kopieren. Wie für Verzeichnisse, müssen sie bereits existieren? Oder überprüft die Anwendung ihre Existenz und erstellt sie bei Bedarf? Wenn die App diese bei Abwesenheit erstellen kann, müssen Sie sie nicht erstellen. Wenn sie vorhanden sein müssen, können Sie sie zum Installationsskript hinzufügen, um diese Ordner vor der Installation der JAR-Dateien zu erstellen. Die Versionsnummer könnte so einfach sein wie das Hinzufügen einer About-Box irgendwo in der App und das Nachschlagen der Versionszeichenfolge in einer config/properties-Datei. Es muss gepflegt werden, aber zumindest wäre es möglich, auf etwas zuzugreifen, das Sie wissen lässt, dass Sie Build 9876.5.4.321 (oder das von Ihnen verwendete Versionsnummernschema) implementiert haben.

+0

Die App selbst ist eine eigenständige J2SE-App (es werden keine Frameworks, nur einige externe Bibliotheken verwendet), die von der Befehlszeile aus auf einer Linux-Plattform ausgeführt werden. Die cfg-Dateien sind einfache Dateien, die Name-Value-Paare enthalten und deren Inhalt sich regelmäßig ändert. Die Verzeichnisse müssen vorhanden sein oder die App wird nicht ausgeführt. – Haes

+0

Konzentrieren Sie sich auf eine Befehlszeile amt build. Erstellen Sie ein Implementierungsziel in dieser Build-Datei, das alle Elemente zusammenfasst: erstellt erforderliche Verzeichnisse, erstellt die JAR-Datei, kopiert alles in die richtigen Verzeichnisse usw. Schreiben Sie ein Shell-Skript, das ant ausführt und dieses spezifische Ziel aufruft. – anon

+0

Für die Versionsnummer, würde ich es nicht in den Konfigurationsdateien, die auf dem Dateisystem verfügbar sind. Fügen Sie es irgendwo in eine kompilierte Klasse ein, damit es innerhalb der App aufgerufen werden kann, aber nicht geändert werden kann (um zu fälschen, welche Version bereitgestellt wird), ohne die Anwendung neu zu erstellen. – anon

0

Idealerweise sollten Sie Ihre Anwendungsquellen und die Konfiguration nicht an eine bestimmte IDE binden.

Questionwise,

  • Ich schlage vor, Sie nicht. Halten Sie Ihre Repository-Struktur unabhängig von der IDE
  • Sie müssen möglicherweise Ihre Anwendung ändern, so dass ihre Struktur sehr allgemein ist und in jeder IDE bearbeitet werden kann.

    Ist dies eine Web App? Eine eigenständige Java-App? Wenn Sie diese klären, wäre es einfacher, Ihre Anfrage zu beantworten.

+0

Guten Punkt, aber da Netbeans bereits Ameisen für seine Build/Test-Mechanismen verwendet, dachte ich, dass zumindest einchecken der Build.xml-Dateien sinnvoll sein könnte (auch wenn ihre Struktur ziemlich kompliziert aussieht). – Haes

+0

Solange die Build-XMLs nichts speziell für Netbeans haben (können sie?), Sollte es in Ordnung sein, sie einzuchecken. Aber ich habe gesehen, dass Netbeans in build.xmls seltsame Dinge erzeugt, also wäre ich vorsichtig Ding. – talonx

0

Wir checken nicht in den Verzeichnissen/build oder/dist ein.

Wir neigen dazu, diese Struktur für unsere Netbeans Projekte in SVN zu verwenden.

/project1/ 
      /trunk 
      /tags/ 
       /1.0 
       /1.1 
      /binaries/ 
        /1.0 
        /1.1 

Wenn eine Änderung wir das NetBeans-Projekt vom Stamm überprüfen wird müssen/und, um es Änderungen und überprüfen Sie es in wieder einmal Eine Freigabe des Projekts ist erforderlich Wir machen eine SVN-Kopie der Netbeans-Projektdateien zur nächsten Tag-Version. Wir nehmen auch eine Kopie des Deployable (JAR oder WAR) und legen sie zusammen mit allen Abhängigkeiten und Konfigurationsdateien unter Binärdateien im Versionsverzeichnis ab.

Dadurch haben wir eine saubere, versionierte deployable, die getrennt von der Quelle ist. Sind Deployables Version im Namen - project1-1.0.jar, project1-1.1jar und so weiter.

Ich stimme talonx nicht zu, dass Ihre Quelle nicht-IDE-spezifisch ist - indem Sie keine IDE-Dateien in SVN zusammen mit Ihrer Quelle speichern, fügen Sie dem Checkout-, Änderungs-, Eincheck- und Bereitstellungszyklus zusätzliche Komplikationen hinzu. Wenn Sie die IDE-Projektdateien in SVN speichern, können Sie einfach das Projekt auschecken, die IDE starten und Build erstellen. Sie müssen nicht die Schritte zum Einrichten eines neuen Projekts in der IDE ausführen, einschließlich der Dateien, die Sie SVNed, Einrichten von Abhängigkeiten etc. Es spart Zeit und bedeutet, dass alle Entwickler mit dem gleichen Setup arbeiten, was Fehler und Diskrepanzen reduziert . Das Letzte, was Sie wollen, ist, dass ein Entwickler ein Projekt auscheckt, um einen kleinen Bug zu beheben, und Zeit damit verbringen muss, Abhängigkeiten zu finden und Dinge einzurichten.

+0

Können Sie den Teil "zusätzliche Komplikation" klären? Was ist der genaue Nutzen, den Sie beim Speichern von IDE-spezifischen Dateien haben? – talonx

+0

Ich fügte dem obigen Text hinzu, als ich hier den Kommentarraum verließ. –

+0

Ihre Klarstellungen sind sinnvoll. Aber nur wenn alle Entwickler die gleiche IDE verwenden (oder eine von ihnen prüft in ihren Einstellungen). Außerdem haben Devs es meistens schon eingerichtet - das wird nur für neue Entwickler ein Problem. – talonx

0

Um Frage # 2 zu beantworten - wer ist Ihr Verbraucher für diese App? Wenn es eine interne App ist und nur Sie (oder andere Entwickler) es bereitstellen, dann ist das, was Sie haben, vollkommen in Ordnung. Werfen Sie eine README-Datei ein, in der die erforderlichen Verzeichnisse erläutert werden.

Wenn Sie es an einen Client zur Installation senden, ist das eine andere Frage, und Sie sollten ein Installationsprogramm verwenden. Es gibt ein paar Installer, die ein Ameisen-Skript und Ihre Ressourcen einpacken, was ein netter Ansatz ist, besonders wenn Sie die GUI nicht brauchen ... schreiben Sie einfach ein einfaches Ameisen-Skript, um alles an den richtigen Ort zu bringen.

Versionsnummer liegt bei Ihnen - die Benennung der JARs ist keine schlechte Idee. Ich habe auch die Angewohnheit, die Versionsnummer beim Start auszudrucken, was nützlich sein kann.