Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
• Konzept der Eclipse IDE und Konsequenzen für die Arbeitsweise
• Wann ist Eclipse die „richtige“ IDE für Visual COBOL?
• Muss ich unbedingt ein Projekt anlegen?
• Vom einfachen zu komplexeren Projekten, Remote Projekte
• Unterschiede managed/unmanaged Code
• Konfiguration: wo stellt man was ein?
• Highlights: neue Features in Visual COBOL 3.0
• Fragen …
Unsere Themen im heutigen Webinar
• Eclipse ist aus einem Projekt bei der IBM entstanden
• IBM Visual Age for Java
• Ziel: Erstellen einer integrierten Entwicklungsumgebung für Java
• Quellcode wurde später von IBM als Open Source freigegeben
• Die Eclipse Foundation ist jetzt für die weitere Entwicklung verantwortlich (https://www.eclipse.org/org/foundation/)
• Eclipse ist außer für die Java-Entwicklung für die Verwendung unterschiedlicher Programmiersprachen ausgelegt
Konzept der Eclipse IDE
• Visual COBOL for Eclipse ist ein Eclipse Plugin zur Entwicklung von Anwendungen mit Visual COBOL
• Editor, Compiler, Debugger, …
• Das Installationspaket von Visual COBOL for Eclipse wird mit einer Eclipse IDE ausgeliefert
• Aktuell Eclipse 4.6 (64bit) (Neon)
• Auch andere Eclipse Versionen können per Plugin Installation genutzt werden (4.4.1, 4.4.2, 4.5 und 4.6 (32bit))
Konzept der Eclipse IDE
• Eclipse ist die „richtige“ IDE …
• Wenn nicht ausschließlich für die Windows-Welt entwickelt wird
• Zugriff auf alle unterstützten Unix/Linux-Plattformen über Remote Projekte
• … aber natürlich auch Entwicklung für Windows unter Windows möglich
• Wenn die Java-Technologie genutzt werden soll oder eine Integration der COBOL-Applikationen in die Java-Welt geplant ist
• Wenn die .NET-Technologie nicht von Interesse ist
• Ansonsten ist die Frage Eclipse oder Visual Studio mehr eine Frage persönlicher Präferenzen
Ist Eclipse die “richtige” IDE für mich?
• Eclipse arbeitet grundsätzlich mit Projekten
• Eclipse Projekte werden in einem sogenannten „Workspace“ verwaltet, einem (lokalen) Verzeichnis
• Lokale Projekte werden innerhalb des Workspace Ordners angelegt
• Pro Projekt ein separates Verzeichnis!!!
• Remote Projekte liegen auf dem Remote System• Existieren im lokalen Workspace nur als implizite Verweise
Konzept der Eclipse IDE
• Besteht eine Anwendung aus unterschiedlichen Programmier-sprachen, so ist für jede Sprache ein Projekt erforderlich
• Auf Projektebene werden dann zur Bearbeitung der Programme die entsprechenden Tools geladen
• Editor, Compiler, Debugger
• Dies ist insbesondere für die Kombination von COBOL und Java der Fall
• Ein Java-Projekt und ein COBOL JVM Projekt
• Referenzen für Aufrufe auf das jeweilige Projekt erforderlich
Konzept der Eclipse IDE
• Nein, Visual COBOL 3.0 for Eclipse kann auch ein einzelnes Programm laden, editieren, compilieren und sogar ausführen, auch im Debugger
• Hat man allerdings mehrere Programme zu bearbeiten, kommt man ohne Projekte nicht wirklich zurecht
• Das Arbeiten mit Eclipse Projekten ist nicht so kompliziert, wie es auf den ersten Blick erscheinen mag
Muss ich unbedingt ein Projekt anlegen?
• Auch die Frage, wie ein Projekt gebaut (Build) werden soll, wird auf Projektebene festgelegt
• Unterschiedliche Ausgabeformate in separaten Projekten erzeugen
• Eine Mischung aus .exe, .dll und .gnt würde drei verschiedene Projekte erforderlich machen
• Dies ist mit ein Grund, warum das Importieren von Net Express Projekten nicht empfohlen wird, zumindest nicht in jedem Fall
• Kann zu sehr vielen unterschiedlichen Eclipse-Projekten führen
• Auch unterschiedliche Compiler-Direktiven können ein Grund für mehrere Projekte sein
Konzept der Eclipse IDE
• Verzeichnisstruktur: Workspace-Verzeichnis
• Projekt1
• New_Configuration.bin
• Projekt2
• New_Configuration.bin
• Projekt3
• New_Configuration.bin
Konzept der Eclipse IDE
• Die IDE trennt klar zwischen Sourcen und Build-Artefakten (.exe, .dll) und speichert diese in separaten Verzeichnissen
• Auf der Projektebene werden alle projekt-spezifischen Einstellungen vorgenommen
• 32/64 bit, Ausgabeformat, Compiler-Direktiven, Anweisungen für den Linker
• Eclipse kann direkt mit Software Configuration Tools zusammenarbeiten (Subversion, Git, …)
Konzept der Eclipse IDE
• Das Hinzufügen von Sourcen bedeutet in der Regel das Laden der Sourcen aus einem solchen Repository
• Aber auch Sourcen, die nicht in einem Repository abgelegt sind, können auf unterschiedliche Weise in das Projekt aufgenommen werden
• Dabei werden die Sourcen in der Regel in das Projekt-verzeichnis kopiert, können aber auch als Link hinzugefügt werden (direkter Zugriff auf ursprünglichen Speicherort)
Konzept der Eclipse IDE
• COBOL-Sourcen zum Projekt hinzufügen:
• Dazu gibt es (mindestens) drei verschiedene Vorgehensweisen:
• Source-Dateien im Windows Explorer markieren und kopieren und in der Eclipse IDE im COBOL-Explorer einfügen (copy and paste).
• Dann – falls erforderlich - die Funktion „Refresh“ im Projekt-Menü aufrufen (rechte Maustaste auf dem Projekt-Namen)
• Source-Dateien im Windows Explorer in das Projekt-Verzeichnis kopieren und dann die Funktion „Refresh“ im Projekt-Menü aufrufen (rechte Maustaste auf dem Projekt-Namen)
Konzept der Eclipse IDE: Projektaufbau
13
• Oder…
• Import-Funktion im Projekt-Menü:
• Import
• Import
• General
• File System
• Oder aus Software Repository über
• Team, Git, ….
Konzept der Eclipse IDE: Projektaufbau
14
• Eclipse ist nicht dafür konzipiert, Programme und/oder Projekte zwischen verschiedenen Entwicklern zu teilen!!!
• Sourcen gehören in ein Repository, aus dem die Entwickler sie entleihen können
• Jeder Entwickler hat seinen eigenen (lokalen) Workspace und exklusiv von ihm verwendete Projekte
• Koordination erfolgt über das Repository
• Ermöglicht die Nachvollziehbarkeit, Versionskontrolle, etc.
Konzept der Eclipse IDE
• Mehrere Programme können zu einer .exe-Datei zusammen gelinkt werden
• Start-Programm angeben!
• Es können auch alle Programme zu einzelnen Executablesgeneriert werden, aber auch zu .dlls oder int/gnt
• Auch diese können direkt unter Kontrolle des Debuggers ausgeführt werden
Arbeiten mit Projekten
• Die Mischung verschiedener Ausgabeformate in einer Anwendung macht es erforderlich, mehrere Projekte für die Anwendung anzulegen
• Eine Anwendung kann aber auch aus anderen Gründen in mehrere Projekte unterteilt werden
• Wegen der Verzeichnisstruktur von Eclipse Projekten können weitere Konfigurationsschritte erforderlich sein, um der Anwendung alle Teile zur Verfügung zu stellen
Arbeiten mit Projekten
• Dazu bieten sich die folgenden Möglichkeiten an:
• Definition eines gemeinsamen Ausgabepfades für alle Projekte über einen Linked Folder
• Nicht zu empfehlen, da das Ausgabeverzeichnis bei einem kompletten Buildoder Clean des Projekts gelöscht wird!
• Unter den Projekteigenschaften Micro Focus / Build Configuration / Events im Post-build Event die Ausgaben der jeweiligen Projekte in ein gemeinsames Verzeichnis kopieren
• Neu: benötigte Projekte zum Micro Focus / Build Path / Projects addieren
Arbeiten mit Projekten
• Remote Projekte liegen auf einem entfernten Unix/Linux-System (Sourcen, Copy-Dateien, …)
• Die Programme werden auf dem entfernten System compiliert, gelinkt und ausgeführt bzw. gedebugged
• Die Steuerung erfolgt aus der lokalen Eclipse IDE
• Verbindung über Samba/NFS oder RSE (Eclipse Framework)
• RSE mit SSH ist die bevorzugte Verbindungstechnik
• Arbeiten wie mit lokalen Projekten!
Arbeiten mit Remote Projekten
• Moderne Cross-Plattform Entwicklung für COBOL
20
Visual COBOL® Remote Projekte
Visual COBOL® Development Hub für Linux u. UNIX- Standalone Compile und Debug-
Umgebung- Source Code, Datendateien etc.,
verbleiben auf der Zielplattform-
Visual COBOL® for Eclipse- Eclipse IDE auf Windows-/Linux-Desktop
für maximale Leistung- Lokale oder Remote Projekte
• Debug Configurations unterstützen alle Funktionen des Debuggers mit unterschiedlichen Konfigurationstypen
• COBOL Application
• COBOL Attach to Process
• COBOL Coredump
• COBOL Unit Test
• COBOL Wait for Application Attachment
• und spezielle Konfigurationen für Enterprise Server und COBOL JVM Applikationen
Debug Configurations
• Diese beziehen sich immer auf ein Projekt
• Sourcen, Copy-Dateien und Debug-Informationen (.idy) werden aus dem Projekt geladen
• Programme, die nicht im aktuellen Projekt liegen, aber bei der Ausführung der Applikation geladen werden, können ebenfalls jederzeit gedebugged werden
• Unter den Tabs für „Source“ und „Debug Symbols“ die Verzeichnisse der Source- und Copy-Dateien sowie der .idy-Dateien angeben
Debug Configurations
• Managed Code Projekte im Eclipse-Umfeld sind COBOL JVM Projekte
• Compilierung von COBOL zum Java Bytecode
• Um diese von Java aus aufzurufen, sind Referenzen aus dem Java Projekt auf die entsprechenden COBOL JVM Projekte erforderlich
• Diese müssen vorab erfolgreich compiliert („Build“) worden sein und im Java Projekt unter „Project References“ angegeben werden
Arbeiten mit Projekten: Managed Code
• 32/64 bit-Default konfigurierbar
• Window / Preferences / Micro Focus / Builder
• Default Platform Target
• Parallele Compilierung auf multi-prozessor Maschinen
• Aktivieren unter Window / Preferences / Micro Focus / Builder
• Maximum number of compilations to execute concurrently
• Refactoring
• Umbenennen einer Variablen im Programm oder
• Extrahieren der Variablen in eine Copy-Datei
Arbeiten mit der Eclipse IDE: Neu in Version 3.0
Arbeiten mit Visual COBOL 3.0 for Eclipse
Nächste Schritte
Kostenlose Testversion herunterladen oderUpdate auf Version 3.0 für Visual COBOL Kunden
microfocus.com/VIsualCOBOL