Grundsätzlich geht MyCoRe davon aus, dass alle Dateien, die nicht sprachabhängig sind, mit UTF-8 kodiert wurden. Dies gestattet eine gute Nutzung auch über die Grenzen des deutschsprachigen Raumes hinaus. Dies betrifft vor allem die Dateitypen:

• Java-Code - *.java
• XML-/XSL-Dateien - *.xml

Die Einstellung erfolgt in Eclipse im jeweiligen Projekt unter:

1. Properties -> Info -> Text file encoding -> UTF-8

Um bei der Arbeit mit dem Subversion-System nur inhaltliche Änderungen zu erfassen und diese nicht mit Umformatierungen zu verwechseln, wird der gesamte Code einheitlich nach folgenden Regeln erstellt:

• Formatierung gemäß den Java-Konventionen
• Tabulatoren werden durch Leerzeichen ersetzt
• Einrückung mit vier Zeichen
• Zeilenumbruch und maximale Zeilenlänge 160
• Kommenare nicht umfomatieren

Die Einstellung erfolgt in Eclipse im jeweiligen Projekt unter:

1. Properties -> Java code style -> Formatter
2. dort Java Conventions als Vorlage wählen
3. Indentation -> Tab Policy -> Spaces only
4. Indentation -> Indentation size -> 4
5. Indentation -> Tab size -> 4
6. Line wrapping -> Maximum line width -> 160
7. Comments -> alle Markierungen entfernen
8. Die Vorlage wird dann als mycore gespeichert.

Auch für die Gestaltung der XML-Dateien wurde eine einheitliche Formatierung festgelegt:

• Zeilenumbruch und maximale Zeilenlänge 160
• Für Einrückungen sind nur Leerzeichen zu verwenden.
• Pro Tab sind 2 Zeichen Einrückung vorgesehen.

Die Einstellung erfolgt in Eclipse im jeweiligen Projekt unter:

1. Window -> Preferences -> XML -> XML Files -> Editor
2. dort wählen
3. Line width -> 160
4. Indent using spaces
5. Indentation size -> 2
6. Window -> Preferences -> XML Buddy -> Formatter
7. dort wählen
8. Tab width -> 2
9. Use space for tab
10. Wrap margin -> 160

Bevor ein Codeteil (Javaklasse, Stylesheet oder Konfigurationsdatei) committed wird, sollte diese gründlich getestet werden. Für Java-Klassen ist als erstes sicher zu stellen, dass sie den Compiler-Lauf erfolgreich bestehen. Um auch Konflikte mit anderen Java-Klassen von vorn herein auszuschließen, sollte vor jedem Commit einer Klasse des MyCoRe-Kerns der Aufruf

ant clean jar

erfolgen. So können Fehler in der Abhängigkeit schneller gefunden werden.

Die Datei .project sollte entsprechend der unten angegebenen Darstellung angepasst werden. Anschließend sind sowohl für den MyCoRe-Kern wie auch für die Anwendung noch die Java-Ressourcen zu definieren.

1. project -> Properties -> Java Build Path
2. Tragen Sie alle Sources ein.
3. Tragen Sie alle Libraries ein. Bitte beachten Sie, dass für den Kern alle *.jar bzw. *.zip Dateien aus mycore/lib bzw. mycore/components/*/sources zu verwenden sind. Hinzu kommen noch ggf Systemweite Pakete (z. B. aus /usr/share/java). Für die Anwendung sollten nur Pakete aus application/build/lib, nicht aus dem MyCoRe-Baum, integriert werden.

.project Datei:

mycore ... ... org.eclipse.jdt.core.javabuilder org.eclipse.jdt.core.javanature ]]>

Eclipse integriert bereits ein Produkt namens JUnit (http://www.junit.org/index.htm). Mit ihm erhalten Sie ein Werkzeug, welches das Testen der von Ihnen erzeugten Java-Klassen ermöglicht. Alle Test sind im Verzeichnis mycore/test abzulegen. Um einen neuen Test zu generieren, gehen Sie wie folgt vor:

1. Navigieren Sie auf die Klasse, für die der Test erzeugt werden soll
2. rechte Maustaste -> New -> Junit Test Case
3. Setzen Sie den Source Folder auf mycore/test
4. Sinnvoll ist das automatische anlegen der Methoden setUp() und tearDown()
5. Next
6. Markieren Sie die Methoden, für die ein Test erfolgen soll.

Den Test selbst starten Sie, indem Sie in der Testklasse über die rechte Maustaste 'Run As' --> 'JUnit Test' aufrufen.

Testklassen, die auf Datenbankanfragen angewiesen sind, sollten die Klasse org.mycore.common.MCRHibTestCase erweitern. Alle anderen erweitern org.mycore.common.MCRTestCase.

Alle Kommentare sind in Englisch abzufassen. Dabei ist auf allgemein verständliche Sprachkonstrukte zu achten. Der Kommentar soll die kodierten Vorgänge gut beschreiben und für andere nachvollziehbar machen.

Jede Java-Quelltext-Datei hat das nachfolgende Aussehen. Das gestattet ein einheitliches Auftreten des Projektes. Da für alle Dateien mittels JavaDoc automatisch eine Dokumentation generiert wird, ist es Pflicht, die erstellte Klasse mit einer allgemeinen Beschreibung zum Zweck und Einsatz der Klasse zu versehen. Weiterhin sind alle public oder protected Methoden mit einer Beschreibung zu versehen. Hierzu gehört auch die Dokumentation der übergebenen Parameter, der Rückgabewerte und ggf. der geworfenen Exceptions.

import java.io.File;
/** * This class implements all methode for ... * * @author Jens Kupferschmidt * @version $Revision: 1.49 $ $Date: 2006/05/17 11:49:32 $ */ final public class MCR... { ... ]]>

Mindestkommentar im Java Quellcode

* * @param a The paremeter a is the first value. * @return a if it is a positive number, else return 0. */ public final int abs(a) {    } } ]]>

Auch alle XSLT-Dateien sollen kurze Kommentare enthalten. Unbedingt erforderlich sind auf jeden Fall die Zeilen für die Versionskontrolle. Angestrebt wird folgendes Aussehen eines Stylesheets.

... ]]>

Alle Logging-Informationen werden, sofern nicht eine Umsetzung mittels der Internationalisierung I18N erfolgt, in Englisch notiert. Für MyCoRe ist das log4j-Paket des Apache-Projektes zu verwenden. Es gib 4 definierte Log-Level mit nachfolgenden Bestimmungen. Es ist davon auszugehen, dass eine normale Anwendung allgemein auf den Level INFO gesetzt ist.

• >ERROR – Gibt Informationen zu nicht behebbaren Fehlern, z.B. Exceptions, zurück.
• WARN – Gibt Informationen zu Fehlern zurück, welche die Weiterarbeit der Anwendung nicht ausschließen. In der Regel wird mit Standardwerten weitergearbeitet.
• INFO – Gibt allgemeine Informationen für den normalen Anwender bzw. die Log-Datei aus. Diese Nachrichten haben nur informativen Charakter.
• DEBUG – Gibt zusätzliche Informationen, die gezielt durch Einschalten dieses Levels abgerufen werden, aus.

• Algemeiner Bestandteile sind die Teile des MyCoRe-Kerns, welche von vielen/allen Komponenten und Modulen verwendet werden und die elementaren Grundfunktionalitäten von MyCoRe bereitstellen. U. a. beinhaltet dies die APIs zur Speicherung der Daten, Klassifikationen, der ACLs und Nutzer, Store-Zugriffe und Klassen, die allgemeiner Natur sind und als API-Funktionalitäten bereitgestellt werden (MCRServlet, XML-Parser usw.).

• Komponenten sind Teile des MyCoRe-Kerns welche als Funktionalität in sich abgrenzbar sind. Sie bauen auf den Allgemeinen Bestandteilen auf und enthalten alle zur Funktionalität gehörenden Klassen und Dateien. Alle Komponenten haben eine fest vorgegebene Struktur (siehe unten) und können über ein Property ausgeschaltet werden (wie bisher bei den Modulen des Kerns). Die in den Komponenten enthaltenen Vorlagen (Templates) können durch anwendungsseitige Dateien überschrieben werden. Komponenten werden vom Entwickler-Team bereitgestellt und sind Bestandteil von mycore.jar. Komponenten werden über einen automatischen Prozess in die Anwendung integriert, wenn sie nicht explizit deaktiviert wurden.

• Module sind austauschbare/abschaltbare Teile der Nutzeranwendung, welche alle wichtigen Dinge zur Gestaltung konkreter Anwendungen enthalten, die nicht als generisch anzusehen sind (Datenmodelle, statische Seiten, Layouts usw.). Module werden von den Anwendern entwickelt und bauen auf dem mycore.jar auf. Module können auch Komponeten überschreiben bzw. ergänzen. Die Dateibaumstruktur vom Modulen und Komponenten soll analog zueinander sein.

Der mycore-Verzeichnisbaum ist ein Projektbereich, aus welchem die für die Anwendung relevante Datei mycore.jar erzeugt wird. Alle Teile unterstützen nur die Sprachen Englisch und Deutsch. mycore hat nachfolgende Struktur:

• Starten der Anwendung mit 'build/bin/jettystart.sh' bzw. 'build\bin\jettystart'.
• Tests der Web-Anwendung (statische Seiten)
  • Es sind alle Seiten der sitemap.xml Anzeige durchzutesten.
• Tests der Web-Anwendung (Suche/Präsentation/Navigation)
  • Suche nach Institutionen
  • Suche nach Personen, weiter Suchen nach verlinkten Dokumenten
  • Suche nach Dokumenten ohne Parameter und Navigation in der Trefferliste. Navigation aus der Anzeige heraus zur Trefferliste und zur Detailansicht. Anzeige von Dokumenten mit Bildern (bei integriertem ImageViewer).
  • Suche nach Dokumenten mit Parametern und Volltextsuchbegriffen, z. B. 'Hühnerstall', 'Huhn*', usw.
  • Test der Zugriffsrechte auf Objekte mit Wechsel der User (z. B. Suche nach 'Umbau').
  • Navigation über den Personenindex und von dort zu Dokumenten (z. B. Trappe).
  • Navigation in den Klassifikationen (z. B. Herkunft, Format).
• Tests der Web-Anwendung (Editor-Funktionen)
  • Login als User 'author1A'.
  • Neuanlegen einer Institution, Bearbeiten der Daten im Workflow, Löschen der Institution aus dem Workflow.
  • Neuanlegen einer Institution, ändern der ACLs (mehrer Versionen durchspielen), Hochladen der Institution, Bearbeiten der Daten, Suchen nach den Daten und Löschen der Daten aus dem Server.
  • Neuanlegen einer Person, Bearbeiten der Daten im Workflow, Löschen der Institution aus dem Workflow.
  • Neuanlegen einer Person, ändern der ACLs (mehrer Versionen durchspielen), Hochladen der Person, Bearbeiten der Daten, Suchen und Navigieren nach den Daten, Setzen der ACL-Permission 'deletedb' für 'author1A' und Löschen der Daten aus dem Server.
  • Neuanlegen eines Dokuments (mit Link auf einen Personendatensatz), Bearbeiten der Daten im Workflow, Hinzufügen eines Derivates, Hinzufügen einer Datei zum Derivate, Umbenennen des Derivates und Löschen des Dokuments aus dem Workflow.
  • Neuanlegen eines Dokuments (mit Link auf einen Personendatensatz), Hochladen des Dokuments, Bearbeiten der Daten, Hinzufügen eines Derivates, Hinzufügen einer Datei zum Derivate, Umbenennen des Derivates, Löschen einer Datei aus dem Derivate und Löschen des Dokuments aus dem Server.
  • Logout als 'gast'
• Tests der Web-Anwendung (Klassifikationseditor)
  • Login als User 'administrator'.
  • Auswahl Menüpunkt Klassifikationseditor starten.
  • Neue Klassifikation erstellen (ID DocPortal_class_00000100), Klassifikation speichern, Klassifikationsbeschreibung ändern, zwei neue Kategorien hinzufügen, Reihenfolge tauschen, Kategorie editieren, 'empty' Kategorie löschen, Klassifikation speichern, exportieren und wieder löschen.
  • Logout als 'gast'.
  • Navigation in den Klassifikationen.
• Tests der Web-Anwendung (Nutzerverwaltung)
  • Aufruf Startseite, Aufruf Login als anderer User, 'Abbrechen', Aufruf Login als anderer User, Login als User 'administrator', Rückkehr zur Anwendung, Benutzer wechseln -> 'Abbrechen', Benutzer abmelden.
  • Login als User 'administrator' und Rückkehr zur Anwendung.
  • Passwort ändern und 'Abbrechen' drücken.
  • Passwort ändern und 'Ändern' drücken. Login mit dem neuen Passwort.
  • Benutzerdaten anzeigen lassen.
  • Neue Gruppe 'test' anlegen, Gruppe administrieren und 2 Benutzer 'test' zuweisen. Neuen Benutzer 'otto' für die Gruppe 'test' anlegen.
  • Logout als 'gast'.
• Tests der Web-Anwendung (ACL-Editor)
  • Login als User 'administrator'.
  • ACL-Editor starten, nach MCRObjectID DocPortal_author_00410901 filtern, 'writedb' auf 'SYSTEMRULE000000006' setzen, OK, Logout als 'gast', Suche nach Person 'Kupferschmidt' – muss jetzt von 'gast' editierbar sein.
  • Login als User 'administrator'.
  • ACL-Editor starten, Rule-Editor aufrufen, 'SYSTEMRULE0000000002' um Gruppe 'test' erweitern, OK. Login as 'test' ant try to change sample data.
  • Logout als 'gast'.
• Tests der Web-Anwendung (Broadcasting Modul)
  • Login als User 'administrator'
  • Module-Broadcasting Monitoring -> edit, 'Power' -> on, ' Message Header' und 'Message Tail' ausfüllen, 'Nachricht an Gruppe' -> admingroup -> ...text... , OK. Login als User 'administrator' (sollte Nachricht erhalten).
  • Module-Broadcasting Monitoring -> edit, 'Power' -> off
• Tests der Web-Anwendung (WebCLI Module)
  • Starten des Web-Commandline-Interfaces
  • Auswählen von Kommandos wie 'list all users' und kritsches prüfen des Ergebnisses
  • Web-Commandline-Interfaces schließen
  • Login als gast und erneuter Versuch, das Tool zu starten (darf nicht gehen).
• Stoppen der Anwendung mit 'build/bin/jettystop.sh' bzw. 'build\bin\jettystop'.

• [ToDo – 2007-08-29 – Jena]

• Test Google-Servlet
  • Aufruf von http://localhost:8291/sitemap_google.xml, es sollte eine korrekte Sitemap zurückgeliefert werden.
• Test OAI
  • [ToDo – 2007-09-25 - Rostock]
• Test Z3950
  • [ToDo – 2007-09-25 - Rostock]
• Test MyCoRe Remote Access
  • Starten der Anwendung mit 'build/bin/jettystart.sh' bzw. 'build\bin\jettystart'.
  • ant webservice.deploy
  • Suchmaske nach Dokumenten aufrufen, 'diesem und ausgewählten Servern' sowie 'Lokal via WebService' und 'DocPortal Sample Server' markieren und die Suche starten. Es müssen die Beispieldaten je dreimal als Treffer erscheinen. Navigation in den Treffern testen.
  • Stoppen der Anwendung mit 'build/bin/jettystop.sh' bzw. 'build\bin\jettystop'.
• Test der Vererbung
  • [ToDo – 2007-09-25 - Leipzig]