Die Methoden zur Abfrage von im Modell oder Produkt definierten Wertebereichen für Vertragsattribute hatten in der Anwendung zwei Probleme:

Auch der Rückgabewert der Methoden ist mit der Einstellung Unified einheitlich ValueSet und nicht mehr spezifisch z.B. OrderedValueSet oder IntegerRange. Dies führt zwar manchmal dazu, dass der Rückgabewert auf den entsprechenden Typ gecastet werden muss, erlaubt dafür aber auch eine flexiblere Überschreibung.

Bei Verwendung von Produktvarianten werden Beziehungen mit der Kardinalität 0..0 überschrieben um sie in der Variante auszuschließen. Solche Beziehungen werden jetzt bei einem Aufruf des Getters (z.B. getDeckungen()) nicht mehr mit zurückgegeben. Ein Aufruf von getLinksForDeckungen() liefert weiterhin alle Links, an denen die Kardinalität jeweils abgefragt werden kann. Um dies z.B. in einem InMemoryRuntimeRepository testen zu können wird jetzt auch bei reinen Produktbeziehungen ein Setter/Adder mit einem CardinalityRange-Parameter generiert, der dann mit der neu eingeführten Konstante CardinalityRange#EXCLUDED aufgerufen werden kann.

Sollen Modellelemente ab einer bestimmten Version nicht mehr verwendet werden können diese analog zu Javacode als "deprecated" markiert werden. Dies ist auf dem Dokumentations-Reiter von Modellklassen und -elementen möglich, wo bisher schon angegeben werden konnte, ab welcher Version ein Element verfügbar ist (@since).

Dabei kann sowohl die Version, ab der das Element deprecated ist angegeben werden, als auch ob es nur nicht mehr genutzt werden soll oder auch in einer zukünftigen Version entfernt wird. Daneben kann eine Beschreibung angegeben werden, beispielsweise mit Hinweisen, welche Elemente ersatzweise genutzt werden sollen.

Deprecatete Elemente werden im Editor durchgestrichen dargestellt:

Die Beschreibung wird auch in der Modellbeschreibung angezeigt:

Werden Produktbausteintypen, Aufzählungstypen oder Tabellenstrukturen als Deprecated markiert, so werden darauf basierende Produktbausteine, Aufzählungs- und Tabelleninhalte mit einem Warnhinweis versehen, der ebenfalls die Beschreibung enthält:

Im generierten Code werden sowohl @Deprecated-Annotations (bei Java > 8 ggf. mit since- und forRemoval-Attribut) als auch @deprecated-Javadoc-Tags mit der Beschreibung erzeugt:

Das bisher von Aufzählungs-Datentypen bekannte Feature, dass diese als ID, Name oder "Name (ID)" angezeigt werden können, wurde verallgemeinert, so dass auch Datentypen ohne als Aufzählung definierte Wertemenge davon profitieren können. Durch Implementierung des Interface NamedDatatype mit den aus dem EnumDatatype bekannten Methoden getValueName(String id) und isSupportingNames() sowie der neuen Methode getValueByName(String valueName) kann ein eigener Datentyp (z.B. für ein Land "Deutschland (DE)") in Faktor-IPS nutzerfreundlicher angezeigt werden.

Auch in der .ipsproject-Konfiguration definierte Datentypen die auf bestehenden Klassen basieren können entsprechend konfiguriert werden:

Von nun an werfen alle Vergleiche (lessThan/greaterThan/compareTo) mit oder auf einem DecimalNull eine UnsupportedOperationException. Null-Objekte sollten nur zur Verhinderung von Exceptions bei Rechenoperationen genutzt und nicht mit regulären Werten verglichen werden. Wird dennoch ein Vergleich benötigt, der Nulls explizit mit beachtet kann dieser über Decimals#nullsFirstComparator() bzw. Decimals#nullsLastComparator() erstellt werden.

Faktor-IPS enthielt zwei unterschiedliche Konzepte mit dem Namen "Geschäftsfunktion“/“Business Function", welche seit Version 21.6 als deprecated markiert waren. Beide wurden nun endgültig entfernt. Bei der Migration werden alle noch existierenden Geschäftsfunktionen-Dateien und Referenzen in Vertragsteiltypen-XMLs gelöscht.

Der Konstruktor von DefaultGenericAttributeValidationConfiguration hat nun ein Feld für einen Pflichtfeldmarker. Wenn ein Marker übergeben wird, wird er in allen Messages für fehlgeschlagene Pflichtfeldprüfungen gesetzt.

Wenn zwei von einander abhängige Faktor-IPS Projekte den selben Basispaketnamen und den gleichen Quellordnernamen haben werden gleichnamige abgeleitete Ressourcen in einem gleichnamigen Java-Paket generiert. Dies führt zur Laufzeit zu Problemen, da der Java ClassLoader nur eine der beiden Dateien sehen kann.

Somit wird jetzt der uniqueQualifier, falls gesetzt, auch dazu verwendet die Validierungsmeldungen (validation-messages_de.properties) und Labels und Beschreibungen (model-label-and-descriptions_de.properties) in ein eindeutiges Java-Paket zu verschieben. Dies spiegelt sich auch im Quellcode wieder da dort der volle Java-Paketname zur Properties-Datei angegeben ist.

Faktor-IPS kann jetzt Konfigurationen für andere Faktor-IPS-Features (z.B. die Produktvarianten) in der .ipsproject-Datei ablegen. z.B:

In der Faktor-IPS-Runtime wurden JAXB-Adapter für die Datentypen LocalDate, LocalTime, LocalDateDatime und MonthDay aufgenommen, die bisher in einigen Projekten von Hand angelegt oder aus dem Projekt f10-commons übernommen wurden und jeweils manuell in den package-info.java-Dateien eingetragen werden mussten.

Da diese Adapter jetzt Bestandteil der (seit Faktor-IPS 21.6 auf Java 8 umgestellten) Runtime sind generiert Faktor-IPS für Felder mit entsprechenden Datentypen die passenden Annotations zur Nutzung der Adapter und fügt diese auch dem mit IRuntimeRepository#newJAXBContext() erzeugten Kontext hinzu, so dass dafür keine package-info.java-Einträge mehr notwendig sind (siehe auch JAXB-Support).

Zum Ausführen von Faktor-IPS-Testfällen mit JUnit gibt es jetzt neben den alten Klassen die noch auf JUnit 3 aufbauten neue Varianten für JUnit 5. Alle Tests aus einem Repository lassen sich jetzt wie folgt ausführen:

Wir arbeiten weiter daran, den Code von Faktor-IPS unabhängiger von Eclipse zu machen. Dazu haben wir Abstraktionen vieler Eclipse-Konzepte eingeführt, auf die unsere Plugins zugreifen. Eigene Plugins, die die Faktor-IPS-Plugin-API nutzen können davon betroffen sein. Abstraktions-Interfaces können am vorangestellten A erkannt werden, so ersetzt beispielsweise org.faktorips.devtools.abstraction.AFile das bisher verwendete org.eclipse.core.resources.IFile. Da eigene Plugins weiterhin Eclipse-Plugins sind kann der darin geschriebene Code auch weiterhin die Eclipse-API nutzen. Um von einer Faktor-IPS-Abstraktion zum entsprechenden Eclipse-Objekt zu kommen dient die Methode unwrap():

Sollten Abstraktionen für den Aufruf von Faktor-IPS-Code benötigt werden können diese mit Hilfe der Klasse Wrappers erstellt werden:

Bei der Migration auf Faktor-IPS 22.6 kann auf vereinheitlichte Wertebereichsmethoden umgestellt werden. Im Abschnitt Vereinheitlichte Wertebereichsmethoden ist ein Migrationsvorgehen für mehrere Projekte beschrieben.

Eigene Plugins müssen ggf. wie unter Interner Umbau beschrieben angepasst werden. Außerdem werden eventuell existierende Geschäftsfunktionen entfernt.

Für Multi-Value-Produktattribute wurde die Codegenerierung korrigiert. Bisher wurde für Attribute mit Vorbelegungswert "null" setMultiValueAttribute(new ArrayList<>()) generiert. Nach der Migration wird stattdessen setMultiValueAttribute(ListUtil.newList(null)) generiert. Aus der leeren Liste wird also eine Liste die ein Null-Objekt enthält. Damit die Liste wieder als leere Liste (setMultiValueAttribute(ListUtil.newList())) generiert wird, muss der Vorbelegungswert "null" entfernt werden. Diese Verhaltensänderung sollte bei der Migration für alle Multi-Value Attribute geprüft und gegebenenfalls angepasst werden.

In allen *.ips*-Dateien werden die UUIDs entfernt und die Reihenfolge von Elementen in Kategorien wird nicht mehr in ProductCmptPropertyReferences sondern in 'categoryPosition'-Attributen abgelegt.

Im Zuge der Migration sollte ggf. eine Maximallänge für die Diskirminatorspalte eingestellt und bestehende JAXB-Adapter für LocalDate/Time ersetzt werden.