Instances of this interface holds data in order to properly configure an IDE project for a user, to be able to take advantage of IDE related features. (E.g. content assist) Instances should contain the data necessary to configure an IDE project for convenient and daily use.
Examples:
- A Java IDE configuration should contain the source directories, classpath, and other related data.
- A C/C++ IDE configuration should contain the compiled sources, include directories, linked libraries, and other related data.
The data contained in an IDE configuration can be accessed via the getField(
An IDE configuration should consist of boxed primitives, String, Collection<?>, Map<String, ?> instances and their compositions. This is to ensure that IDE configuration objects can be transferred properly between processes, and they can be serialized into arbitrary external formats (E.g. JSON, XML). Boxed primitive objects should be handled without precision, meaning that a value should have the same semantics regardless if they're represented using a Short or Long.
When including path related information about the build, it is recommended to use execution related absolute paths. Unless they are directly associated with another file system (local or remote), the paths should point to a file or directory that are accessible using the execution path configuration roots.
Implementation of this interface should be Serializable, preferably Externalizable.
The field names can be arbitrary. They should represent their meaning for a project configuration. It is best that they are short and describe what kind of aspect they correspond to.
If a field has a multiple value then its name should be plural. (E.g. source_dirs
,
include_dirs
)
Although it is not necessary if the usage does not require it. (E.g. both classpath
and
classpaths
should be okay)
Field values should be boxed primitives, String, Collection, Map<String, ?> and compositions of their instances.
Any returned field values should be immutable.
null
if it is not set.
If a field name is present in this returned collection then getField(null
. It is an error to return null
if the field name is present in this
collection, but users of this class should be able to handle that gracefully.
This identifier should be based on a build step or location so the user can identify its correspondence to a build task. It is best if it's unique for a given IDE configuration type.
For example it can be an explicitly assigned identifier by the user, or a base source directory for the task which generated this configuration.
The type can be an arbitrary string which uniquely identifies a type of an IDE configuration. It is recommended that it is a dot separated name identified by the developer domain. (Like reverse domain naming in Java packages.)
The available field names for a given type should be documented by the developer of the given typed IDE configuration.