Version 3.13.0

New and Noteworthy in Version 3.13.0

The new Faktor-IPS version 3.13 brings improvements in the usability and performance area. Most notably the Faktor-IPS runtime libraries can be retrieved via the Maven Central Repository. Other highlights are detailed below. At the end of this page a complete list of changes can be found.

Deactivation of validation and code generation


Particularly in long running projects there is a tendency for developers to continue developing in the Java code while the relatively stable model is mainly used for documentation. However, building and validating an unaltered model every time causes unnecessary delays in clean-builds.

In this case developers can now switch to the Browse mode. The Browse mode can be selected directly via button f10-org-new_3_13_0-ansicht_bearbeitung_icon or via the user setting. In this mode, Faktor-IPS objects cannot be edited and no validation or code generation takes place.

Large tables

Another cause for delays during the project builds is the validation of content of large tables. Especially when dealing with complex keys in tables with thousands of rows this might take a while. Naturally, using the Browse mode is no option for product developers.

The new Faktor-IPS version allows for the validation of table content to be deactivated in the user settings. Deactivating the option will lead to quicker updates and build times, as tables aren’t loaded in the first place.

If the table makes use of enum values this option should be used carefully. If enums changed, invalid entries in tables would not be detected.

When opening tables in the editor, however, the content is loaded and validated regardless of this option.

Improved enum-value entry

The editing of enum values is simplified by new controls. Beside the existing value selection there is now the possibility of direct entry via keyboard.

The following improvements were implemented:

  • Value search: Partially typed values will bring up a list of possible matches, helping find the desired value. Useful for large enums.
  • Quick entry: Known enum values can be entered directly via name or ID, without having to resort to the search functionality or the drop-down menu.

Baseclass for modelstructures

Faktor-IPS now allows defining a common base class for all policy classes (i.e. layer supertype). This was impossible before as all types in a hierarchy had to be either product-configured or not. Now configured policy component types can inherit from un-configured types.

f10-org new_3_13_0 fips-1221

This results in some key changes to the base classes of the Faktor-IPS runtime. All generated policy classes, both product configured and not, directly inherit from AbstractModelObject. The dependency to the class AbstractConfigurableModelObject was removed altogether.

Such a base class can be used to define properties common to all policy classes, for instance a technical ID for database persistence.

Faktor-IPS runtime available on Maven-Central-Repository

The Runtime, Valuetypes and Valuetypes-Joda libraries are now available via the Maven Central Repository. A guide on how to use the Maven Dependency Management with Faktor-IPS will be released shortly on our homepage. To include the runtime libraries the appropriate entry in the Maven configuration pom.xml is sufficient.

Dependency definition to the Faktor-IPS runtime and Valuetypes in pom.xml


Inclusion of the Valuetypes-Joda library including Joda-Time


Migration 3.13

To be able to use Faktor-IPS 3.13, existing projects need to be migrated. This can be achieved easily by selecting the appropriate entry in the context menu.

With the migration the XML files for table contents are converted to the new file structure.

Possibly existing XML adapter classes will have to be deleted manually. See: XMLAdapter

Generated code and runtime


The generated XmlAdapter classes for extensible enums are now placed into the „src“ directory instead of „derived“. Although the classes still can’t be edited manually this change was made for improved compatibility with the Maven project configuration. This way, no Java source code is written to the derived directory. The separation between „src“ and „derived“ conforms to Mavens concept of „sources“ and „resources“.

The old classes in the „derived“ directory are deleted if the option „Derived Resources“ is set to true in the generator configuration. Otherwise the existing files (* have to be deleted manually.

Support Serializable for model classes

Serialization can be a useful feature when using Faktor-IPS in application server contexts, for the purpose of persisting sessions, for instance.

Support for serialization can now be activated in the code generator configuration. With that, all generated policy classes are serializable. Since the product classes and the runtime repository are not serializable, a project-specific implementation of the interface IRuntimeRepositoryLookup has to be set in the runtime repository. It can be implemented as static access to the runtime repository.

Attention: The currently generated code for serialization does not increment the serial version UID upon model changes. The serialVersionUID is always generated with value 1L. Therefore the application should guarantee that no old model states are unserialized after model changes were made. Otherwise this could cause corruption of policy data!

Generally, using serialization in Java comes with lots of implications and should be carefully considered. Reading chapter 11 of the book „Effective Java“ by Joshua Bloch for a better understanding of the subject is recommended.

AbstractConfigurableModelObject removed

As noted in „Base class for modelstructures“, all generated runtime classes now inherit from AbstractModelObject. Product-configured classes additionally implement the interface IConfigurableModelObject. The base class AbstractConfigurableModelObject was removed altogether.

Message and ObjectProperty

The API of the class org.faktorips.runtime.Message was extended. A message can now contain a list of markers. The concrete use of markers are project-specific, for instance a special enum. Together with this change the enum Severity was moved to its own class. Code that manually accesses this enum might need to be updated. The use of markers on messages is still in an early development stage, therefore changes to its API in future versions are possible.

To instantiate messages new static methods were introduced which use the builder pattern. With them, new messages can be instantiated comfortably. Examples:

  // New error message
  Message.error("Error while doing anything").code("ERROR_CODE").invalidObjects(theObject, "anything").create();
  // New warning mMessage with specified invalid object: Property "anything" on object "theObject"
  Message.warning("Warning while doing anything").code("WARNING_XY").invalidObjects(theObject,  "anything").create();

For the class ObjectProperty a new attribute qualifier of type IPropertyQualifier was introduced.

It can be used to provide the qualifier of invalid (qualified) associations. The implementation of IPropertyQualifier is project specific for now. A standard implementation may be implemented in future releases.