Faktor-IPS Documentation

Release Notes

Version 22.6.8

Offline XSD Schemadateien fehlen (FIPS-9759)
Unrestricted Java-Enum enthält nicht alle Werte (FIPS-10003)

Wenn ein Enum (isEnumType=true) als eigener Datentyp definiert ist und in der Produktkonfiguration als Unrestricted konfiguriert wird, dann wird jetzt ein OrderedValueSet generiert das alle Werte enthält. Dazu wird die in der .ipsproject Datei konfigurierte getAllValuesMethod verwendet.

Version 22.6.6

Behobene Fehler

Rekursion in AbstractRuntimeRepository#getEnumValueLookupService wird zu oft aufgerufen (FIPS-9621)
ProductReleaseProzessor wirft NullPointerException bei als JAR referenzierten Modellen (FIPS-9633)

Version 22.6.5

Behobene Fehler

Wenn man die Maven-Dependencies eines IPS-Projekts im Modell-Explorer oder Produktdefinitions-Explorer aufklappte flog eine Exception (FIPS-9306)

Version 22.6.4

Behobene Fehler

IpsTests finden ToC aus Maven-Dependencies unter Windows nicht (FIPS-9196)

Version 22.6.3

Behobene Fehler

Einheitlicher Umgang mit null/Leerstring als Default (FIPS-9042)

Version 22.6.2

Weitere Funktionen und Verbesserungen

Schema in .ipsproject-Templates des Archetype (FIPS-9015)
IDeltaComputationOptions erweitern, so dass MOVED ignoriert werden kann (FIPS-9052)

Behobene Fehler

Zugriff auf Aufzählungsattribute via Name schlägt bei groß geschriebenen Attributsnamen fehl (FIPS-9003)
Ständig wiederkehrende Exception wenn InstanceExplorer offen ist (FIPS-9029)
DecimalRange.getValues() mit upperBound=lowerBound + step=null wirft Exception (FIPS-9044)

Version 22.6.1

Bei der Division eines Decimal-Werts durch Decimal.NULL wird jetzt wie bereits zuvor im Javadoc dokumentiert Decimal.NULL zurück gegeben. (FIPS-8989)

Version 22.6.0

Neue Funktionen und Verbesserungen

Vereinheitlichte Wertebereichsmethoden (FIPS-6497)

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

Sie hießen abhängig von der Art des Wertebereichs unterschiedlich (z.B. getRangeForWohnflaeche,getSetOfAllowedValuesForZahlweise,getAllowedValuesForHubraum). Ursprünglich war es so gedacht, dass man am Namen der Methode schon den Rückgabetyp erahnen kann, doch dazu muss man die Methode schon gefunden haben. Meist war es eher hinderlich, da man beim Programmieren nur den Namen des Attributs, nicht aber die Art des Wertebereichs kennt.
Sie hatten einen ValidationContext als Parameter - der dann im generierten Code nicht genutzt wurde und deshalb zu Warnings im Code führte. Hier war angedacht, dass der Kontext genutzt würde, um davon abhängig unterschiedliche Wertebereiche zurückzugeben, doch diese ließen sich so nicht in der Produktkonfiguration festlegen. Deshalb musste man die Art des Wertebereichs kennen, um die passende Methode aufrufen zu können (oder generisch über das IpsModel gehen) und immer einen ValidationContext oder null übergeben. Ab Faktor-IPS 22.6 gibt es die Möglichkeit, den Generator anzuweisen, für alle Typen von Wertebereichen einen einheitlichen Methodennamen(getAllowedValuesForWohnflaeche) zu verwenden und auf den Kontext-Parameter zu verzichten. Dies erleichtert auch die Überschreibung, z.B. mit berechneten Wertebereichen. Bei der Migration kann gewählt werden, ob direkt auf die neuen einheitlichen Methoden(Unified) umgestellt wird, weiterhin die alten Methoden(ByValueSetType) genutzt oder beide Methoden(Both) generiert werden sollen.

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.

Migration

Faktor-IPS unterstützt auch unterschiedliche valueSetMethods Einstellungen per Projekt. Diese Funktion sollte aber spärlich verwenden werden da der Code Generator zusätzliche ähnlich Methoden generieren muss damit die Vererbung in Java weiterhin wie erwartet funktioniert. Außerdem empfehlen wir die Einstellung Both nur für Migrationszwecke zu verwenden, nicht jedoch für den Produktivcode.

Wurden bereits Wertebereichsmethoden manuell angepasst empfiehlt sich folgendes Migrationsvorgehen:

Basismodell auf Both umstellen
Manuelle Anpassungen in die neuen Methoden übernehmen
Spartenmodelle auf Both umstellen
Manuelle Anpassungen in die neuen Methoden übernehmen
Spartenmodelle auf Unified umstellen
Basismodell auf Unified umstellen

Die Einstellung valueSetMethods sollte für Maven- und OSGi-Projekte nicht nur in der .ipsproject-Datei sondern auch in der META-INF/MANIFEST.MF gepflegt werden. Ist diese vorhanden wird im Rahmen der Migration der Abschnitt Fips-GeneratorConfig dort angelegt bzw. mit den aktuellen Werten überschrieben. Bei späteren Änderungen der Einstellungen muss der Wert manuell synchronisiert werden. Die Einstellung aus dem Manifest wird vom Codegenerator verwendet, wenn ein referenziertes Projekt (z.B. das Basismodell) nur als Dependency vorhanden ist und nicht im Workspace geöffnet ist.

Noch im handgeschriebenen Codeteil verbliebene Aufrufe der alten Methoden lassen sich z.B. in Eclipse über Regular Expressions beim Suchen und Ersetzen finden, z.B. kann folgender Ausdruck durch .getAllowedValuesFor$1() ersetzt werden:

\.get(?:Range|(?:SetOf)AllowedValues)For([^(]+)\((?:[^)(]+|\((?:[^)(]+|\([^)(]*\))*\))*\)

Wurden Wertebereichsmethoden mit Hilfe des Javadoc-Tags @generated REDIRECT umgeleitet, so müssen ggf. nach der Migration die neu benannten Methoden ebenfalls umgeleitet werden.

Vor der Migration sieht der Code z.B. so aus:

  /**
   * Gibt den erlaubten Wertebereich fuer das Attribut versicherungssumme zurueck.
   *
   * @generated REDIRECT
   */
  @IpsAllowedValues("versicherungssumme")
  public ValueSet<String> getSetOfAllowedValuesForVersicherungssumme(IValidationContext context) {
    ValueSet<String> allowedValues = getSetOfAllowedValuesForVersicherungssummeGeneratedRedirection(context);
    // z.B. Einschränkungen auf Grundlage anderer Attribute
    return allowedValues;
  }

  /**
   * Gibt den erlaubten Wertebereich fuer das Attribut versicherungssumme zurueck.
   *
   * @generated
   */
  @IpsGenerated
  public ValueSet<String> getSetOfAllowedValuesForVersicherungssummeGeneratedRedirection(IValidationContext context) {
    return MAX_ALLOWED_VALUES_FOR_VERSICHERUNGSSUMME;
  }

Nach der Migration gibt es eine neue Methode ohne Redirect und die alte mit @generated REDIRECT markierte Methode:

  /**
   * Gibt den erlaubten Wertebereich fuer das Attribut versicherungssumme zurueck.
   *
   * @generated
   */
  @IpsAllowedValues("versicherungssumme")
  @IpsGenerated
  public ValueSet<String> getAllowedValuesForVersicherungssumme() {
    return MAX_ALLOWED_VALUES_FOR_VERSICHERUNGSSUMME;
  }

  /**
   * Gibt den erlaubten Wertebereich fuer das Attribut versicherungssumme zurueck.
   *
   * @generated REDIRECT
   */
  @IpsAllowedValues("versicherungssumme")
  public ValueSet<String> getSetOfAllowedValuesForVersicherungssumme(IValidationContext context) {
    ValueSet<String> allowedValues = getSetOfAllowedValuesForVersicherungssummeGeneratedRedirection(context); (1)
    // z.B. Einschränkungen auf Grundlage anderer Attribute
    return allowedValues;
  }

1	Hier sollte ein Compilefehler auftreten, weil noch die alte Methode aufgerufen wird

Jetzt kann die neue Methode umgeleitet werden:

Kopieren der neuen Methode
Ergänzen des Methodennamens der Kopie um GeneratedRedirection (hier generiert Faktor-IPS weiterhin)
Ergänzen des Javadoc-Tags der Original-Methode @generated um REDIRECT (hier generiert Faktor-IPS nicht mehr)
Ersetzen des Original-Methodeninhalts durch den der alten mit @generated REDIRECT markierten Methode
Darin Ersetzen des alten Methodenaufrufs und Weglassen des ValidationContext-Parameters (z.B. wird getRangeForFoobarGeneratedRedirection(context) durch getAllowedValuesForFoobarGeneratedRedirection() ersetzt)
Löschen der alten Methode

Ergebnis:

  /**
   * Gibt den erlaubten Wertebereich fuer das Attribut versicherungssumme zurueck.
   *
   * @generated REDIRECT
   */
  @IpsAllowedValues("versicherungssumme")
  @IpsGenerated
  public ValueSet<String> getAllowedValuesForVersicherungssumme() {
    ValueSet<String> allowedValues = getAllowedValuesForVersicherungssummeGeneratedRedirection();
    // z.B. Einschränkungen auf Grundlage anderer Attribute
    return allowedValues;
  }

  /**
   * Gibt den erlaubten Wertebereich fuer das Attribut versicherungssumme zurueck.
   *
   * @generated
   */
  @IpsGenerated
  public ValueSet<String> getAllowedValuesForVersicherungssummeGeneratedRedirection() {
    return MAX_ALLOWED_VALUES_FOR_VERSICHERUNGSSUMME;
  }

Überschreibung von Bereichen mit Aufzählungen

Bei Verwendung der vereinheitlichten Wertebereichsmethoden können in Superklassen als Bereich festgelegte Wertebereiche jetzt auch in Ableitungen mit Aufzählungen (deren Werte dem ursprünglich definierten Bereich entstammen) überschrieben werden.

Umgang mit ausgeschlossenen Beziehungen / Kardinalität 0..0

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.

Deprecation von Modellelementen

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:

Produktbaustein "hausrat.zusatzdeckungen.Fahrraddiebstahl 2022-01" basiert auf Produktbausteintyp "hausrat.Zusatzdeckungstyp"; "hausrat.Zusatzdeckungstyp" ist seit 22.6.0 als deprecated markiert (Stattdessen spezialisierte Subklassen verwenden).

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:

/**
 * Erzeugt eine neue Instanz von Zusatzdeckungstyp.
 *
 * @deprecated for removal since 22.6.0. Stattdessen spezialisierte Subklassen verwenden
 * @since 17.3
 *
 * @generated
 */
@Deprecated(since = "22.6.0", forRemoval = true)
public Zusatzdeckungstyp(IRuntimeRepository repository, String id, String kindId, String versionId) {
    super(repository, id, kindId, versionId);
}

Datentypen mit Namen und ID

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:

<Datatype id="Land"
  javaClass="org.faktorips.sample.dt.Land"
  valueObject="true"
  isEnumType="false"
  valueOfMethod="fromIsoCountryCode"
  isParsableMethod="isIsoCountryCode"
  valueToStringMethod="getIsoCountryCode"
  isSupportingNames="true" (1)
  getNameMethod="getFullName" (2)
  getValueByNameMethod="fromFullName" /> (3)

1	Konfiguration der Namensunterstützung
2	Eine parameterlose Methode mit String-Rückgabewert
3	Eine statische Methode, die auf einen String- oder CharSequence-Parameter (wie er von der getNameMethod ausgegeben wird) einen Wert zurückgibt

Konsequente Exceptions beim Vergleich mit DecimalNull

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.

Geschäftsfunktionen entfernt

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.

Unterstützung von Pflichtfeldmarkern bei der Generischen Validierung

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.

Verbesserungen am Unique-Qualifier

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.

Feature-Konfiguration

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

<FeatureConfigurations>
  <FeatureConfiguration featureId="org.faktorips.productvariant">
    <Property name="UseUniqueIds" value="OnlyForVariedComponents" />
  </FeatureConfiguration>
</FeatureConfigurations>

Datenbank-Mapping

Angabe der Länge der Diskriminator-Spalte

Wird die Persistenz-Annotation-Generierung von Faktor-IPS genutzt ist es nun möglich die Länge der Diskriminator-Spalte in Faktor-IPS zu definieren. Dadurch kann unnötiger Speicherverbrauch in der Datenbank verhindert werden. Die Länge der Diskriminator-Spalte wird in der Validierung überprüft und es wird eine Error-Meldung erstellt, wenn ein Diskriminator-Wert die Länge überschreitet. Die Angabe der Länge ist optional. Wenn keine Länge definiert wird, verhält es sich wie bisher und es können beliebig lange Diskriminator-Werte gesetzt werden.

Wir empfehlen den Wert so zu setzen, dass alle bisherigen Diskriminator-Werte erhalten bleiben und eine DB-Migration durchzuführen, die den bisherigen DB-Standardwert für die Spaltenlänge durch den eingestellten ersetzt.

Jakarta Persistence und EclipseLink 3

Der Standard Jakarta Persistence (ehemals JPA) und die Referenzimplementierung EclipseLink werden jetzt jeweils in der Version 3 unterstützt, welche sich von den Vorgängerversionen hauptsächlich durch den Wechsel der Package-Namen von javax.persistence zu jakarta.persistence unterscheiden. Bei entsprechender Umstellung sollten auch Maven-Dependencies auf jakarta.persistence:jakarta.persistence-api:3.0.0 bzw. org.eclipse.persistence:eclipselink:3.0.2 aktualisiert werden.

JAXB-Adapter für LocalDate/Time

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).

JUnit-5-Adapter für IPS-Tests

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:

import org.junit.jupiter.api.DynamicTest;
import org.junit.jupiter.api.TestFactory;

public class HomeInsuranceJUnitTest extends IpsTestSuiteJUnit5Adapter {
     @TestFactory
     public Stream<DynamicTest> getTests() {
         IRuntimeRepository repository = // z.B. ClassloaderRuntimeRepository#create
         return createTests(repository.getIpsTest(""));
    }
}

Interner Umbau

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():

AFile abstractFile = [...]
IFile eclipseFile = abstractFile.unwrap();

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

import static org.faktorips.devtools.abstraction.Wrappers.wrap;
[...]
IFile eclipseFile = [...]
AFile abstractFile = wrap(eclipseFile).as(AFile.class);

Migration

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.

Weitere Funktionen und Verbesserungen

getEffectiveFromAsCalendar() nicht mehr generieren (optional) (FIPS-7539)
Model-Plugin von Eclipse entkoppeln (FIPS-8425)
Doku zu Mavenunterstützung aktualisieren (FIPS-8584)
@Deprecated im IPS-Modell (Klassen/Attribute/Beziehungen…?) (FIPS-451)
java.util.Currency als Datentyp bereitstellen (FIPS-4708)
Angabe der Länge der Diskriminator-Spalte (FIPS-5278)
Methoden zum Anlegen von Ranges konsistent machen (FIPS-5358)
GenericEnumDatatype sollten auch Collections als Wertebereich akzeptieren (FIPS-5440)
Vereinheitlichte Wertebereichsmethoden (FIPS-6497)
Tooltip an Produktbeziehungen sollte Namen der Vertragsbeziehung anzeigen (FIPS-7537)
DataType: getNameMethod auch für nicht Enums verwenden? (FIPS-7548)
ValueSet eines unrestricted Enum Attribute sollte ein OrderedValueSet sein (FIPS-7802)
Getter für assozierte Produktbausteine sollten leere Kardinalitäten ausfiltern (FIPS-7905)
NaturalOrderedValueSet, das Range implementiert (FIPS-7956)
Abfrage eines im Modell festgelegten Defaultwertes über DefaultPolicyAttribute.getDefaultValue() (FIPS-8095)
Verzicht auf UUIDs in .ips* (FIPS-8096)
Remove deprecated Business Functions (FIPS-8115)
PersistenceProvider für jakarta.persistence / EclipseLink 3 (FIPS-8159)
Ich möchte nie wieder XML-Adapter in package-info.java per Hand eintragen (FIPS-8231)
null-handling im OrderedValueSet problematisch/sehr fragwürdig (FIPS-8416)
Format Delta-ComputationMethod Javadoc (FIPS-8466)
Use mavenVersionProvider in Integrationtest (FIPS-8469)
PersistenceOptions Default max table column size anpassen und dokumentieren (FIPS-8515)
FormulaEvaluator sollte nur erstellt werden, wenn auch Formeln vorliegen (FIPS-8559)
StringLengthValueSet#isEmpty() sollte true zurückgeben, wenn nur null enthalten (FIPS-8575)
null und Blank-String bei der Wertemenge von String-Attributen gleich behandeln (FIPS-8662)
properties-Datei mit Default-Relevance-Validierungstexten auch mit "_en" kopieren (FIPS-8708)
DefaultGenericAttributeValidationConfiguration unterstützt Pflichtfeldmarker unmittelbar (FIPS-8740)
DatatypeDefinitions-Konfiguration vereinfachen (FIPS-8772)
@IpsAssociationRemover verbessern (FIPS-8794)
associationsInFormulas rausschmeißen (FIPS-6753)
Abfragemöglichkeit bzgl. Eigenschaft "Qualifizierung" einer Vertragsbeziehung (FIPS-8314)
variedBase setzbar machen (FIPS-8807)
Aufzählung als Einschränkung einer Range erlauben (FIPS-5698)
IpsMatchers um hasMarker(IMarker): Matcher<Message> ergänzen (FIPS-8741)
JUnit-5-Adapter für IPS-Tests (FIPS-7298)
XML-Schema für .ipsproject (FIPS-8675)

Behobene Fehler

@since sollte auch in Code generiert werden, wenn keine Version im Projekt angegeben wurde (FIPS-6474)
Bei erweiterbaren Enums wird fehlerhafter Code für Equals und Hashcode generiert wenn die ID ein primitiver Datentyp ist (FIPS-6644)
Multi-Value-Attribute: Leere Listen und Null (FIPS-6872)
Enum-Contents sind nicht wirklich Serializable (FIPS-7198)
Konsequente Exceptions beim Vergleich mit DecimalNull (FIPS-7292)
Fehler bei konfigurierten Ableitungen nicht-konfigurierter Oberklasse (FIPS-7497)
Dokumentation bei Valdierungen nicht im JavaDoc (FIPS-8197)
uniqueQualifier wirken sich nicht auf .properties aus (FIPS-8401)
Performance: AbstractIpsBundleContentIndex#getQualifiedNameTypes() (FIPS-8534)
SimpleCache gibt nichts zurück (FIPS-8676)
Beim Schreiben des Manifest müssen " escaped werden (FIPS-8790)
Migration passt MANIFEST.MF jetzt auch in src/main/resources an (FIPS-8937)
Null-Objekte werden beim Vergleich in Range-Strukturen von Tabellen explizit behandelt (FIPS-8936)
Noch mehr Leerzeichen im generierten Javadoc entfernt (FIPS-8867)
Verwendung lokaler XSDs zur Validierung im Betrieb offline/hinter Proxy (FIPS-8863)
Veraltete commons-collections-dependency entfernt (FIPS-8926)
XML-Attribute, die meist leer/false sind sind jetzt optional und werden nicht mehr geschrieben (FIPS-8891)
Migration von @generated REDIRECT für Vereinheitlichte Wertebereichsmethoden dokumentiert (FIPS-8904)
ClassCastException bei mvn install mit faktorips-maven-plugin (FIPS-8796)
Rückwärtskompatibilität wieder hergestellt, damit mit Faktor-IPS 21.6/12 generierter Code auf der Runtime von 22.6 läuft (FIPS-8836)
Beschreibung im Migrationsdialog nach 22.6.0 überarbeiten (FIPS-8838)
Migration ändert unter Windows in der .ipsproject Slashes zu Backslashes (FIPS-8859)
IPS-Codegenerator erzeugt wieder ein Blank im Kommentar (FIPS-8867)
Extensible Enum: Neue Variable muss serialVersionUID ändern (FIPS-8871)
Message.Builder#invalidObjectWithProperties löscht bereits gesetzte ObjectProperties (FIPS-8876)
MessageListMessageMatcher#describeMismatchSafely sollte die MessageList beschreiben (FIPS-8878)
Asciidoc zerlegt Regex (FIPS-8899)
getValueByNameMethod verschwindet bei Migration aus .ipsproject (FIPS-8917)
Labels für produktkonfigurierte Vertragsattribute unpräzise (FIPS-8911)
Bei Kombination aus BOTH und UNIFIED generiert FIPS nicht alle notwendigen Methoden (FIPS-8906)