The Repository - Import external files task will take content from a directory on the server and import it into the desired repository in Nexus Repository Manager. This will allow you to get external content into a repository from any source, even Nexus Repository Manager 2.
Only available in Nexus Repository Pro. Interested in a free trial? Start here.
Planning and Requirements
Before using this task, you should consider a few things:
- Space Requirements - Copying all components will double the assets and space on disk; hard linking does not do this but will take additional space to store all of the metadata.
- Location Requirements - The source directory must be writable by the user running Nexus Repository Manager 3. The import history is stored in the source directory to enable incremental imports.
- Timing - This task can take some time to run, and multiple imports are not done in parallel. Each task will need to complete before the next one will run.
- Frequency - You can configure this task to run manually or on a schedule depending on your needs.
- Performance - We do not recommend that you import directly to object storage such as S3 as doing so can result in poor performance.
- Import is limited to just artifacts and their metadata; it does not include any other server configurations.
- This task will also not import hidden files and directories (having names that start with a period).
- Hard Link Requirements
- To use hard links, the target repository blob store must be on the same file system as the source.
- Detaching the source directory where the blobs are located from the current instance after using this option to import the artifacts will result in the blobs becoming inaccessible.
- Hard linking is not supported for object storage blob stores.
Create a new Repository - Import external files task and you will be presented with the configuration options listed below:
Important import-specific fields are as follows:
Target repository - The repository into which to import content. This list will only be popluated with Hosted repositories of the supported Formats (see format list below).
Source directory - The directory from which to import content.
Files in this directory should be in a directory structure that supports the desired format (see format list below).
NEW IN 3.31 Enable Hard Links - For some formats (see
Hard Link Support in table below), enabling this option will create hard links for the blobs in the source directory to be used in the target directory. A physical copy of the blobs will not be created in the target directory. This can save time if the source directory will continue to be accessible by the current instance. Ensure you have read the hard link requirements under Planning and Requirements.
Running the Task
When the task runs, it generates a
.nexus directory inside of the source directory. This
.nexus directory contains metadata that we use for future imports so that Nexus Repository will not import content multiple times if the task is run more than once. This will allow you to keep placing content into this directory while only importing newer content if you run the task again.
As Nexus Repository processes the import, it will log every single file it imports to the task log; a new task log is created each time a task runs. If an error occurs with any particular file, Nexus Repository will simply log that fact, then continue importing the rest of the content.
You can import content into repositories of any format listed below. Some formats require that content be structured in a certain manner:
|Format||Since||Directory Layout||Hard Link Support Since|
|Raw||3.23.0||No specific layout required, content will simply be imported exactly as laid out in the source directory||3.31.0|
Files need to be laid out in the usual maven GAV structure, /(groupId)/(artifactId)/(version)/(artifactId-version.extension)
maven-metadata files at each level (G, A or V) will also be imported.
|npm||3.25.0||No specific layout required, will simply import all tgz packages contained in the source directory||3.34.0|
|NuGet||3.25.0||No specific layout required, will simply import all nuget packages contained in the source directory||3.35.0|
(Note the : in the following path, this is simply an ascii encoded colon ':' as windows file systems do not support this character in the filename)
|PyPI||3.26.0||No specific layout required, will simply import all archives contained in the source directory (along with any .asc signature files alongside them)||3.35.0|
|RubyGems||3.26.0||No specific layout required, will simply import all gem files contained in the source directory||3.35.0|
No specific layout required, will simply import all of the rpm (or drpm) files, as well as any comps.xml files in the source directory
You can use this task as part of your import process to import from Nexus Repository 2 to Nexus Repository 3 or even to migrate to Nexus Repository from other repository managers.
Import from Nexus Repository 2 to Nexus Repository 3
If importing from Nexus Repository 2 to 3, the Nexus Repository 3 server must have file access to the Nexus Repository object store directory in order to import the repository.
One way to use import when migrating from Nexus Repository 2 to 3 is to first set up a group repository with ap roxy to the source repository. This way, artifacts will be available immediately while you do the import. Once the import is done, you can remove the proxy to test that everything is available.
When importing from Nexus Repository 2 repositories, the task will also pull the date-/time-related attributes so that you can maintain the data in the new repository. These include the created date, last updated date, and the last downloaded date.
Import from Other Repository Managers
To import from other repository managers, you must first export artifacts to temporary storage. Nexus Repository 3 can then import this repository if it has access to this attached storage. You will not be able to directly connect to another repository manager and import from there.