Nexus Scheduled Tasks

Nexus provides a rich and extensible set of tasks that can be scheduled. Internally, all long-running, or asynchronous task are modeled as scheduled tasks, which provides a consistent development model and exposes all the functionality for the user to schedule if they choose. What this means is that some tasks are not applicable to all users. I'll go through them all below.

External Changes

Many of the tasks below apply to the same scenario so I'll cover it here.
If you are deploying or otherwise regularly changing the contents of the filesystem by some mechanism outside of Nexus, then certain internal states of Nexus may get out of sync (cache, index, etc) with the true contents of the disk. A common example is an organization migrating from using no repository manager, continuing to use webdav or scp to deploy while they migrate.

The Tasks

Expire Repository Caches

What it does

Repositories have several caches to improve performance - this task expires the caches causing Nexus to recheck the remote repository (proxy) or file system (hosted).

Configuration

• Repository / Group - This is the Repository or Group to expire, an option is also provided for all repositories.
• Repository Path - you may expire a subset of the repository by entering the path such as /org/apache/maven/

When to use it

Typically this is fired off from the right-click menu of a repository in response to temporary config changes, etc. This could be scheduled in the External Changes scenario covered above. A better approach would be to adjust the cache timeouts to a smaller number.

Remove Snapshots From Repository

What it does

Maven best practices suggest you deploy snapshots on a frequent basis, usually from a CI system. If the snapshots aren't cleaned up, this can lead to lots of disk usage. The snapshot remover can clean out old snapshots based on their age keeping minimum number, or removing all copies when a release of the same version is detected. In all cases, maven-metadata.xml is properly updated.

Configuration

• Repository / Group - This defines the Repository or Group from which to clear snapshots, an option is also provided for all repositories.
• Minimum Snapshot Count - This sets the minimum number of copies to maintain. Regardless of age, the task will always leave at least this number of snapshots behind. -1 indicates an infinite number will be preserved.
• Snapshot Retention (days) - This sets the maximum age of the snapshots to keep. Anything older than this will be removed, subject to the Minimum count.
• Remove if released - This tells the task to ignore the above settings if an artifact with the same group/artifact/version is detected in a release repository.

When to use

This task should be scheduled to run daily at a convenient time. I generally keep 3 copies of snapshots (in the off chance I want to go back one or two to test some changes) with a minimum age of 1-2 days. I also like to have the Remove if Released option set. This causes our builds to fail in CI if we forget to upgrade to a released dependency.

Evict Unused Proxied Items From Repository Caches

What it does

This task purges items from proxy repositories that haven't been requested by a user in a set period of time.

Configuration

• Repository / Group - This defines the Repository or Group from which to evict items, an option is also provided for all repositories.
• Evict items older than (days) - anything that hasn't been downloaded from the system within this number of days will be removed.

When to use

This task is handy to recover disk space for versions of artifacts that are no longer used regularly. If they are needed again, they will be re-requested from the proxy. If you trust the availability of the remote proxy, then set this for some period like 90 days. If however you want to be sure Nexus has a copy of every artifact you've ever needed, then don't run this task. I generally set this for 90 days and let it run on the weekends. This is particularly handy if you have a personal Nexus instance where you might have a large churn in the artifacts you use and are more sensitive to disk usage.

Empty Trash

What it does

All delete operations in Nexus don't actually delete files, they are simply moved to /sonatype-work/nexus/trash. This applies to scheduled tasks and manual deletions. This is done to give you a recovery path if you accidentally delete something incorrectly. Restoring files is currently a manual process of moving the files back, but trust me if you need it, you will hardly mind. (I speak from experience)

Configuration

• Purge items older than (days) - Will remove any items that have been in the trash for the number of days entered.

When to use it

It's not required as you can manually purge the trash from the repository view when you need to recover disk space. Keep in mind that purged snapshots will end up in the trash so depending on your development cycle, it could grow quickly. I like to set this to run weekly on Sunday night...the logic being that I want the maximum time to discover and restore any artifacts before they get purged.

Rebuild Maven Metadata Files

What it does

This task is similar to expire caches since it normally is invoked from the repository view to repair one-time changes. This task will rebuild the maven-metadata.xml files with the correct information and will also validate the checksums (.mh5/.sha1) for all files.

Configuration

• Repository / Group - This is the Repository or Group for which to rebuild maven metadata, an option is also provided for all repositories.

When to use it

This would only need to be scheduled if you make External Changes on a regular basis as described in the first section.

Download Indexes

What it does

This will check for new versions of indexes that may be published on remote repositories. Not all repositories publish indexes, but if they do, you can enable the download in the repository configuration for your proxy repository.

Configuration

• Repository / Group - This is the Repository or Group for which to download indexes, an option is also provided for all repositories.

When to use it

If you want to keep the indexes for searching and browsing remote repositories, then set this schedule. It's best to know how often the remote is updated and set your schedule accordingly. The Maven Central repository index is currently updated weekly on Saturday mornings.

Publish Indexes

What it does

This task bundles up the internal Nexus indexes that are maintained in realtime along with downloaded remote indexes and exposes them for download by other systems like downstream Nexus or M2eclipse clients. Publishing has no effect on the searching inside of Nexus, these indexes are always maintained in realtime. Producing the format for efficient download is nontrivial and the results are zipped so it's not practical to do this in real time, hence the ability to schedule it.

Configuration

• Repository / Group - This is the Repository or Group for which to publish indexes, an option is also provided for all repositories.

When to use it

If you have downstream Nexus instances or users with M2eclipse, then you will want to schedule the publishing. How often and when depends on your needs. M2eclipse currently only looks for new indexes on startup so publishing every 5 minutes is likely overkill.

Reindex

What it does

This task walks over the entire repository and rebuilds the internal indexes from scratch. It also checks for remote indexes and will publish the results when done. (i.e. it supercedes the Download Index and Publish Index tasks.)

Configuration

• Repository / Group - This is the Repository or Group to reindex, an option is also provided for all repositories.

When to use it

You should rarely, if ever, have to reindex a repository, because Nexus maintains the internal indexes in realtime. If you are making External Changes as described above, then you would want to schedule a re-indexing, otherwise you're better off using the Download Index and Publish Index tasks.

Purge Nexus Timeline

What it does

The timeline is the internal audit of operations. This is currently only used to produce the RSS feeds.

Configuration

• Purge items older than (days) - Will remove any items that are older than the number of days entered.

When to use it

The timeline can be purged to conserve disk space. In future versions, the timeline will form an audit path and this task will probably be disabled. For now only use it if you find the timelines are taking up lots of disk, otherwise it should be safe to ignore.

Synchronize Shadow Repository

What it does

Shadow repositories are another name for virtual repositories. Virtual repositories allow you to convert data from one content type to another, for example Maven1 to Maven2, or Maven2 to OBR.

Shadow repositories manage themselves by laying down "symlinks" that point to the source repository. They are managed on the fly, but if you are making External Changes, then this is used to update the shadow repository to reflect actual change.

Shadow will still work and will deliver the newly copied files to maven (more precisely, will fulfill maven download requests) if they are present, but this task merely creates the folder structure and the symlinks and makes the /content tree browsable by syncing the master repo content with symlinks in shadow repository.

Configuration

• Shadow Repository - This is the Repository that will be synchronized.

When to use it

This is only needed if you have virtual repositories and you make External Changes to the source repository.

Backup all Nexus Configuration Files - Pro

What it does

This Nexus Professional plugin creates archives of the Nexus configuration data.

Configuration

• Backups to Keep - The number of backup copies to keep, as this limit is reached, the oldest backups will be removed.

When to use it

We recommend running this at least daily to keep backups of the config.

Mirror Eclipse Update Site - Pro

What it does

This Nexus Professional P2 plugin allows you to mirror Eclipse Update Sites. Using this task, your Nexus will mirror the data from the remote repository.

Configuration

• Repository/Group - The Eclipse Update Site Proxy Repository for which you want to refresh the mirror.
• Force Mirror - If selected, this option will force a mirror operation even if the site.xml hasn't changed.

When to use it

The P2 plugin should handle this operation when necessary, however, should you get in a state where the mirrored content/metadata gets out of sync with the remote repository, you can run this task to get back in sync.