This section describes the concepts behind the PomStrap bootstrap configuration. Typically, the PomStrap bootstrap configuration options can be specified as part of the root dependency POM in the PomStrap plug-in configuration section.
To cater for special circumstances, the PomStrap bootstrap configuration can be also specified as part of a user specific properties file and on the command line of the PomStrap cli utility. The use to latter two mechanisms for options that affect the behaviour of the PomStrap bootstrap with respect to the organisation of the dependency graph is highly discouraged.
An artifact repository is a collection of binary software artifacts and metadata stored in a defined directory structure which is used by clients such Maven, Mercury, or Ivy.
PomStrap requires the access to one repository in order to load jars and artifact metadata. One artifact repository can be configured by means of a HTTP url and an optional username and password if authentication is required.
If no remote artifact repository is configured, PomStrap uses the current user's local Maven repository. The default location of user's local Maven repository is $HOME/.m2/repository. An alternative location can be specified by means of the property localRepository.
The dependency exclusion mechanism is useful to remove unwanted dependencies form the resulting dependency graph. Conceptually it is identical to the Maven's standard dependency exclusion mechanism
In complex projects it is likely that different version of the same artifact appear in the dependency graph.
For example, the artifact example:one depends on log4j:log4j:1.2.15 and example:two. The artifact example:two in turn depends on log4j:log4j:1.2.12 and other artifacts. In order to ensure the correct functioning of the logging library log4j, only one class-loader instance corresponding to log4j:log4j should appear in the dependency graph.
The singleton mechanism allows to limit to one the number of class-loaders corresponding to one dependency artifact.
Given a dependency graph, the PomStrap bootstrap normally creates one class-loader for each artifact dependency.
Certain libraries - notably the Hibernate ORM framework - assume that their components dependency artifacts are to be loaded by the same class-loader. If this assumption is not satisfied, an access violation exception will be thrown whenever a class loaded by one class-loader tries to access protected classes from other class-loaders.
The grouping mechanism allows to load a set of dependency artifacts within the same class-loader. As a consequence, PomStrap will modify the resulting dependency graph so that the required artifacts are grouped together.
Multiple distinct dependency groups can be configured for one dependency graph.
Class file transformation is an advanced feature available since Java version 1.5. They allow to modify class files at run-time. The transformation occurs before the class is defined by the JVM.
Typically, the functionalities provided by class file transformers are only available by means of instrumentation agents. The set-up of a JVM agent requires the modification of the JVM bootstrap options.
PomStrap allows to activate multiple class file transformers per-PomStrap bootstrap instance. As multiple PomStrap boostraps can be instantiated within the same JVM, PomStrap allows to restrict the scope one of more class file transforms to well defined groups of class-loaders.
One of the most useful class-transform is the AspectJ load-time weaving (LTW) class file transformer.
Given an applications deployed to a Maven repository, the corresponding dependency tree is uniquely determined by the artifact dependency relationships expressed by means of POM projects descriptors. In order to change any of the dependency that are part of the dependency graph, it is necessary to modify the source POM descriptors for a given set of projects, re-deploy those projects using Maven and then re-deploy and re-start the application. This is the normal workflow that ensures a repeatable development process.
There a number of circumstances when the described workflow is less than ideal. For example, when an application defect is found and a simple fix has been implemented, it would be desirable to quickly test the application in question with the same dependency tree with the exception of the dependency artifact where the fix has been made.
The dependency transformation mechanism allows to swap at run-time one dependency for another. For example, given a dependency example:one:1.2.2 we can configure PomStrap to load example:one:1.2-SNAPSHOT in place of any occurrence of example:one:1.2.2 in the dependency graph.
