CAMEL-23112 - add back JDk 17 on Jenkins

[apupier]

Kept JDK 21 as the "principal" target branch for coverage and Sonar check

Description

Target

• I checked that the commit is targeting the correct branch (Camel 4 uses the main branch)

Tracking

• If this is a large change, bug fix, or code improvement, I checked there is a JIRA issue filed for the change (usually before you start working on it).

Apache Camel coding standards and style

• I checked that each commit in the pull request has a meaningful subject line and body.

• I have run mvn clean install -DskipTests locally from root folder and I have committed all auto-generated changes.

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using build-all, build-dependents, skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[gnodet]

The JDK 17 support changes look straightforward.

One question about the deploy defaults change: switching from deploy to no-deploy as the default in Jenkinsfile.deploy could affect other pipelines or jobs that rely on the current default behavior. Is this intentional, or should it be a separate change?

The rest (adding JDK 17 to the build matrix, test matrix) looks fine.

[apupier]

One question about the deploy defaults change: switching from deploy to no-deploy as the default in Jenkinsfile.deploy could affect other pipelines or jobs that rely on the current default behavior. Is this intentional, or should it be a separate change?

there is no such change in this PR as far as i can see. Can you provide more details?

[apupier]

One question about the deploy defaults change: switching from deploy to no-deploy as the default in Jenkinsfile.deploy could affect other pipelines or jobs that rely on the current default behavior. Is this intentional, or should it be a separate change?

there is no such change in this PR as far as i can see. Can you provide more details?

merging as it is causing JBang tests failing as they are using the snapshots version deployed on the Apache Snapshots repository which are for now compiled with JDK 21.

Please follow-up in a specific issue to discuss what you reported with more details