Im Umgang mit der vorherigen MASA Produktionsumgebung zeigten sich einige Nachteile:
Ziel der neuen Produktionsumgebung war es, diese Unflexibilitäten zu beseitigen und eine komfortable Umgebung zu schaffen, die Entwickler von Agenten in die Lage versetzt, möglichst auf bereits für die Übersetzung des Agentensystem getroffene Einstellungen zurückgreifen zu können.
Erreicht wurde dies durch die Schaffung einer Reihe von Makefiles, deren Inhalte nach den folgenden Kriterien aufgeteilt wurde:
Diese Makefiles werden gemeinsam von den Produktionsumgebungen von Agentensystem und Agenten benutzt.
Weiterhin sollte eine Möglichkeit geschaffen werden, mit der die konditionale Übersetzung unterschiedlicher Varianten aus einem Quelltext heraus möglich wird. Hierzu wurde das in [Roel 98] vorgestellte Konzept der Verwendung eines Präprozessors angewendet. Dort wird die damit verbundene Problematik anhand der Verwendung zweier unterschiedlicher ORB-Implementierungen, welche unterschiedliche Signaturen für Methoden gleichen Namens verwenden, erläutert:
``Für die flexible Verwendung des Quelltexts für beide ORBs ist die konditionale Übersetzung durch Steuerung über globale Konstanten (wie in Java üblich, siehe [Flan 97], Seite 22) nicht möglich. Der Grund hierfür liegt darin, daß bei dieser Methode die syntaktische Korrektheit aller Varianten überprüft werden muß, was durch die unterschiedlichen Signaturen zentraler Methoden und Klassennamen nicht möglich ist.
Die Verwendung eines Präprozessors, wie er aus der Programmiersprache C bekannt ist, stellt hier einen Ausweg dar, da dieser die jeweiligen, nicht zur Übersetzung anstehenden Teile ausfiltert, bevor der Quelltext an den Übersetzer übergeben wird. Leider ist ein Präprozessor in Java nicht vorgesehen.
Um dennoch einen Präprozessor nutzen zu können, mußte eine Eigenschaft des verwendeten Java Entwicklungssystems beachtet werden. Im Gegensatz zu C wird in Java eine automatische Auflösung von syntaktischen Abhängigkeiten auf Java-Ebene zwischen unterschiedlichen Quelldateien durch den Übersetzer vorgenommen und diese bei Bedarf auch sofort übersetzt. Somit ist eine, unter Unix gängige, ``pipe''-Verkettung von Präprozessor und Java Compiler ausgeschlossen. Vielmehr müssen alle Quelldateien vor dem ersten Aufruf des Java Compilers den Präprozessor durchlaufen haben, da im Zuge des Übersetzungsvorgangs nicht nur die angegebene Datei betrachtet wird, sondern auch all jene, von denen diese Datei abhängig ist. Dies wiederum führt zu dem Problem, daß nun die Ergebnisse der Präprozessor-Läufe explizit in Form von Dateien vorliegen müssen, die, durch den Suchalgorithmus von Java bedingt, mit identischen Dateinamen in korrekter Hierarchie zu den Quelldateien vorliegen müssen.
Wegen dieser Randbedingungen entstand eine Konstruktion, die zwischen den universellen Quelldateien und den Präprozessor-Ergebnissen unterscheidet. Die Präprozessor-Ergebnisse werden in einem sogenannten ``Produktionsverzeichnis'' abgelegt, in dem dann auch die eigentliche Übersetzung durch den Java Compiler durchgeführt wird und sich schließlich auch die übersetzten Programme befinden.''
In [Roel 98] wird außerdem ein weiterer Vorteil der Verwendung eines Präprozessors beschrieben:
``Durch die Verwendung eines Präprozessors wurde außerdem eine weitere Automatisierungsstufe im Entwicklungsprozeß möglich. Gewöhnlich muß sich die Package-Hierarchie der Java-Klassen in der die Klassen implementierenden Datei-Hierarchie widerspiegeln, damit die automatische Auflösung von Abhängigkeiten durch den Java Compiler funktioniert. Durch den Präprozessor sind nun auch Textersetzungen möglich, was es erlaubt, die Package-Hierarchie zentral als Parameter festzulegen. Die Quelldateien selbst müssen deshalb weder die konkrete Spezifikation der Package-Hierarchie enthalten, noch ist eine Anordnung der Quelldateien entsprechend Package-Hierarchie notwendig.''
Diese Technik wird ebenfalls in der neuen Produktionsumgebung eingesetzt.