Skip to content

Link Groovy javadoc through a local package-list instead of fetching it - #146

Merged
vharseko merged 1 commit into
OpenIdentityPlatform:masterfrom
vharseko:groovy-javadoc-offline-link
Oct 2, 2026
Merged

vharseko merged 1 commit into
OpenIdentityPlatform:masterfrom
vharseko:groovy-javadoc-offline-link

Conversation

@vharseko

Copy link
Copy Markdown
Member

Problem

Scattered build-maven matrix cells keep failing in javadoc:jar (attach-javadocs) with

Error fetching URL: https://docs.groovy-lang.org/latest/html/api/ (java.io.FileNotFoundException: .../package-list)

The javadoc <link> to docs.groovy-lang.org/latest makes every build fetch the Groovy link list over the network. javadoc tries element-list first and falls back to package-list. The latest docs now return 404 for package-list, so a single transient miss on element-list fails the build. The same link has also been seen to hang javadoc until the 6-hour job limit. Recent examples are #130, #142 and #145, whose failed cells went green on a plain re-run.

Change

  • OpenICF-java-framework/pom.xml: remove the Groovy link. None of the framework modules expose Groovy types in their public API, so the link added nothing there.
  • OpenICF-java-framework/bundles-parent/pom.xml: replace both <links> blocks (pluginManagement and <reporting>) with an offlineLink. It points at a committed package-list under bundles-parent/src/javadoc/groovy-2.4.21/. The URL now targets the Groovy version the build actually uses (2.4.21) instead of latest, which currently holds the Groovy 5 docs. The connectors that expose Groovy types (groovy, ssh, kerberos) keep their cross-links.
  • If the local file cannot be found, for example in the src/it invoker projects, the plugin only logs an error and skips the link. It does not fail the build.
  • The file must be refreshed when the Groovy version changes. The comment next to the groovyJavadocPackageList property says so.

Verification

  • package with attach-javadocs (failOnWarnings=true) on JDK 26 for connector-framework-contract, connector-framework-internal, groovy-connector, ssh-connector and kerberos-connector, plus groovy-connector on JDK 11: BUILD SUCCESS.
  • The javadoc options file (-Ddebug=true) has no network -link left. Groovy is passed as -linkoffline https://docs.groovy-lang.org/2.4.21/html/api <local dir>.
  • The generated HTML links to docs.groovy-lang.org/2.4.21 in 30 files for groovy-connector (e.g. groovy/lang/Closure.html, CompilerConfiguration.html), 6 for ssh and 4 for kerberos. No links to latest remain.

The javadoc <link> to docs.groovy-lang.org/latest made every build
download the Groovy element-list/package-list at javadoc time. The
"latest" docs no longer serve package-list, so any transient miss on
element-list failed attach-javadocs, which kept turning random
build-maven matrix cells red.

- Drop the link from the framework modules: none of them expose Groovy
  types in their public API.
- In bundles-parent, replace it with an offlineLink backed by a
  committed package-list, pointing at the Groovy version the build
  actually uses (2.4.21) rather than "latest".
@vharseko vharseko added bug Something isn't working ci CI, build & workflow changes build Maven build configuration and plugins documentation README, docs, license headers labels Sep 29, 2026

@maximthomas maximthomas left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

praise: The change removes the network fetch where the flake comes from, and pins the link to the Groovy version the build actually resolves.

  • OpenICF-java-framework/bundles-parent/src/javadoc/groovy-2.4.21/package-list is identical to the file served at https://docs.groovy-lang.org/2.4.21/html/api/package-list (95 packages). That site returns 404 for element-list, so package-list is the right file.
  • The offlineLink URL targets 2.4.21, the groovy-all resolved through opendj-parent 5.1.2 → commons parent 3.1.2, instead of latest (Groovy 5).
  • All nine build-maven cells pass on e618c3a, windows-latest 11/26 included.

@vharseko
vharseko merged commit bc957be into OpenIdentityPlatform:master Oct 2, 2026
14 checks passed
@vharseko
vharseko deleted the groovy-javadoc-offline-link branch October 2, 2026 12:02
vharseko added a commit that referenced this pull request Oct 5, 2026
## Summary

Follow-up to the unused-parameter cleanup (#141): investigated all the
newly-surfaced small `note`-severity CodeQL categories.

- **`GuardedString`** now overrides `toString()` (returns
`"GuardedString(...)"`), so it no longer inherits `Object`'s default.
Fixes `call-to-object-tostring` at its root instead of patching the two
current call sites (`SharedSecretPrincipal`,
`ScriptOnResourceApiOpTests`) individually — any future logging of a
`GuardedString` is safe by construction. This is more than cosmetic: the
inherited output printed `hashCode()`, which is derived from the
unsalted SHA-1 hash of the clear text, so a fingerprint of the secret
reached log text — through `SharedSecretPrincipal.toString()`, and, with
OK-level logging on, through `LoggingProxy`, which prints every API
argument and return value: a `GuardedString` attribute value (e.g.
`__PASSWORD__`) passed to create/update or returned by getObject was
printed via `Attribute.toString()`.
- **`GuardedByteArray`** gets the same override
(`"GuardedByteArray(...)"`): its `hashCode()` is derived from the clear
bytes the same way, and it is a supported attribute type, so the same
`LoggingProxy` → `Attribute.toString()` path printed it.
- Fixes a shadowed local in `LdapInternalSearch.execute()`
(`local-shadows-field`).

Also dismissed on GitHub: 3 `ignored-error-status-of-call` (the ignored
return values are already covered by a subsequent check or exception
path), 8 `jdk-internal-api-access` (AD DirSync's
`com.sun.jndi.ldap.Ber*`, no public JDK alternative exists), 1
`confusing-method-signature` (`Log.log(..)` is long-standing,
heavily-used public API — renaming to remove the overload is too
invasive for the benefit).

Covered by other PRs instead of this one:
- #134 (opened independently, earlier) fixes byte-for-byte the same
lines in `AttributeTypeUtil.java`, `MultiOpTests.java`,
`PrettyStringBuilder.java`, `StringUtil.java`,
`ActiveDirectoryChangeLogSyncStrategy.java`, `XSDAnnotationParser.java`
(with `AttributeTypeUtilTests.java`):
`uncaught-number-format-exception`, `inefficient-boxed-constructor`,
`inefficient-empty-string-test`, `inefficient-key-set-iterator`,
`unknown-javadoc-parameter`, `missing-space-in-concatenation`. Dropped
here on 2026-09-21.
- #132 removes the dead `ContractTestFactory` inner class from
`ContractITCase` (`unused-reference-type`) along with more of that
file's dead code; the two PRs conflicted there, so this PR no longer
touches `ContractITCase`. Dropped here on 2026-10-04.

**Update 2026-10-02 (review round 1):** rebased onto the current
`master`; added the `GuardedByteArray` override; replaced the
`toString()` test, which passed even without the override, by one that
pins the fix; reworded the Javadoc to say why the override matters.

**Update 2026-10-04 (review round 2):** rebased onto the current
`master` (picks up #146, which fixes the `docs.groovy-lang.org` javadoc
failure that turned the `windows-latest, 11` cell red); both
`toString()` tests now also pin the exact output; corrected the
description of the `GuardedByteArray` leak (it was reachable, not
latent); dropped the `ContractITCase` change in favour of #132; aligned
the added 3A copyright lines to the repository's `Portions Copyrighted
2026 3A Systems, LLC`.

## Test plan
- [x] `GuardedStringTests.testToStringDoesNotDependOnTheSecret` and
`GuardedByteArrayTests.testToStringDoesNotDependOnTheSecret`: two
different secrets print the same `toString()`, and it is exactly
`"GuardedString(...)"` / `"GuardedByteArray(...)"`. Verified red with
the overrides removed (round 1) and with `toString()` returning `null` /
`""` (round 2).
- [x] `connector-framework` test suite after round 2 — 194 tests, 0
failures.
- [x] `connector-framework`, `connector-framework-contract`,
`OpenICF-ldap-connector` build after round 2.
- [x] `mvn install` on `connector-framework`,
`connector-framework-contract`, `OpenICF-ldap-connector` (incl. existing
test suites, LDAP/OpenDJ integration tests included) — all green, 946
tests, 0 failures (before the review rounds).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working build Maven build configuration and plugins ci CI, build & workflow changes documentation README, docs, license headers

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants