Configuration Files of Apache Archiva
- :STUB: This is a documentation stub.
+ While Archiva is primarily configured via the graphical administration interface, it stores all configuration in XML configuration
+ files that can be hand edited and used for backup and migration.
+ The following files compose the configuration for Archiva:
+
+ * <<<archiva.xml>>> - this is the primary Archiva configuration file
+
+ * <<<security.properties>>> - this configures the security as described in the {{{security.html} security configuration documentation}}
+
+ * <<<plexus.xml>>> - only applies when running the standalone Archiva instance, as described in the {{{standalone.html} installing Archiva standalone documentation}}
+
+ This section will focus on the <<<archiva.xml>>> file.
+
+* The Archiva configuration file
+
+ The Archiva configuration file is stored in one of two locations:
+
+ * The application server configuration directory (see {{{standalone.html} installing Archiva standalone}} for more information)
+
+ * The user home directory (<<<~/.m2/archiva.xml>>>).
+
+ []
+
+ When modified in the GUI, the file is written back to the location it was initially read from, with the home directory taking priority if both exist. When using a
+ standalone installation, it is highly recommended that a configuration file is only maintained in one of the locations.
+
+ The following shows a basic configuration file:
+
+----
+<configuration>
+ <version>2</version>
+ <managedRepositories>
+ <managedRepository>
+ <location>${appserver.base}/repositories/internal</location>
+ <daysOlder>30</daysOlder>
+ <id>internal</id>
+ <name>Archiva Managed Internal Repository</name>
+ </managedRepository>
+ </managedRepositories>
+ <remoteRepositories>
+ <remoteRepository>
+ <url>http://repo1.maven.org/maven2</url>
+ <id>central</id>
+ <name>Central Repository</name>
+ </remoteRepository>
+ </remoteRepositories>
+ <proxyConnectors>
+ <proxyConnector>
+ <sourceRepoId>internal</sourceRepoId>
+ <targetRepoId>central</targetRepoId>
+ <policies>
+ <releases>always</releases>
+ <checksum>fix</checksum>
+ <snapshots>never</snapshots>
+ <cache-failures>no</cache-failures>
+ </policies>
+ </proxyConnector>
+ </proxyConnectors>
+</configuration>
+----
+
+ ~~TODO: need a full reference
Runtime Configuration of Apache Archiva
- :STUB: This is a documentation stub.
+ Archiva is primarily configured via the graphical administration interface.
+
+ The following describe the various sections of the administration menu:
+
+ * {{{repositories.html} Configuring repositories}}
+
+ * {{{proxy-connectors.html} Configuring proxy connectors}}
+
+ * {{{network-proxies.html} Configuring network proxies}}
+
+ * {{{consumers.html} Configuring repository scanning and consumers}}
+
+ []
Apache Archiva Databases
- :STUB: This is a documentation stub.
+ Archiva uses an external database for two purposes:
-~~TODO: give general information on configuration for an external database
-~~TODO: use mysql or external derby as an example
+ * Storing artifact information
+
+ * As a default user store for security
+
+ []
+
+ Generally, it is unnecessary to configure anything - the built in embedded database is suitable for the artifact management, and if
+ an external authentication mechanism is not needed, the user database.
+
+ However, it is possible to configure an external database as needed.
+
+* Configuring an external database
+
+ Archiva uses JNDI data sources to locate the databases to use:
+
+ * <<<jdbc/archiva>>> - the repository database
+
+ * <<<jdbc/users>>> - the user store
+
+ Configuring an external database for either or both of these sources depends is configured in <<<plexus.xml>>> if you are using the
+ {{{standalone.html} standalone installation}}, or in the application server configuration if you are using the {{{webapp.html} web application
+ installation}}.
+
+* Backing up the database
+
+ While it is a good idea to back up both databases, it is not strictly necessary to back up the repository database on a regular basis. Should any
+ data loss be suffered, this database can be regenerated by deleting it's contents and re-scanning the repositories.
+
+ If you are using the default user security mechanism, it is important to back up the users database on a regular basis to ensure that the user
+ passwords and information are not lost in the event of corruption. With the default embedded storage this is simply a matter of making a copy of
+ the database directory on the filesystem. If you have configured an external database as the source for user information, please refer to your
+ database documentation for backup instructions.
+
~~TODO: link to wiki location that does others
System Administrators Guide to Apache Archiva
- :STUB: This is a documentation stub.
+ Archiva is designed to be simple to install and maintain - including both manual configuration files and a comprehensive
+ graphical administration interface.
+
+ The following sections describe the process for configuring Archiva for use:
+
+ * {{{installing.html} Installing Archiva}}
+
+ * {{{databases.html} Configuring databases for Archiva}}
+
+ * {{{security.html} Configuring security for Archiva}}
+
+ * {{{configuration.html} Using the graphical administration interface}}
+
+ * {{{configuration-files.html} The configuration files available for Archiva}}
+
+ * {{{reports.html} Repository health reports}}
+
+ []
+
Installing Apache Archiva
- :STUB: This is a documentation stub.
+ Whether you choose to install Archiva as a standalone application or as a web application in your preferred Java EE
+ application server, only a minimal amount of configuration is necessary.
+
+ The following documents cover the different installation alternatives:
+
+ * {{{standalone.html} Installing standalone}}
+
+ * {{{webapp.html} Installing as a web application}}
-~~TODO: ensure upgrading is covered - does it need to be a separate doc
Understanding Network Proxy Configuration of Apache Archiva
- :STUB: This is a documentation stub.
+ Archiva uses the terminology "proxy" for two different concepts:
+
+ * The remote repository proxying cache, as configured through {{{proxy-connectors.html} proxy connectors}} between repositories
+
+ * Network proxies, which are traditional protocol based proxies (primarily for HTTP access to remote repositories over a firewall)
+
+ []
+
+ Network proxies are configured using standard HTTP proxy settings as provided by your network administrator.
+
+ Once configured, the network proxy can be attached to operations that access remote resources. At present, this is configured on the
+ remote repository proxy connectors that need to access the remote repository over the HTTP protocol.
+
+ ~~TODO: walkthrough configuration
Understanding Proxy Connector Configuration of Apache Archiva
- :STUB: This is a documentation stub.
+ Archiva uses the terminology "proxy" for two different concepts:
+
+ * The remote repository proxying cache, as configured through proxy connectors between repositories
+
+ * {{{network-proxies.html} Network proxies}}, which are traditional protocol based proxies (primarily for HTTP access to remote repositories over a firewall)
+
+ []
+
+ A proxy connector is used to link a managed repository (stored on the Archiva machine) to a remote repository (accessed via a URL). This will mean that when a request
+ is received by the managed repository, the connector is consulted to decide whether it should request the resource from the remote repository (and potentially cache
+ the result locally for future requests).
+
+ Each managed repository can proxy multiple remote repositories to allow grouping of repositories through a single interface inside the Archiva instance. For instance,
+ it is common to proxy all remote releases through a single repository for Archiva, as well as a single snapshot repository for all remote snapshot repositories.
+
+ A basic proxy connector configuration simply links the remote repository to the managed repository (with an optional network proxy for access through a firewall).
+ However, the behaviour of different types of artifacts and paths can be specifically managed by the proxy connectors to make access to remote repositories more flexibly controlled.
+
+* Configuring policies
+
+ When an artifact is requested from the managed repository and a proxy connector is configured, the policies for the connector are first consulted to decide whether
+ to retrieve and cache the remote artifact or not. Which policies are applied depends on the type of artifact.
+
+ By default, Archiva comes with the following policies:
+
+ * <<<releases>>> - how to behave for released artifact metadata (those not carrying a <<<SNAPSHOT>>> version). This can be set to <<<always>>> (default), <<<hourly>>>, <<<daily>>>, <<<once>>> and <<<never>>>.
+
+ * <<<snapshots>>> - how to behave for snapshot artifact metadata (those carrying a <<<SNAPSHOT>>> version). This can be set to <<<always>>> (default), <<<hourly>>>, <<<daily>>>, <<<once>>> and <<<never>>>.
+
+ * <<<checksum>>> - how to handle incorrect checksums when downloading an artifact from the remote repository (ie, the checksum of the artifact does not match the corresponding detached checksum file).
+ The options are to fail the request for the remote artifact, fix the checksum on the fly (default), or simply ignore the incorrect checksum
+
+ * <<<cache-failures>>> - whether failures retrieving the remote artifact should be cached (to save network bandwidth for missing or bad artifacts), or uncached (default).
+
+ []
+
+* Configuring whitelists and blacklists
+
+ By default, all artifact requests to the managed repository are proxied to the remote repository via the proxy connector if the policies pass. However, it can be more efficient to
+ configure whitelists and blacklists for a given remote repository that match the expected artifacts to be retrieved.
+
+ If only a whitelist is configured, all requests not matching one of the whitelisted elements will be rejected. Conversely, if only a blacklist is configured, all requests not matching one of
+ the blacklisted elements will be accepted (while those matching will be rejected). If both a whitelist and blacklist are defined, a path must be listed in the whitelist and not in the blacklist
+ to be accepted - all other requests are rejected.
+
+ The path in the whitelist or blacklist is a repository path, and not an artifact path, and matches the request and format of the remote repository. The characters <<<*>>> and <<<**>>> are wildcards,
+ with <<<*>>> matching anything in the current path, while <<<**>>> matches anything in the current path and deeper in the directory hierarchy.
+
+ For instance, to only retrieve artifacts in the Apache group ID from a repository, but no artifacts from the Maven group ID, you would configure the following:
+
+ * White list: <<<org/apache/**>>>
+
+ * Black list: <<<org/apache/maven/**>>>
+
+ []
+
+ ~~TODO: walkthrough configuration
:STUB: This is a documentation stub.
+ ~~TODO: walkthrough configuration
~~TODO: link to quick start as it covers the most basic scenario
~~TODO: ensure to refer to advanced configuration options, such as PLEXUS_BASE
+~~TODO: upgrading
Installing Apache Archiva as a Web Application
~~TODO: link to wiki location for other application servers
+~~TODO: upgrading
To deploy Archiva on Tomcat 5.5
your artifact utilisation with search, browse and reporting, and perform routine
maintenance on your repositories.
- ~~TODO: improve appearance of links
-
- To get started with Archiva, read the following documentation:
+ To get started with Archiva, you can read the following documentation:
* {{{quick-start.html} A Quick Getting Started Guide}}
Release Notes for Archiva 1.0
-~~TODO: paste, instructions, etc?
+ The Apache Archiva team would like to announce the release of Archiva 1.0.
+
+ Archiva 1.0 is {{{/download.html} available for download from the web site}}.
+
+ Archiva is an application for managing one or more remote repositories, including administration, artifact handling, browsing and searching.
+
+ If you have any questions, please consult:
+
+ * the web site: {{http://maven.apache.org/archiva/}}
+
+ * the archiva-user mailing list: {{http://maven.apache.org/archiva/mail-lists.html}}
+
+* Release Notes
+
+ The full list of changes can be found {{{http://jira.codehaus.org/secure/ReleaseNote.jspa?version=12113&styleName=Text&projectId=10980} in JIRA}} and is reproduced below:
+
+~~TODO: paste
+
- {{{http://jira.codehaus.org/secure/ReleaseNote.jspa?version=12113&styleName=Text&projectId=10980} Release Notes from JIRA}}
User Guide
- :STUB: This is a documentation stub.
+ Welcome to the Archiva user's guide. Getting to know and use Archiva is very simple - please select one of the following documents to learn how to use
+ Archiva quickly.
+
+ * {{{browsing.html} Browsing Archiva repositories}}
+
+ * {{{searching.html} Searchin Archiva repositories}}
+
+ * {{{find-artifact.html} Identifying an unknown artifact by comparing the repository checksum database}}
+
+ * {{{using-repository.html} Using Archiva as a repository for Maven, Ivy, etc.}}
+
+ * {{{deploy.html} Deploying artifacts to the repository}}
+
+ []
+
+
projects / archiva.git / commitdiff