Each artifact has a unique identifier conforming to the Transit artifact protocol specification. Using a standard extension to the java.net.URL class in the Java API, Transit accesses an artifact through an artifact URI. The artifact URI logically identifies a resource and the Transit system provides the means for resource retrieval.
The artifact URI describes the:
- type of resource (JAR, meta, template...)
- group to which the artifact belongs
- name of the artifact
- version
The purpose of the group is to avoid naming conflicts in the artifact name space. The top level group should be a distinguishable and well accepted name of the organization, and any sub groups to be decided by the organization itself to further avoid name clashes. It is recommended that the bottom level group is the release level, i.e. all resources within the 'release' shares the same version and are meant to be working in a group within that version, and not mixed between versions.
Transit promotes strong version management. The underlying concern is that many parts of the system are dependent on particular versions of another part or resource, and can not be freely mixed. To ensure that all dependencies are resolved against the proper versions, it is paramount that a version management system is in place, and policies are established. From Transit's point of view, the version is an opaque identifier without any in-built semantic meaning.
These identifiers disassociate the definition of an application from the source of the resources needed to build and deploy the application. Meaning, it is only in the interest of the user of the resources, be it built tools or running applications, that the correct resources are provided, and not from which server these were downloaded. The task of resolving the location is transferred from each application to Transit itself, which is configured to know about which servers are available in its running environment.