# njord
**Repository Path**: mirrors_olamy/njord
## Basic Information
- **Project Name**: njord
- **Description**: Publish where you want!
- **Primary Language**: Unknown
- **License**: EPL-2.0
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No
## Statistics
- **Stars**: 0
- **Forks**: 0
- **Created**: 2025-05-23
- **Last Updated**: 2026-05-17
## Categories & Tags
**Categories**: Uncategorized
**Tags**: None
## README
# Njörðr
[](https://search.maven.org/artifact/eu.maveniverse.maven.njord/extension)
Documentation available: https://maveniverse.eu/docs/njord/
Requirements:
* Java 11+
* Maven 3.9+ (tested with 3.9.9 and 4.0.0-rc-3)
Note: this code is Proof of Concept, with a lot of To-Be-Done parts and intentionally simple as possible.
Goal: Provides non-intrusive Artifact publishing and local staging functionality.
Concept: Assume you have a Maven project and it works very well. Suddenly, the _publishing requirement_ change, and
changes wildly... and then you are in trouble. But, if you think about it, **where** and **how** you publish your
artifacts will inevitably change from time to time, maybe even involving some proprietary solutions and/or protocols.
If you are within some organization, you are probably using some Maven Repository Manager, and you use Maven as "usual":
deploying artifacts into designated hosted repository. But, if you are in open (as in "open source"), or you want to
publish your artifacts globally (make them globally reachable), then you are at the mercy of organizations providing
these services, usually requiring some "special" (given there is no standard in this area) steps to publish artifacts.
Moreover, these steps most often comes with some required changes to your project, like adding profiles, and who knows
what, plus you are forced to use their (possibly closed source) plugins in your own build to make it work.
This tool aim is to help you manage your build artifacts by publishing them to these repositories, but without the
hassle of requiring to mutilate your own build (POMs).
With Njord you can have benefits:
* have only as many server entries in your `settings.xml` as many publishing services you use, as opposed to current
status, where each project uses "own" server ID for distribution management, that again causes that users working
on several projects (ie releasing them) must have copies of auth for each server of each project. Currently, there
are only 4 services publishing to Maven Central, so all you need is at most 4 server entries with auth in your `settings.xml`.
* support publishing that is not "natively" supported by Maven, without hoops and looks and any change needed in
your project. Moreover, publishing comes with local staging as well in non-intrusive way.
## Setting it up
With Maven 3 install Njord project-wide `.mvn/extensions.xml`, or with Maven 4+ install it user-wide `~/.m2/extensions.xml` like this:
```xml
eu.maveniverse.maven.njord
extension
${currentVersion}
```
It is recommended (but not mandatory) to add this stanza to your `settings.xml` as well if you don't have it already
(to not type whole G of plugin):
```xml
eu.maveniverse.maven.plugins
```
Next, set up authentication for service or even more services you plan to use. Different publishers require different
server, for example `sonatype-cp` publisher needs following stanza in your `settings.xml`:
```xml
sonatype-cp
USER_TOKEN_PT1
USER_TOKEN_PT2
```
Supported publishers and corresponding `server.id`s are:
| Publisher (publisher ID) | server.id | What is needed |
|----------------------------------------------------------------|-------------------------|----------------------------------------------------------------------------------------------------------------------------------------------|
| Sonatype Central Portal (`sonatype-cp`) | `sonatype-cp` | Obtain tokens for publishing by following [this documentation](https://central.sonatype.org/publish/generate-portal-token/). |
| Sonatype OSS on https://oss.sonatype.org/ (`sonatype-oss`) | `sonatype-oss` | Obtain tokens for publishing by following [this documentation](https://central.sonatype.org/publish/generate-token/) and using OSS instance. |
| Sonatype S01 on https://s01.oss.sonatype.org/ (`sonatype-s01`) | `sonatype-s01` | As above but using s01 instance. |
| Apache RAO on https://repository.apache.org/ (`apache-rao`) | `apache.releases.https` | As above but using RAO instance. |
Make sure your `settings.xml` contains token associated with proper `server.id` corresponding to you publishing service you want to use.
The publisher id is determined (or inferred) from the plugin parameter `publisher` (of goal `publish`) or from user
or project properties, or from `server` indirection (in `settings.xml` you can add `configuration` element with Njord
configurations that will be obeyed to "redirect" to other server, useful when you does not want to or cannot change
the distributionManagement server IDs.
If the project POM cannot be changed (`project/distributionManagement/repository`) or you don't want to change it,
you need one more thing: set up server indirection. Assuming your POM contains this:
```xml
project-releases
Some Release Repository
https://some.service/deploy
project-snapshots
Some Snapshots Repository
https://some.service/snapshots
```
Then you need to set up indirection for servers `project-releases` and `project-snapshots` in your `settings.xml`, like this:
```xml
project-releases
sonatype-cp
njord:template:release-sca
project-snapshots
sonatype-cp
njord:template:snapshot-sca
```
This provides Njord following information:
* indirection of publishing `project-release` -> `sonatype-cp` and `project-snapshots` -> `sonatype-cp` (for snapshot support Central Portal must have snapshot support enabled)
* templates for local staging of releases and snapshots
* any indirection may be omitted, then Maven will use distribution repositories from POM. Same for URL, if omitted, URL from POM will be used.
That's all! No project change needed at all.
## Using it
Next, let's see an example of Apache Maven project (I used `maven-gpg-plugin`):
1. For example’s sake, I took last release of plugin (hence am simulating release deploy): `git checkout maven-gpg-plugin-3.2.7`
2. Deploy it (locally stage): `mvn -P apache-release deploy -DaltDeploymentRepository=id::njord:` (The `id` is really unused, is there just to fulfil deploy plugin syntax requirement. The URL `njord:` will use "default" store template that is RELEASE. You can target other templates by using, and is equivalent of this `njord:release`. You can stage locally snapshots as well with URL `njord:snapshot`. Finally, you can target existing store with `njord:store:storename-xxx`).
3. Check staged store names: `mvn njord:list`
4. Optionally, check locally staged content: `mvn njord:list-content -Dstore=release-xxx` (use store name from above)
5. Optionally, validate locally staged content: `mvn njord:validate -Ddetails -Dstore=release-xxx` (use store name from above)
6. Publish it to ASF: `mvn njord:publish -Dstore=release-xxx -Dpublisher=apache-rao` (use store name from above), if operation successful, store is dropped.
7. From now on, the repository is staged on RAO, so you can close it, vote, and all the usual fluff as before.
8. To drop locally staged stores use: `mvn njord:drop -Dstore=release-xxx` (use store name from above)
Build requirements:
* Java 21
* Maven 3.9.9+
## High level design
TBD