Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JENKINS-55048] Add support for plugin Java requirement metadata #3016

Merged
merged 25 commits into from
Jan 10, 2019

Conversation

daniel-beck
Copy link
Member

@daniel-beck daniel-beck commented Sep 11, 2017

See JENKINS-55048.

Downstream of jenkinsci/maven-hpi-plugin#75 and jenkins-infra/update-center2#164.

Future enhancement might be to send the Java version with the request (or consider it already sent by the user agent header) and handle that on the server side, similar to the tiered update sites. But for now, a big red (newly bold) warning should at least get us started.

Here is how it renders:
image

(I used http://updates.jenkins.io/temporary-experimental-java11/ for testing.
Pipeline: Supporting APIs, aka workflow-support is the only one requiring Java 11+.
The others are red because they depend on it directly or transitively.
I used the following system groovy quick&dirty script to check these things:

def showDeps(plugin, level) {
  println ("  ".multiply(level)+"${plugin.name}:${plugin.version}")
  
  plugin.getNeededDependencies().each { dep ->
    def dep1 = dep
    showDeps(dep1, level + 1);
  }
}
showDeps(Jenkins.instance.updateCenter.getPlugin('throttle-concurrents'), 0)

).

Proposed changelog entries

  • Add support for plugins declaring a minimum Java version in manifest and update center, showing warnings and refusing to load plugins with unsatisfied dependencies.

Submitter checklist

  • JIRA issue is well described
  • Changelog entry appropriate for the audience affected by the change (users or developer, depending on the change). Examples
    * Use the Internal: prefix if the change has no user-visible impact (API, test frameworks, etc.)
  • Appropriate autotests or explanation to why this change has no tests

Desired reviewers

@jenkinsci/code-reviewers

@daniel-beck daniel-beck added needs-more-reviews Complex change, which would benefit from more eyes on-hold This pull request depends on another event/release, and it cannot be merged right now labels Sep 11, 2017
Copy link
Member

@oleg-nenashev oleg-nenashev left a comment

Choose a reason for hiding this comment

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

Generally the PR looks good, added few comments.

I would also consider adding Maximum-Java-Version as a part of this story while you are around. E.g. I barely believe that Maven Integration Plugin can be made Java9-compatible easily (CC @aheritier)

@@ -8,3 +8,6 @@
margin: 1em;
text-align: right;
}
.compatWarning, .securityWarning {
font-weight: bold;
}
Copy link
Member

Choose a reason for hiding this comment

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

line break

jglick
jglick previously requested changes Sep 12, 2017
Copy link
Member

@jglick jglick left a comment

Choose a reason for hiding this comment

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

Misuse of java.version, otherwise looks good.

@daniel-beck
Copy link
Member Author

Rebased to current master with no impl changes so far.

@oleg-nenashev oleg-nenashev added the java11 Java 11 support in Jenkins label Nov 22, 2018
@batmat batmat self-assigned this Jan 3, 2019
batmat added 4 commits January 7, 2019 11:11
Given this field is present in maven-hpi-plugin, update-center, etc.
I think it does not hurt to keep the 'Minimum-Java-Version' name across
various usages to help make it clear.
This way at least we know the backend methods should not be broken without
noticing.
@batmat batmat changed the title [JENKINS-20679] Add support for plugin Java requirement metadata [JENKINS-55048] Add support for plugin Java requirement metadata Jan 7, 2019
@batmat batmat dismissed jglick’s stale review January 7, 2019 13:40

"Misuse of java.version, otherwise looks good." main reason addressed. Need another review.

@batmat batmat removed the on-hold This pull request depends on another event/release, and it cannot be merged right now label Jan 7, 2019
"title": "Dummy",
"url": "http://nowhere.net/dummy.hpi",
"version": "1.0",
"minimumJavaVersion": "25"
Copy link
Member

@batmat batmat Jan 7, 2019

Choose a reason for hiding this comment

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

Hopefully, we shouldn't get too quickly to this as a "future" baseline we're not running in during tests (?). Or maybe I should even have gone bigger. (maybe I should see to mock the runtime Java version retrieval to isolate the test from such issue in the future)

@batmat
Copy link
Member

batmat commented Jan 7, 2019

@jenkinsci/java11-support please review this pull-request.

@batmat
Copy link
Member

batmat commented Jan 7, 2019

To test this, a simple way is the following:

# Build and run a Jenkins with this patch
docker run -ti -e ID=3016 -p 8080:8080 batmat/jenkins-pr-tester

Then open a browser on 8080, and change the update center URL to http://updates.jenkins.io/temporary-experimental-java11/update-center.json to check how it behaves.
In this UC, the workflow-support plugin in 3.0-java11-alpha-11 requires Java 11.

@batmat batmat requested a review from MRamonLeon January 8, 2019 13:29
Copy link
Contributor

@MRamonLeon MRamonLeon left a comment

Choose a reason for hiding this comment

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

Minor comments, but anyway it LGTM

@batmat batmat requested a review from jglick January 9, 2019 17:13
@batmat
Copy link
Member

batmat commented Jan 9, 2019

@jglick I believe I addressed your feedback. Can you please take another quick look?

Thanks!

@batmat
Copy link
Member

batmat commented Jan 9, 2019

BTW, anyone willing to have another look is welcome.
The additions I made since approvals are very trivial, often in javadoc only but a few confirmed approvals would be better I suppose.

Thanks!

return !javaVersion.startsWith("1.");
}

/**
* Returns the JVM's current version as a {@link VersionNumber} instance.
Copy link
Member

Choose a reason for hiding this comment

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

Best to document this with examples. IIUC these would be

  • 1.8
  • 9
  • 10
  • 11

?

Copy link
Member

Choose a reason for hiding this comment

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

Yes. Basically JEP-223

Copy link
Member

Choose a reason for hiding this comment

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

Great, but please link to this so that people do not have to discover it by code inspection and independent research.

Copy link
Member

Choose a reason for hiding this comment

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

@jglick fix proposed in #3842

@batmat batmat added the ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback label Jan 9, 2019
@batmat batmat merged commit eb39d6b into jenkinsci:master Jan 10, 2019
@oleg-nenashev
Copy link
Member

It causes https://issues.jenkins-ci.org/browse/JENKINS-55562 , because there is no version normalization code in this pull request. Both 8 and 1.8 are valid version numbers, because pre-JEP-223 format stays valid for older versions

@jglick
Copy link
Member

jglick commented Jan 14, 2019

there is no version normalization code in this pull request

Nor should there be IMO—normalization should be performed on input, at build time.

Both 8 and 1.8 are valid version numbers, because pre-JEP-223 format stays valid for older versions

My reading of JEP-223 is that Java version numbers in the range [1.9,9) are invalid for all time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
java11 Java 11 support in Jenkins needs-more-reviews Complex change, which would benefit from more eyes ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants