The Proximity gathers one or more repositories. Each repository have well defined API and behaviour. The behaviour of a repository is affected by multiple factors.
A repository at glance in Proximity have these properties:
The two most important component, the localStorage and remotePeer is the main factor in repository behaviour. The second most important is the repositoryLogic. All these components are "pluggable", and loosely coupled, since they are actually implementations of their respective interfaces.
As we have seen, the repository itself is like rubber, and is robust to compete with almost every component combinations. Naturally, some of these will be rather nonse to use, but it is up to user to do a proper configuration.
| With remote peer | Without remote peer | |
| Without local storage | non-caching proxy (will not speed up anything) | will work, but nonsense (without content) |
| With ReadOnly local storage | non-caching proxy (usable for intentional artifact spoofing) | inhouse repository (with local static content, usable for inhouse repository hosting) |
| With ReadWrite local storage | caching proxy (the real value, will proxy and cache) | inhouse repository (but write operation will occur only on WebDAV deployment, logical equivalent of upper one) |
Thus, first we have to choose what intention will repository serve for us, and configure it the needed way. But remember, the Repository Logic has also large influence on how repository works!
Used in "direct addressing" the given repository. Used for example on WWW interface and "piping".
If more than one repository is member of one group (have same groupId's), their metadata content will be merged. Usable for Maven plugin developers, who needs snapshots from snapshot repositories. If not specified, the "default" string will be used.
Local storage implementation. Currently two implementation exists: ReadOnlyFileSystemStorage usable for hosted repositories and WritableFileSystemStorage usable for proxied repositories. If not specified, the repository will have no local storage (see upper table).
Remote storage implementation. Currently two implementation exists: CommonsHttpClientRemotePeer and CommonsNetFtpRemotePeer. Obviously, Jakarta Commons HttpClient and Net components are used in their implementations. If not specified, the repository will have no remote storage (see upper table).
The most trickiest part of Repository. The logic "drives" the retrieval of the current request. This is the part where Proximity-M offers "Mavenized" logic to drive retrieval. If not specified, repository defaults to DefaultProxyingRepositoryLogic which is not Maven aware.
If repository have local storage, and if local storage is writable, and if local storage is set to be metadata aware, the metadata will be recreated at startup. Defaults to true. Furthermore, if indexer is defined, and if reindex is true, reindexing will occur on Proximity startup. If indexer is not specified, this parameter is neglected. If not specified, it defaults to true. The lack of indexer does not affect the metadata recrate mentioned before.
If true, the content of the repository appears on repository browsing page. If false, it will be not browsable, but it will be still reachable by direct HTTP GET requests, thus it will be still available to Maven. Defaults to true.
If false, repository will reject all incoming requests. Defaults to true.
If true, and if repository have remote peer, the repository will not try to fetch anything from remote peer, it will serve what it have in cache (if have cache). Defaults to false.
Proximity offers three Repository Logic implementations:
and finally, the Maven "specialized" one, that "recognizes" Maven internals:
Look at their sources for setup possibilites.