Technical Solutions for Uploading Build Artifacts to Nexus Repository Without Maven

In continuous integration and deployment workflows, storing build artifacts in a central repository is crucial for traceability and dependency management. While Nexus repositories were originally designed for Maven ecosystems, non-Java projects can still achieve efficient file uploads through appropriate tools and methods. Based on actual technical Q&A data, this article explores the technical details and implementation principles of two mainstream solutions.

Application of Maven deploy:deploy-file Plugin

Even if the project itself doesn't use Maven for building, the deploy:deploy-file plugin provided by Maven command-line tools offers a highly compatible solution. This plugin can simulate Maven project deployment behavior without introducing complete POM file structures into the project. Its core advantage lies in automatically generating metadata files that comply with Maven repository specifications.

The basic command format is as follows:

mvn deploy:deploy-file \
    -Durl=$REPO_URL \
    -DrepositoryId=$REPO_ID \
    -DgroupId=org.myorg \
    -DartifactId=myproj \
    -Dversion=1.2.3  \
    -Dpackaging=zip \
    -Dfile=myproj.zip

Key parameter analysis:

• -Durl: Specifies the deployment endpoint URL of the Nexus repository
• -DrepositoryId: Corresponds to the repository identifier configured in Maven settings.xml
• -DgroupId, -DartifactId, -Dversion: Form the coordinate triplet of the artifact, following Maven naming conventions
• -Dpackaging: Defines file packaging type, such as zip, tar.gz, etc.
• -Dfile: Specifies the path to the local build artifact

When executing this command, the plugin automatically generates a minimal POM file in the background, containing basic project coordinates and dependency declarations (empty by default). This process is transparent to users and requires no manual XML configuration. For example, for a myproj.zip file with version 1.2.3, the generated POM will include elements like <groupId>org.myorg</groupId>.

This method is particularly suitable for systems with Maven already installed or as a standardized step in CI/CD pipelines. Sonatype's official documentation also lists it as a recommended solution due to its proven stability and backward compatibility.

Direct Upload via curl-based REST API

For scenarios wishing to completely avoid Maven dependencies, Nexus provides HTTP-based REST interfaces. Using the curl tool with multipart/form-data format, files can be directly uploaded to the repository. This approach is more lightweight and suitable for scripted deployments.

A typical upload command example:

curl -v \
    -F "r=releases" \
    -F "g=com.acme.widgets" \
    -F "a=widget" \
    -F "v=0.1-1" \
    -F "p=tar.gz" \
    -F "file=@./widget-0.1-1.tar.gz" \
    -u myuser:mypassword \
    http://localhost:8081/nexus/service/local/artifact/maven/content

Parameter explanation:

• -F "r=releases": Specifies target repository type (e.g., releases or snapshots)
• -F "g=com.acme.widgets": Corresponds to Maven groupId
• -F "a=widget": Corresponds to Maven artifactId
• -F "v=0.1-1": Version number, supporting custom formats
• -F "p=tar.gz": File extension/packaging type
• -F "file=@./widget-0.1-1.tar.gz": Specifies local file path via @ symbol
• -u myuser:mypassword: HTTP basic authentication credentials

It's important to note that REST API permission configuration may differ from the web interface. Users need to create dedicated roles in the Nexus admin interface and grant "Artifact Upload" privileges. Standard full-control roles might not include this specific permission, potentially causing 403 errors.

Additionally, this API's stability has some uncertainty. Sonatype officially stated in related JIRA issues that they plan to comprehensively refactor the REST API and its documentation generation in future versions. Therefore, when using this method in production environments, it's advisable to closely monitor version updates and compatibility notes.

Solution Comparison and Selection Recommendations

Both solutions have their advantages and disadvantages:

The Maven plugin approach offers high standardization, seamless integration with existing Maven ecosystems, and automatically generated POM files ensuring metadata consistency. The drawback is requiring Maven runtime installation in deployment environments, which may add dependencies for minimal setups.

The curl approach最大的优势是轻量级，仅依赖基本的命令行工具，适合容器化环境或资源受限的场景。但需要手动处理认证和权限，且API接口可能随版本变化而调整。

In practical applications, selection can be based on the following factors:

1. If the project might introduce Java modules in the future or need to share dependencies with Maven projects, prioritize the Maven plugin solution
2. If deployment environments strictly limit additional software installation or require highly customized upload logic, the curl approach is more suitable
3. For long-term maintained projects, prioritize solutions explicitly supported by official documentation (currently the Maven plugin)

Regardless of the chosen approach, it's recommended to add version verification steps in CI/CD pipelines to ensure uploaded artifact coordinates match actual build versions.同时，定期备份仓库配置和权限设置，以防API变更导致部署失败。