Browse files

o move to tesla site documentation

  • Loading branch information...
1 parent f3c4b37 commit d6cb229594f5bb94b44100408f7d0184982c25e7 Jason van Zyl committed Jul 11, 2012
@@ -1,2 +0,0 @@
-Based on Aether 1.9+ ([AETHER-50](, this feature branch enables
-core extensions to provide an alternative format for the local repository.
@@ -1,22 +0,0 @@
-Based on improvements in Aether 1.12 ([AETHER-98](, this feature branch
-makes Maven configure (repository-specific) HTTP request headers for Aether based on the [Wagon-style server configuration](
-from the `settings.xml`, i.e.:
- <settings>
- <servers>
- <server>
- <id>my-server</id>
- <configuration>
- <httpHeaders>
- <httpHeader>
- <name>Foo</name>
- <value>Bar</value>
- </httpHeader>
- </httpHeaders>
- </configuration>
- </server>
- </servers>
- </settings>
-The above snippet is already functional with stock Maven when the Wagon-based repository connector is used. This branch
-decouples support for HTTP headers from Wagon/Plexus and generalizes it to all connectors like AHC.
@@ -1,19 +0,0 @@
-Expendable repository mirror selection.
-Introduced new MirrorSelectorDelegate component interface. For repositories
-that do not have matching <mirror/> element in global/user settings.xml
-files, all registered MirrorSelectorDelegate implementations will be called
-in no particular order and first not-null Mirror will be used.
-MirrorSelectorDelegate can associate credentials information with returned
-Mirror instances. Because of this, MirrorSelectorDelegate are NOT required to
-change repository id when using mirrors. This is useful when mirror is known
-to be exact copy of the original repository and use of the same repository id
-for direct and mirror access allows better sharing of artifacts in Maven local
-The main underlaying usecase is automatic mirror repository discovery based
-on specifics of build environment. For example, a MirrorSelectorDelegate
-implementation could negotiate available mirror repositories with a local
-repository manager, thus eliminating the need to manually maintain <mirror/>
-and <server/> configuration in settings.xml.
@@ -1,5 +0,0 @@
-This feature branch adds support for project-specific Aether configurations by associating a `RepositorySystemSession` with
-each `MavenProject` instance. By default, all projects in a build session will use the same Aether configuration, a new
-extension point in form of a `ProjectBuilderDelegate` can then be used to customize the Aether session for a given project.
-As a concrete example, an extension plugin could configure project-specific HTTP request headers for dependency resolution.
@@ -1,8 +0,0 @@
-This branch introduces a new extension point `RepositorySystemSessionFactoryDelegate` for core extensions to customize
-the base Aether configuration to use. In more practical terms, this feature allows extensions to change conflict resolution,
-authentication/proxy/mirror selection or to introduce additional workspaces to overlay artifacts.
-There is generally a chicken-egg scenario when it comes to customizing the Aether configuration via extensions. Obviously,
-any extension that is resolved from a repository cannot customize the Aether configuration used during its own resolution
-process. As such, this feature targets extensions that get manually installed into `lib/ext` of a Maven distribution or
-via bundle fragments for M2E's Maven runtime. Open for discussion/review is the interaction with session extensions.
@@ -1,21 +0,0 @@
-Session extensions are similar to maven extensions plugins, except session extensions cannot define any goals, only
-components. Session extensions are created during maven session setup and their components are available for the entire
-duration of the session.
-Session extensions are "installed" by creating an xml file in extension configuration directory, ~/.m2/ext/ by
-default. -Dmaven.ext.conf.dir=<some-path> can be used to specify different configuration directory path and
--Dmaven.ext.conf.dir can be used to suppress session extensions.
-Extensions configuration files
-Supported component configuration parameters
-${settings} merged global, user and extensions settings. <pluginRepositories/> and <properties/> from extension.xml
-file are injected in a new settings profile named after the extension, i.e. if the extension is defined in file
-foo-extension.xml, the injected profile will have id foo. <server/> elements defined in extension.xml file override
-<server/> elements with same id defined in settings.xml file.
-${property} String value with corresponding key in <properties/> map. <properties/> map is merged from extension.xml,
-active profiles in settings.xml, user properties and system properties.

0 comments on commit d6cb229

Please sign in to comment.