* Clarify credential environment variable inputs
Rename credential-related inputs to make their environment-variable semantics explicit while preserving deprecated aliases with migration warnings.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 70a3daa8-dbc9-4eb0-a57b-df198a459315
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Use gpg.passphraseEnvName instead of gpg.passphrase server
The maven-gpg-plugin's `gpg.passphrase`/`passphraseServerId` mechanism is
deprecated and fails when the plugin's `bestPractices` mode is enabled.
Stop writing the `gpg.passphrase` server to settings.xml and instead set
`gpg.passphraseEnvName` via an active profile when the configured passphrase
env var name differs from the plugin default (MAVEN_GPG_PASSPHRASE).
The default `gpg-passphrase` input value (GPG_PASSPHRASE) is unchanged, so the
plugin reads the same environment variable as before.
Fixes#760
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Fix settings.xml publishing validation
Update the publishing e2e check to assert the settings.xml generated when gpg-passphrase is MAVEN_GPG_PASSPHRASE. In that default case the action no longer writes a gpg.passphrase server entry.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7d0a510e-aebf-4ec4-a667-efeb3e4edeb1
* Default gpg-passphrase to MAVEN_GPG_PASSPHRASE
Align the default `gpg-passphrase` input value with the maven-gpg-plugin
default environment variable name (MAVEN_GPG_PASSPHRASE). With this default,
setup-java writes no extra GPG configuration to settings.xml and the plugin
reads the passphrase from MAVEN_GPG_PASSPHRASE out of the box.
Also document that reading the passphrase from an environment variable via
`gpg.passphraseEnvName` requires maven-gpg-plugin 3.2.0 or newer.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7d0a510e-aebf-4ec4-a667-efeb3e4edeb1
* Document gpg-passphrase breaking change in V6
Add a "Breaking changes in V6" section to the README covering the switch to
gpg.passphraseEnvName, the new MAVEN_GPG_PASSPHRASE default, and the
maven-gpg-plugin 3.2.0+ requirement.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7d0a510e-aebf-4ec4-a667-efeb3e4edeb1
* Keep GPG_PASSPHRASE default for v5 compatibility
Revert the gpg-passphrase input default back to GPG_PASSPHRASE so existing v5
workflows that set the GPG_PASSPHRASE environment variable keep working without
changes. setup-java writes gpg.passphraseEnvName=GPG_PASSPHRASE into an active
profile, so the maven-gpg-plugin reads the same variable as before.
The only remaining compatibility requirement is maven-gpg-plugin 3.2.0+, which
is documented in the README and advanced usage guide.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7d0a510e-aebf-4ec4-a667-efeb3e4edeb1
* Clarify GPG passphrase profile compatibility
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7d0a510e-aebf-4ec4-a667-efeb3e4edeb1
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Cache Maven wrapper distribution separately from the local repository
The Maven wrapper distribution (~/.m2/wrapper/dists) was cached in the same
entry as the local Maven repository (~/.m2/repository), keyed on a hash of
**/pom.xml (plus wrapper properties and extensions). Because pom.xml changes
frequently and no restoreKeys are used (by design, #269), almost every change
produces a full cache miss and the wrapper distribution is re-downloaded via
mvnw — which intermittently fails due to upstream rate limiting.
The wrapper distribution only depends on maven-wrapper.properties, which
changes very rarely. Give it its own cache entry keyed solely on
**/.mvn/wrapper/maven-wrapper.properties so it survives the frequent pom.xml
changes that rotate the main dependency cache key.
- Add a generic additionalCaches concept to PackageManager, restored and saved
independently with name-scoped state keys.
- Move ~/.m2/wrapper/dists out of the main maven path into a maven-wrapper
additional cache; skip silently when the project does not use mvnw.
- Keep cache-hit / cache-primary-key outputs driven by the main cache.
- Update tests, docs, and rebuild dist bundles.
Fixes#1095
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Cache Gradle wrapper distribution separately from the dependency cache (#1098)
The Gradle wrapper distribution (~/.gradle/wrapper) only depends on
gradle-wrapper.properties, which changes rarely, but it was previously
cached in the same entry as ~/.gradle/caches, keyed on volatile
**/*.gradle* files with no restoreKeys (issue #269). Every dependency
change therefore re-downloaded the wrapper.
Move ~/.gradle/wrapper into a dedicated `gradle-wrapper` additional
cache keyed only on **/gradle-wrapper.properties, reusing the
additionalCaches infrastructure introduced for the Maven wrapper fix.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Fix broken try/catch in saveAdditionalCache and rebuild dist
The autofix commits dropped the `} catch (error) {` line in
saveAdditionalCache, leaving a `try` block without a catch and a dangling
`error` reference, which broke compilation and Prettier. Restore the catch
clause, reformat, and regenerate the dist bundles.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Address cache.ts review feedback
- saveAdditionalCache: handle @actions/cache ValidationError (thrown when the
cache paths do not resolve, e.g. the wrapper distribution was never
downloaded) by skipping instead of failing the post step. Add a test.
- Point the Gradle wrapper cache comment at issue #269 (Gradle wrapper cache
churn) instead of the Maven-specific #1095.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Document Gradle Wrapper distribution caching in README
Add a parallel "Gradle Wrapper" note alongside the Maven Wrapper note, so the
new behavior for cache: 'gradle' (caching ~/.gradle/wrapper in a separate entry
keyed on **/gradle-wrapper.properties) is documented.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Update recommended configuration for GPG signing
This attempts to document the new recommended configuration to sign artifacts with the maven-gpg-plugin as part of the deploy process.
It imitates this PR from the maintainer of the maven-gpg-plugin:
https://github.com/xerial/sqlite-jdbc/pull/1082/files
Notes that this requires the maven-gpg-plugin version 3.2.0 or above, not sure if this is worth adding to the documentation as I expect this guide will mostly be followed by people setting up a new project (hopefully using the latest version of the plugin by default).
@cstamas I hope I got it right, feel free to suggest any improvements
* Remove unnecessary comment
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* docs: tidy GPG signing section for bc signer
- Remove leftover gpg.passphrase server from the GitHub Packages settings.xml example
- Clarify that the bc signer needs no gpg binary, keychain import, or pinentry loopback
- Document the legacy gpg-private-key/gpg-passphrase input path alongside it
- Note the MAVEN_GPG_KEY must be an ASCII-armored (TSK) secret key
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 50be9bf4-3414-43f2-8454-03c2d9e61973
* docs: add legacy GPG signing example alongside bc signer
Restore a complete, clearly-labeled legacy path (setup-java gpg-private-key/
gpg-passphrase inputs) for maven-gpg-plugin < 3.2.0 or the gpg executable:
full workflow YAML, the generated gpg.passphrase server, and the
--pinentry-mode loopback pom.xml snippet.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 50be9bf4-3414-43f2-8454-03c2d9e61973
---------
Co-authored-by: Bruno Borges <bruno.borges@gmail.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Bruno Borges <brborges@microsoft.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Add the `liberica-nik` distribution (Liberica Native Image Kit), a
GraalVM-based build from BELL Software resolved via the Bell-SW
`/v1/nik/releases` API.
- `java-version` matches the embedded JDK version (from the release's
`liberica` component), consistent with every other distribution.
- `java-package: jdk` installs the `standard` bundle; `jdk+fx` installs
the `full` bundle with JavaFX/Swing support.
- Supported on Linux, macOS and Windows for x64 and aarch64.
Signed-off-by: asm0dey <pavel.finkelshtein@gmail.com>
Co-authored-by: Bruno Borges <brborges@microsoft.com>
* Preserve Maven toolchains across repeated setup-java runs (#1099)
Toolchain generation was gated behind the `overwrite-settings` input,
which is documented to control only regeneration of `settings.xml`.
Because `generateToolchainDefinition` already performs a non-destructive
merge (existing JDK, custom, and user-managed toolchains are preserved,
and only an entry with the same `type` + `provides.id` is replaced),
skipping the write when `overwrite-settings: false` caused later
setup-java executions to drop toolchain entries registered by earlier
runs.
Decouple toolchains generation from `overwrite-settings`: the toolchains
file is now always written, so consecutive runs accumulate every JDK.
`settings.xml` behavior (auth.ts) is unchanged.
- src/toolchains.ts: drop overwriteSettings from configureToolchains /
createToolchainsSettings / writeToolchainsFileToDisk; always write.
- __tests__/toolchains.test.ts: update call sites, rewrite the
"does not overwrite" test to assert non-destructive extension, and add
a regression test for consecutive configureToolchains executions.
- docs/advanced-usage.md: clarify merge is non-destructive and
independent of overwrite-settings.
- dist/setup/index.js: rebuilt.
Fixes#1099
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 0bcec457-b86b-4902-b6e6-6dfd6b2570f7
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
- Update Tencent Kona documentation to list JDK 25 as supported
- Add Kona 25 to the e2e verification matrix (ubuntu, windows, macos)
- Extend Kona test fixture with real Kona 25.0.3 release entries
- Add unit tests covering Kona 25 selection across all platforms
Signed-off-by: John Jiang <johnsjiang@tencent.com>
Co-authored-by: Bruno Borges <brborges@microsoft.com>
Address post-merge review feedback on #1094: the intro paragraph
described the cache too narrowly. setup-java caches both
~/.m2/repository and ~/.m2/wrapper/dists, and the default key hashes
**/pom.xml plus .mvn/wrapper/maven-wrapper.properties and
.mvn/extensions.xml, so changing wrapper/extensions files also
invalidates the cache.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* docs: document Maven cache seeding for plugin dependencies (#990)
Explain that setup-java's maven cache only stores what a run downloads and
is not re-saved on a hit, so plugin dependencies resolved lazily (e.g. by
maven-shade-plugin) can be missing from the cache. Document a dependency
resolution 'seed' step (dependency:go-offline + dependency:resolve-plugins)
in README and a fuller advanced-usage section with a goal-comparison table,
single-job and separate-seed-job examples, and caveats.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* docs: note gradle cache has the same limitation, point to setup-gradle (#990)
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* docs: shorten README maven cache note, link to advanced docs (#990)
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* docs: cover the parallel multi-job cache race in the seed-job example (#705)
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Infer distribution from asdf .tool-versions vendor prefix
asdf-java encodes the JDK vendor as a prefix on the version string in
.tool-versions (e.g. `java temurin-17.0.3+7`). Capture that prefix and
map it to a setup-java distribution, mirroring the existing .sdkmanrc
behavior. Unknown prefixes warn and fall back to the distribution input.
Fixes#1081
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Rename jdkFile input to jdk-file with deprecated alias
Add a standardized `jdk-file` input to match the lowercase-dash naming
used by every other action input. The camelCase `jdkFile` input is kept
as a deprecated alias: it still works, but emits a deprecation warning and
may be removed in a future release. `jdk-file` takes precedence when both
are provided.
Updates docs and the local-file e2e workflow (one case intentionally keeps
using the deprecated alias for coverage) and regenerates the dist bundles.
Fixes#1077
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* docs: keep jdkFile in switching-to-v2 guide
The switching-to-v2 migration guide uses actions/setup-java@v2, which only supports the camelCase jdkFile input. Keep the new jdk-file spelling in current-version docs only.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Use Azul metadata API
* Document arm64 -> aarch64 mapping in README.md
* Paginate through all available versions
* Fix typo: win_aarhc4
* Only query for linux_glibc packages
* Add Zulu CRaC package support to metadata migration
Fold CRaC-related work into the Zulu metadata API migration by wiring crac_supported query handling, extending Zulu package docs, and updating installer tests for jdk+crac/jre+crac behavior.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Harden Zulu metadata pagination with safety cap
- Stop paginating on a short page to avoid an extra empty request
- Guard against undefined results (not just null)
- Cap iterations at 100 pages and warn if the limit is hit to
prevent a runaway loop if the API misbehaves
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Preserve JDK build number from Azul Metadata API
The Azul Metadata API returns java_version as a 3-element array
(e.g. [17,0,7]) and reports the build number separately in
openjdk_build_number. The migration mapped version directly from
java_version, dropping the build and breaking exact-version lookups
like 17.0.7+7 (e2e failure: "No matching version found for SemVer").
Add openjdk_build_number to IZuluVersions and append it to
java_version before converting to semver so resolved versions retain
the build (e.g. 17.0.7+7). Update the zulu test fixtures to mirror the
real API shape (3-element java_version plus openjdk_build_number) so
unit tests exercise the actual response format, and rebuild dist.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Bruno Borges <brborges@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* feat: Add distribution detection support to .sdkmanrc file
Extends .sdkmanrc support to automatically detect Java distribution from SDKMAN identifiers (e.g., java=21.0.5-tem maps to temurin distribution).
Makes distribution input optional when using .sdkmanrc with distribution suffix.
* fix: align SDKMAN sem identifier mapping
* fix: support SDKMAN albba identifier
* docs: clarify sdkmanrc distribution inference scope
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Add Tencent Kona SDKMAN mapping and format sdkmanrc docs as a table
- Map SDKMAN 'kona' identifier to the 'kona' distribution (added in #672)
- Add a .sdkmanrc test case for the kona suffix
- Convert the inline SDKMAN suffix mapping in advanced-usage.md to a table
- Rebuild dist bundles
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Bruno Borges <brborges@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Bruno Borges <bruno.borges@gmail.com>
* docs: document the Java problem matcher and how to disable it
Add an advanced-usage section explaining the javac/java problem matcher that
setup-java registers, and how to turn it off for a job using the built-in
::remove-matcher:: workflow command (owners javac and java).
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* docs: document Maven Wrapper caching and generated interactiveMode
- README: note that cache: 'maven' also caches/restores the Maven Wrapper
distribution (~/.m2/wrapper/dists), not just the local repository.
- advanced-usage: note that the generated settings.xml sets interactiveMode=false
for non-interactive CI runs.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Clarify Java problem matcher annotations
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Add set-default option
This option allows to install an additional JDK without making it the
default one.
I have wanted this for quite a long time as I'm running custom GitHub
Actions with Java, which might require a specific JDK and I don't want
to pollute the JDK that is used by the overall workflow calling the
action.
And I'm apparently not alone as there was a preexisting issue.
Fixes#560
* Dedupe setJavaDefault and document multi-version/toolchain behavior
- Refactor setJavaDefault to delegate shared output/env logic to
setJavaEnvironment, avoiding duplication between the two.
- Document that set-default applies to all JDKs in a multiline
java-version, and that installed JDKs remain registered in Maven
toolchains regardless of set-default.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* test: fix Prettier formatting in base-installer test
Resolves the failing 'Basic validation / build' format-check on
__tests__/distributors/base-installer.test.ts (line exceeded print width).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Bruno Borges <brborges@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* feat: suppress Maven transfer progress via MAVEN_ARGS by default
Set MAVEN_ARGS to include -ntp (--no-transfer-progress) so Maven invocations
in the job produce cleaner CI logs without download/transfer progress noise.
Add a new optional 'show-download-progress' input (default false); set it to
true to keep the progress output.
The change preserves any existing MAVEN_ARGS value (the flag is appended,
not overwritten) and is idempotent (it won't add the flag twice if -ntp or
--no-transfer-progress is already present). Applies on all platforms; honored
by Maven 3.9.0+ and the Maven Wrapper, and is a no-op for non-Maven builds.
- action.yml: add show-download-progress input
- src/constants.ts: add input + MAVEN_ARGS constants
- src/maven-args.ts: new configureMavenArgs()
- src/setup-java.ts: invoke configureMavenArgs() during setup
- __tests__/maven-args.test.ts: unit tests
- docs/advanced-usage.md: document the behavior and input
- dist: rebuild bundled action
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Update generated dist for Maven args log change
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
* chore: enforce pre-PR validation with aggregate scripts, git hooks, and PR checklist
Add tooling to help contributors run the same checks as CI before
submitting a pull request, reducing avoidable format/lint/build failures.
- Add aggregate npm scripts:
- `npm run check` runs format-check + lint + build + test (mirrors CI)
- `npm run fix` runs format + lint:fix + build
- Add husky + lint-staged git hooks (installed via `npm install`):
- pre-commit formats and lints staged files
- pre-push rebuilds dist/ and runs the test suite
- Add a checklist item to the PR template prompting contributors to run
`npm run check` locally
- Document the aggregate scripts and hooks in docs/contributors.md
dist/ is intentionally not auto-committed by CI to avoid pwn-request
security risks; the existing `Check dist/` workflow continues to verify it.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Apply suggestions from code review
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
- installer: surface a clear error when the GraalVM Community releases
listing is not a JSON array, instead of silently treating an error
payload (rate limit, auth failure, etc.) as "no releases" which later
surfaced as a misleading "version not found" error.
- docs: fix the GraalVM Community advanced-usage example to check the
installed binary versions (java/native-image --version) rather than
running a non-existent HelloWorldApp classpath that fails when copied.
- tests: cover the new non-array release listing error path.
Rebuilt dist bundle.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* docs: note jdkfile approach for Early Access / unreleased JDK builds
Clarify in advanced-usage that the existing 'jdkfile' distribution can be
used to install Early Access (EA) or other unreleased JDK builds not
provided directly by setup-java, by downloading the archive in a prior
step and pointing jdkFile at it. Adds a concrete EA example.
Addresses #612.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Apply suggestions from code review
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Initial plan
* feat: add graalvm community distribution support
* build: update bundled dist for graalvm community support
* chore: address GraalVM community review feedback
* fix: tidy graalvm community validation follow-ups
* refactor: simplify GraalVM Community release resolution
* refactor: address review feedback on Community resolver
* refactor: rename pagination index for clarity
* test: fix graalvm installer test formatting
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Bruno Borges <brborges@microsoft.com>
Document how to make the installed JDK trust an internal CA at application
runtime by importing it into $JAVA_HOME/lib/security/cacerts with keytool
after setup-java runs. Clarifies this is the runtime trust layer, distinct
from the download/transport layer (NODE_EXTRA_CA_CERTS), and notes hosted vs
self-hosted persistence caveats.
Refs #640#1035
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Adds an advanced-usage section explaining the 'self signed certificate in
certificate chain' error seen on GitHub Enterprise Server and behind
TLS-inspecting proxies. Recommends the secure fix of trusting the internal
CA via NODE_EXTRA_CA_CERTS (or the OS trust store on self-hosted runners),
with a GitHub Enterprise callout, and warns against disabling TLS
verification since the JDK download has no checksum fallback.
Refs #640
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Initial plan
* docs: replace HelloWorldApp references with java --version in README and advanced-usage
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
* chore(e2e-versions): Add e2e test scenario on `setup-java-version-from-file-major-minor-patch-with-dist` for `.sdkmanrc`
* chore(e2e-versions): Update `setup-java-version-from-file-major-minor-patch-with-dist` test to include the file name of the java-version-file that is used
* feat: Add support for `.sdkmanrc` as *Java Version File*
* chore: Add test for the latest known sdkman java versions
* docs(advanced-usage): Document support for `.sdkmanrc` as java-version-file
* chore(docs): Anyone can contribute and maintain 🤷
* Update advanced-usage.md
Add example step/file for `.sdkmanrc`
* Update advanced-usage.md
* Update util.ts
* chore: format and rebuild
* chore: untouch toolchains.ts
* fix check dist error
---------
Co-authored-by: mahabaleshwars <147705296+mahabaleshwars@users.noreply.github.com>
* added support for tool version file
* testing with one regex
* working regex
* Checked for the file extension
* added e2e checks for tool version
* removed error warning
* updated regex to support early version
* updated regex for early version support
* updated regex for early version
* updated regex to accept early versions
* added coreinfo to analyze
* updated the regex
* updated regex
* new regex for early version
* updated regex to match the new version file format
* new regex
* changed the regex
* redex updated
* used java version regex
* regex updated
* regex modified
* regex updated
* regex updated
* regex updated
* updated regex to support early versions
* Regex updated to support all java versions
* Documentation updated to add tool version description
* Documentation updated for the tool version file
* update the advanced doc and readme file to specify tool version changes
Bruno Borges
Copilot
Haritha
Antonin Delpeuch
Pasha Finkelshteyn
John Jiang
James Wald
Lukasz
Guillaume Smet
Bruno Borges
Josh Soref
mahabaleshwars
guicamest
aparnajyothi-y
lmvysakh
Marcono1234
Gregory Mitchell
Fabio Niephaus
Tobias
dependabot[bot]
Michael Keppler
Ivan