fix: derive User-Agent version from pom at build time#72
Conversation
The User-Agent header was hardcoded to "PluggyJava/0.16.2" in two places
(PluggyClient.authenticate, ApiKeyAuthInterceptor.requestWithAuth) and
had drifted from the actual pom version (1.9.0). The API logs were seeing
the wrong client version since 0.16.2.
Maven resource filtering now injects ${project.version} into
pluggy-version.properties at build time. A new ai.pluggy.utils.Version
class loads it once and composes the User-Agent as
"PluggyJava/<version> (Java <java.version>)", which also exposes the
consumer's JVM version for support visibility.
The TOOD (sic) comment flagging this exact debt has been removed.
Gabrielpanga
left a comment
There was a problem hiding this comment.
Review — ✅ Approve (one robustness nit)
Diff: +62 −3, 6 files. Clean fix for the stale hardcoded PluggyJava/0.16.2 User-Agent (vs the real pom 1.9.0). Both call sites — PluggyClient.authenticate and ApiKeyAuthInterceptor.requestWithAuth — now resolve through Version.USER_AGENT, which is exactly the two-places gotcha CLAUDE.md warned about. The new pluggy-version.properties + Maven resource filtering is the standard way to do this.
Strengths
VersionTestasserting the value isn't the literal${project.version}is a great guard — it fails loudly if resource filtering ever breaks.- Adding
(Java <java.version>)gives the API useful consumer-JVM visibility.
Nit (non-blocking): Version.loadSdkVersion() does props.load(in) where in = getResourceAsStream(...). If the resource is ever absent (e.g. a packaging regression), in is null and this throws an NPE inside a static initializer, which surfaces as a confusing ExceptionInInitializerError on first SDK use. Consider a null check with a clear message, or a fallback like "unknown".
Doc follow-up: CLAUDE.md still says the User-Agent string is "hardcoded in two places." Once this lands, that note is stale — worth updating in the same PR or a docs pass.
Summary
PluggyJava/0.16.2in bothPluggyClient.authenticateandApiKeyAuthInterceptor.requestWithAuth, stale against the actual pom version (1.9.0). API-side logs and analytics have been seeing the wrong SDK version.${project.version}into a newpluggy-version.propertiesat build time. Aai.pluggy.utils.Versionutility loads it once and exposesVersion.USER_AGENT.PluggyJava/<version> (Java <java.version>), giving the API visibility into both SDK and consumer JVM.// TOOD: add dynamic version(sic) note inApiKeyAuthInterceptorthat flagged this exact debt.Test plan
mvn -B test— 6/6 unit tests pass (4 existing + 2 new inVersionTest)mvn -B verify— 39 integration tests pass, 0 failurestarget/classes/pluggy-version.propertiescontainsversion=1.9.0after build (Maven filtering works as expected)VersionTest.sdkVersion_isResolvedFromPom_notTheLiteralPlaceholderguards against future filtering regressions