Return-Path: X-Original-To: apmail-archiva-commits-archive@www.apache.org Delivered-To: apmail-archiva-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3DA29DE78 for ; Wed, 19 Sep 2012 13:36:41 +0000 (UTC) Received: (qmail 14587 invoked by uid 500); 19 Sep 2012 13:36:41 -0000 Delivered-To: apmail-archiva-commits-archive@archiva.apache.org Received: (qmail 14537 invoked by uid 500); 19 Sep 2012 13:36:41 -0000 Mailing-List: contact commits-help@archiva.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@archiva.apache.org Delivered-To: mailing list commits@archiva.apache.org Received: (qmail 14528 invoked by uid 99); 19 Sep 2012 13:36:41 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Sep 2012 13:36:41 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Sep 2012 13:36:30 +0000 Received: from eris.apache.org (localhost [127.0.0.1]) by eris.apache.org (Postfix) with ESMTP id B7441238890B for ; Wed, 19 Sep 2012 13:35:44 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r1387591 [2/8] - in /archiva/site-content/docs/1.3.5: ./ adminguide/ css/ customising/ images/ images/logos/ images/tour/ tour/ userguide/ Date: Wed, 19 Sep 2012 13:35:41 -0000 To: commits@archiva.apache.org From: olamy@apache.org X-Mailer: svnmailer-1.0.8-patched Message-Id: <20120919133544.B7441238890B@eris.apache.org> Added: archiva/site-content/docs/1.3.5/adminguide/installing.html URL: http://svn.apache.org/viewvc/archiva/site-content/docs/1.3.5/adminguide/installing.html?rev=1387591&view=auto ============================================================================== --- archiva/site-content/docs/1.3.5/adminguide/installing.html (added) +++ archiva/site-content/docs/1.3.5/adminguide/installing.html Wed Sep 19 13:35:36 2012 @@ -0,0 +1,279 @@ + + + + + + + + + + + + + + Archiva Documentation - Installing Apache Archiva + + + + + + + + + + + +
+ +
+
+
+

Installing Apache Archiva

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:

+
+
+
+
+
+ + + Added: archiva/site-content/docs/1.3.5/adminguide/legacy.html URL: http://svn.apache.org/viewvc/archiva/site-content/docs/1.3.5/adminguide/legacy.html?rev=1387591&view=auto ============================================================================== --- archiva/site-content/docs/1.3.5/adminguide/legacy.html (added) +++ archiva/site-content/docs/1.3.5/adminguide/legacy.html Wed Sep 19 13:35:36 2012 @@ -0,0 +1,287 @@ + + + + + + + + + + + + + + Archiva Documentation - Apache Archiva legacy repository support configuration + + + + + + + + + + + +
+ +
+
+
+

Apache Archiva legacy repository support configuration

Archiva supports both Maven 1 and Maven 2 clients transparently when used as a proxy. The underlying managed repository can use either the default or legacy layout, and Archiva will convert the requested path to the expected internal format.

However, due to the lack of structure in maven 1 "legacy" artifact request format, Archiva must split the request path to discover artifactId, version and classifier - and this is not always deterministic. The strategy used by Archiva has been tested on many existing artifacts in the public central repository, but users may require support for private artifacts or for artifacts with classifiers.

Since version 1.0.1, Archiva provides a legacy support configuration to the administrator. It is possible to register some custom legacy path and the expected artifact reference. Archiva will check that the entered artifact referen ce matches the legacy path, to avoid corrupted data in repository.

For example:

  • Path: jaxen/jars/jaxen-1.0-FCS-full.jar
  • Group ID: jaxen
  • Artifact ID: jaxen
  • Version: 1.0-FCS
  • Classifier: full
  • Type: jar

This prevents the artifact incorrectly getting translated to a version of 1.0 and a classifier of FCS-full.

Those custom legacy path are stored in the archiva.xml configuration file. By default, jaxen-1.0-FCS-full is registered, as it is used by some core Maven 1 plugins (however this is not the case if you upgraded from a previous version and retained your configuration file).

+
+
+
+
+
+ + + Added: archiva/site-content/docs/1.3.5/adminguide/logging.html URL: http://svn.apache.org/viewvc/archiva/site-content/docs/1.3.5/adminguide/logging.html?rev=1387591&view=auto ============================================================================== --- archiva/site-content/docs/1.3.5/adminguide/logging.html (added) +++ archiva/site-content/docs/1.3.5/adminguide/logging.html Wed Sep 19 13:35:36 2012 @@ -0,0 +1,279 @@ + + + + + + + + + + + + + + Archiva Documentation - Log Files + + + + + + + + + + + +
+ +
+
+
+

Log Files

To keep track of the Archiva performance and problems, log files are created during runtime. These files can be found in the logs/ directory.

  • archiva.log - contains all the start-up information and output logs for Archiva
  • archiva-audit.log - contains information regarding the operations performed against the repositories and configurations being modified. A good example is when an artifact is deployed to an Archiva repository. The operation will be logged in this file, with the date and timestamp of when the operation occurred, the userId of who performed the deployment, and the artifact that was deployed.
  • archiva-security-audit.log - contains information regarding Archiva's security. For example, a successful login of a user or a user account is created.
+
+
+
+
+
+ + + Added: archiva/site-content/docs/1.3.5/adminguide/network-proxies.html URL: http://svn.apache.org/viewvc/archiva/site-content/docs/1.3.5/adminguide/network-proxies.html?rev=1387591&view=auto ============================================================================== --- archiva/site-content/docs/1.3.5/adminguide/network-proxies.html (added) +++ archiva/site-content/docs/1.3.5/adminguide/network-proxies.html Wed Sep 19 13:35:36 2012 @@ -0,0 +1,287 @@ + + + + + + + + + + + + + + Archiva Documentation - Understanding Network Proxy Configuration of Apache Archiva + + + + + + + + + + + +
+ +
+
+
+

Understanding Network Proxy Configuration of Apache Archiva

Archiva uses the terminology "proxy" for two different concepts:

  • The remote repository proxying cache, as configured through 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.

Network Proxy Settings and the JVM

As Archiva still targets Java 5 and uses the built-in networking libraries, it must configure these settings using system properties. This can be problematic in two scenarios:

  • if you use multiple different network proxies on different proxy connectors, they may clash
  • if you deploy other applications into the same container as Archiva, they will likely pick up the settings

Please refer to MRM-1248 for workarounds and to track the issue.

+
+
+
+
+
+ + + Added: archiva/site-content/docs/1.3.5/adminguide/proxy-connectors.html URL: http://svn.apache.org/viewvc/archiva/site-content/docs/1.3.5/adminguide/proxy-connectors.html?rev=1387591&view=auto ============================================================================== --- archiva/site-content/docs/1.3.5/adminguide/proxy-connectors.html (added) +++ archiva/site-content/docs/1.3.5/adminguide/proxy-connectors.html Wed Sep 19 13:35:36 2012 @@ -0,0 +1,287 @@ + + + + + + + + + + + + + + Archiva Documentation - Understanding Proxy Connector Configuration of Apache Archiva + + + + + + + + + + + +
+ +
+
+
+

Understanding Proxy Connector Configuration of Apache Archiva

Archiva uses the terminology "proxy" for two different concepts:

  • The remote repository proxying cache, as configured through proxy connectors between repositories
  • 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 Arch iva 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 a rtifact 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).
  • Return error when - if a remo te proxy causes an error, this option determines whether an existing artifact should be returned (error when artifact not already present), or the error passed on regardless (always).
  • On remote error - if a remote error is encountered, stop causes the error to be returned immediately, queue error will return all errors after checking for other successful remote repositories first, and ignore will disregard ay errors.

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. Convers ely, 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/**
+
+
+
+
+
+ + + Added: archiva/site-content/docs/1.3.5/adminguide/reports.html URL: http://svn.apache.org/viewvc/archiva/site-content/docs/1.3.5/adminguide/reports.html?rev=1387591&view=auto ============================================================================== --- archiva/site-content/docs/1.3.5/adminguide/reports.html (added) +++ archiva/site-content/docs/1.3.5/adminguide/reports.html Wed Sep 19 13:35:36 2012 @@ -0,0 +1,266 @@ + + + + + + + + + + + + + + Archiva Documentation - Making the most of Reporting in Apache Archiva + + + + + + + + + + + + +
+ +
+
+
+

Making the most of Reporting in Apache Archiva

Archiva has two types of reports: Repository Statistics and Repository Health. Repository Statistics was just implemented in 1.2.

Repository Statistics

Repository statistics contains the detailed statistics such as number of artifacts, number of groups and projects, etc. of an Archiva managed repository.

Configuring the Report

The following fields are configurable for Repository Statistics:

1. Repositories to be Compared - the repositories whose latest statistics would be compared. If only one repository is selected, the different statistics based on the executed repository scanning and the specified Start Date and End Date will be shown. Otherwise, the latest statistics of the selected repositories on the specified dates will be displayed.

2. Row Count - the number of rows to be displayed on each page.

3. Start Date - the start date range of the statistics to be displayed.

4. End Date - the end date range of the statistics to be displayed.

Contents of the Report

The Repository Statistics Show Report button will display a table containing the statistics of the repository/repositories. See below for a sample Repository Statistics report comparing two repositories:

Repository Statistics

Repository Statistics can be exported to a CSV file. To do this, just click the link on the upper left hand corner above the report.

Repository Health

The Repository Health report is a detailed listing of the problematic artifacts in the different repositories. Problematic artifacts are those artifacts that were detected by Archiva to have defects (ex. the versions in the pom and in the artifact itself do not match).

Configuring the Report

There are 3 fields which can be configured when viewing the report. These are: the number of rows per page, the group id and the repository.

1. Setting the row count. This field is for configuring the number of rows or artifacts to be displayed per page of the report. By default, this is set to 100. The minimum number of rows per page is 10 and the maximum number of rows is 1000.

2. Setting the group id. The group id pertains to the group id of the artifact (ex. org.apache.maven.plugins). This field has a blank default value -- meaning, show defective artifacts which has any group id.

3. Setting the repository. You can view the defective artifacts found on specific repositories by setting the repository field. By default, it is set to All Repositories. Please note that the repository field options list only contains the repositories which have one or more defective artifacts in it. So not all the repositories you have c onfigured in the Repositories section will show up in this list, unless of course they all contain defective artifacts.

Contents of the Report

The Repository Health Show Report button will display a detailed list of problematic artifacts filtered according to the configuration you've set. Below is a sample Repository Health report:

Repository Health Report

You can see in the sample report that there are links to the groupId and artifactId directories of each artifact. Clicking on any of these links will bring you to the appropriate navigation page in the Repository Browse. Going back to the report, shown below the links is the specific problem or defect of the artifact. These are usually detected during repository or database scanning. The page number is also displayed on the lower left-hand part of the report.

+
+
+
+
+
+ + + Added: archiva/site-content/docs/1.3.5/adminguide/repositories.html URL: http://svn.apache.org/viewvc/archiva/site-content/docs/1.3.5/adminguide/repositories.html?rev=1387591&view=auto ============================================================================== --- archiva/site-content/docs/1.3.5/adminguide/repositories.html (added) +++ archiva/site-content/docs/1.3.5/adminguide/repositories.html Wed Sep 19 13:35:36 2012 @@ -0,0 +1,295 @@ + + + + + + + + + + + + + + Archiva Documentation - Understanding Repository Configuration of Apache Archiva + + + + + + + + + + + + +
+ +
+
+
+

Understanding Repository Configuration of Apache Archiva

Archiva has two types of repository configuration: managed repository and remote repository.

Managed Repository

A managed repository is a repository which resides locally to the server where Archiva is running. It could serve as a proxy repository, an internal deployment repository or a local mirror repository.

Managed repository fields:

  • identifier - the id of the repository. This must be unique.
  • name - the name of the repository.
  • directory - the location of the repository. If the path specified does not exist, Archiva will create the missing directories.
  • index directory - the location of the index files generated by Archiva. If no location is specified, then the index directory (named .indexer) will be created at the root of the repository directory. Another direct ory named .index is also created at the root of the repository directory. This is not configurable though as it contains the packaged/bundled index which is consumed by different consumers of the index such as M2Eclipse.
  • type - the repository layout (maven 2 or maven 1)
  • cron - the cron schedule when repository scanning will be executed.
  • repository purge by days older - the first option for repository purge. Archiva will check how old the artifact is and if it is older than the set number of days in this field, then the artifact will be deleted respecting the retention count (see #7) of course. In order to disable the purge by number of days old and set Archiva to purge by retention count, just set the repository purge field to 0. The maximum number of days which can be set here is 1000. See the Repository Purge section below for more details.
  • repository purge by retention count - the second option for repository purge. When running the repository purge, Archiva will retain only the number of artifacts set for this field for a specific snapshot version. See the Repository Purge section below for more details.
  • releases included - specifies whether there are released artifacts in the repository.
  • block re-deployment of released artifacts - specifies whether released artifacts that are already existing in the repository can be overwritten. Note that this only take effects for non-snapshot deployments.
  • snapshots included - specifies whether there are snapshot artifacts in the repository.
  • scannable - specifies whether the repository can be scanned, meaning it is a local repository which can be indexed, browsed, purged, etc.
  • delete released snapshots - specifies whether to remove those snapshot artifacts which already has release versions of it in the repository during repository purge.

Each repository has its own Webdav url. This allows the user to browse and access the repository via webdav. The url has the following format: 

http://[URL TO ARCHIVA]/repository/[REPOSITORY ID] (e.g. http://localhost:8080/archiva/repository/releases).

A pom snippet is also available for each repository. The <distributionManagement> section can be copied and pasted into a project's pom to specify that the project will be deployed in that managed repository. The <repositories> section on the other hand, can be copied and pasted to a project's pom.xml or to Maven's settings.xml to tell Maven to get artifacts from the managed repository when building the project.

Remote Repository

A remote repository is a repository which resides remotely. These repositories are usually the proxied repositories. See Proxy Connecto rs on how to proxy a repository.

Remote repository fields:

  • identifier - the id of the remote repository.
  • name - the name of the remote repository.
  • url - the url of the remote repository. It is also possible to use a 'file://' url to proxy a local repository. Be careful that if this local repository is a managed repository of archiva which has some proxies connectors, those ones won't be triggered.
  • username - the username (if authentication is needed) to be used to access the repository.
  • password - the password (if authentication is needed) to be used to access the repository.
  • type - the layout (maven 2 or maven 1) of the remote repository.

Scanning a Repository

Repository scan can be executed on schedule or it can be explicitly executed by clicking the 'Scan Repository Now' button in the repositories page. By default, Archiva on ly processes new artifacts in the repository with respect to the last run of the repository scanner. Meaning that if the artifact's last modified date is newer than the last repository scan, then the artifact will be processed. Otherwise, it will be skipped. You can override this behavior and force Archiva to process all artifacts regardless of its age by ticking the 'Process All Artifacts' checkbox in the repositories page and clicking the 'Scan Repository Now' button.

Repositories

For every artifact found by the repository scanner, processing is done on this artifact by different consumers. Examples of the processing done are: indexing, repository purge and database update. Details about consumers are available in the Consumers page.

Repository Purge

Repository purge is the process of cleaning up the repository of old snapshots. When deploying a snapsh ot to a repository, Maven deploys the project/artifact with a timestamped version. Doing daily/nightly builds of the project then tends to bloat the repository. What if the artifact is large? Then disk space will definitely be a problem. That's where Archiva's repository purge feature comes in. Given a criteria to use -- by the number of days old and by retention count, it would clean up the repository by removing old snapshots.

Please take note that the by number of days old criteria is activated by default (set to 100 days). In order to de-activate it and use the by retention count criteria, you must set the Repository Purge By Days Older field to 0. Another thing to note here is that if the by number of days old criteria is activated, the retention count would still be respected (See the Repository Purge By Days Older section below for more details) but not the other way around.

Let's take a look at different behaviours for repository purge using the following scenario:

Artifacts in the repository:
+
+../artifact-x/2.0-SNAPSHOT/artifact-x-20061118.060401-2.jar
+../artifact-x/2.0-SNAPSHOT/artifact-x-20061118.060401-2.pom
+../artifact-x/2.0-SNAPSHOT/artifact-x-20070113.034619-3.jar
+../artifact-x/2.0-SNAPSHOT/artifact-x-20070113.034619-3.pom
+../artifact-x/2.0-SNAPSHOT/artifact-x-20070203.028902-4.jar
+../artifact-x/2.0-SNAPSHOT/artifact-x-20070203.028902-4.pom
  1. Repository Purge By Number of Days Older

    Using this criteria for the purge, Archiva will check how old an artifact is and if it is older than the set value in the repository purge by days older field, then the artifact will be deleted respecting the retention count of course.

    If repository purge by days older is set to 100 days (with repository purge by retention count field set to 1), and the current date is let's say 03-01-2007, given the scenario above.. the following artifacts will be retained: artifact-x-20070113.034619-3.jar, artifact-x-20070113.034619-3.pom, artifact-x-20070203.028902-4.jar and artifact-x-20070203.028902-4.pom. It is clear in the version timestamps that these 4 artifacts are not more than 100 days old from the current date (which is 03-01-2007 in our example) so they are all retained. In this case the retention count doesn't have any effect since the priori ty is the age of the artifact.

    Now, if the repository purge by days older is set to 30 days (with repository purge by retention count field still set to 1) and the current date is still 03-01-2007, then given the same scenario above.. only the following artifacts will be retained: artifact-x-20070203.028902-4.jar and artifact-x-20070203.028902-4.pom. In this case, we can see that the retained artifacts are still not older by the number of days set in the repository purge by days older field and the retention count is still met.

    Now, let's set the repository purge by days older to 10 days (with repository purge by retention count field still set to 1) and the current date is still 03-01-2007, then still given the same repository contents above.. the following artifacts will still be retained: artifact-x-20070203.028902-4.jar and artifact-x-20070203.028902-4.pom. It is clear from the version timestamps that the artifacts ARE MORE THAN the repository purge by days older value, which is 10 days. Why is it still retained? Recall the value of the repository purge by retention count -- 1 :) This ensures that there is ALWAYS 1 artifact timestamped version retained for every unique version snapshot directory of an artifact.

  2. Repository Purge By Retention Count

    If the repository purge by retention count field is set to 2, then only the artifacts artifact-x-20070113.034619-3.jar, artifact-x-20070113.034619-3.pom, artifact-x-20070203.028902-4.jar and artifact-x-20070203.028902-4.pom will be retained in the repository. The oldest snapshots will be deleted maintaining only a number of snapshots equivalent to the set retention count (regardless of how old or new the artifact is).

Deleting Released Snapshots

You can also configure Archiva to clean up snapshot artifacts that have already been released. This can be done by ticking the Delete Released Snapshots checkbox in the Repository Conf iguration form.

Once this feature is enabled, if Archiva encounters a snapshot artifact during repository scanning, it would check all the repositories configured for a released version of that snapshot. If it finds one, then it would delete the entire snapshot version directory.

It should be noted that this feature is entirely separate from the repository purge by number of days older and by retention count.

Scanning a Database

Another scanning process also occurs in Archiva, the database scanning. Same as with repository scanning, it can also be executed on schedule or explicitly. This can be configured in the 'Database' page, via the 'Database - Unprocessed Artifacts Scanning' section.

It is essential that the database scan occur after the repo scan as this is where the pom information of the artifacts in the database will be processed by the consumers and in turn, added to the database (as ArchivaPro jectModel objects). For more details about the different database consumers, please see the Consumers page.

+
+
+
+
+
+ + +