Publish pipeline.did to Maven Central

[jwrosewell]

The problem

The 51Did library for Java is complete and builds with the rest of the repository, but it has never been published, so nobody outside can use it.

pipeline.did is listed in the root pom.xml modules, alongside pipeline.core and the others, and it holds FodId, DidClient, FodIdParseResult, IdType, SigningKey and their tests. A search of Maven Central for g:"com.51degrees" AND a:"pipeline.did" returns numFound: 0. Its siblings are there, for example pipeline.core and pipeline.engines at 4.5.0-alpha.1, so the group is published and this one artifact is missing from it.

The most likely reason is simply that no release has been cut since the module was added, rather than anything being wrong with the module.

Why it matters

A customer using Java cannot read a 51Did without copying source out of this repository. Every other language ships a package, being FiftyOne.Did 4.5.88 on nuget, fiftyone.pipeline.did 4.5.35 on npm, fiftyone-pipeline-did 4.5.15 on PyPI and fodid on crates.io.

What is needed

A release that includes pipeline.did, published to Maven Central under com.51degrees. If a first publish of a new artifact id needs anything accepted at the registry end, that is part of this.

Worth doing in the same release, the match key rename merged in 120, so the first published version carries the finished vocabulary rather than shipping the old constant names and deprecating them one version later. MATCH_KEY_OFFSET and MATCH_KEY_LENGTH are the real constants, with HASH_OFFSET and HASH_LENGTH kept as deprecated aliases.

How to tell it is done

https://search.maven.org/solrsearch/select?q=g:%22com.51degrees%22+AND+a:%22pipeline.did%22&wt=json returns a version rather than numFound: 0, and a plain Maven project can depend on it and parse a 51Did.

Produced with AI assistance under James Rosewell's direction and needs human review.

[jwrosewell]

Raising the priority, with the launch state as of 3 September 2026

51Did is about to be launched and this is now a blocker for consumers in
this language, so recording where every language actually stands.

Language	Package	State
.NET	FiftyOne.Did	on NuGet at 4.5.89, but a publish problem means the latest changes are not out, 51Degrees/pipeline-dotnet#387
Node	fiftyone.pipeline.did	on npm, 4.5.37, current
Python	fiftyone-pipeline-did	on PyPI, 4.5.17, current
Rust	fodid	on crates.io at 4.5.3, reader only. The client is unpublished, 51Degrees/rust#34
Java	pipeline.did	not on Maven Central, #121
PHP	fiftyone.pipeline.did	not on Packagist, 51Degrees/pipeline-php-did#9

So three languages have a consumable package and three do not.

What has changed since this issue was raised

The client vocabulary gained two values on 3 September, misconfigured and
invaliddate, along with a third per-factor value. That work is merged in
every language including this one, so the code here is current and only the
publishing step is missing.

That matters for how this is prioritised. There is no development left to do
before publishing, and the gap is entirely in release plumbing and whatever
account or credential setup a first publication needs.

Why it bites a consumer

Someone adopting 51Did in this language has to depend on a source revision
rather than a package. That is a poor first experience of a feature we are
asking people to adopt, and it makes the ordinary things hard, being version
pinning, transitive dependencies and reproducible builds.

[jwrosewell]

Correction to the table in my previous comment. The .NET row was wrong. FiftyOne.Did published cleanly today and is on NuGet at 4.5.90 carrying the new outcome values, so .NET is current. I read the registry before it had indexed the push and drew the wrong conclusion. 51Degrees/pipeline-dotnet#387 is closed as not a defect.

The rest of the table stands. Node is on npm at 4.5.37 and Python on PyPI at 4.5.17, both current. Rust has a reader on crates.io and an unpublished client (51Degrees/rust#34). This language still has no package at all, which is what this issue is for.