Offering default methods on ParameterizedJob #2864

jglick · 2017-05-01T19:34:50Z

Description

Allows subtypes to have less boilerplate. Mentioned as a design pattern in #2730.

Changelog entries

None required.

Desired reviewers

@reviewbybees

ghost · 2017-05-01T19:35:29Z

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

jglick · 2017-05-01T19:35:20Z

core/src/main/java/jenkins/model/ParameterizedJobMixIn.java

+         * Cancels a scheduled build.
+         * @see ParameterizedJobMixIn#doCancelQueue
+         */
+        @RequirePOST


cf. jenkinsci/stapler#113

jglick · 2017-05-01T22:14:36Z

[ERROR] …/core/src/main/java/jenkins/model/ParameterizedJobMixIn.java:165: error: reference not found
[ERROR] * Standard implementations of {@link ParameterizedJob#isParametrized}.
[ERROR] ^
[ERROR]

oleg-nenashev

Kinda 🐛 since it advertises non-Restricted & non-RequirePOST method in all ParameterizedJob implementations. Even though it is a historic API in AbstractProject, I am not sure we want to offer it in other job types

oleg-nenashev · 2017-05-02T09:55:04Z

core/src/main/java/jenkins/model/ParameterizedJobMixIn.java

+         * Schedules a new build command.
+         * @see ParameterizedJobMixIn#doBuild
+         */
+        default void doBuild(StaplerRequest req, StaplerResponse rsp, @QueryParameter TimeDuration delay) throws IOException, ServletException {


So, no Restricted/RequirePOST annotations here? I am not sure it is safe to offer such default impl. 🐛 , but probably I miss something.

The original had neither annotation. @Restricted cannot be added compatibly. @RequirePOST is unwanted since the implementation checks the request method explicitly.

oleg-nenashev · 2017-05-02T09:55:11Z

core/src/main/java/jenkins/model/ParameterizedJobMixIn.java

+         * Currently only String parameters are supported.
+         * @see ParameterizedJobMixIn#doBuildWithParameters
+         */
+        default void doBuildWithParameters(StaplerRequest req, StaplerResponse rsp, @QueryParameter TimeDuration delay) throws IOException, ServletException {


stephenc

Looks good to me.

The public doBuild method that is being moved does not currently have any annotations, so while I think it should have a @RequirePOST annotation, this refactoring is not making the code worse than it already is and therefore the lack of an annotation is not blocking this PR IMHO

oleg-nenashev · 2017-05-02T10:38:33Z

@stephenc

... this refactoring is not making the code worse than it already is and therefore the lack of an annotation is not blocking this PR IMHO

From what I see it adds new API to the ParameterizedJob interface (new default method doBuilds(), which was not defined in the interface before), so IMHO it makes the code worse.

stephenc · 2017-05-02T10:42:25Z

From what I see it adds new API to the ParameterizedJob interface (new default method doBuilds(), which was not defined in the interface before), so IMHO it makes the code worse.

Well ParameterizedJob is a marker interface and this is just a refactoring of methods in classes implementing that marker interface, so I see it as non-blocking for this PR but the lack of annotation should be fixed (just in a different PR with a separate JIRA to track that change as I think the annotation change could affect users that may have been accidentally using the "feature" so to co-mingle with this PR would hide the change)

jglick · 2017-05-02T10:57:57Z

core/src/main/java/jenkins/model/ParameterizedJobMixIn.java

+            return getParameterizedJobMixIn().scheduleBuild(quietPeriod, c);
+        }
+
+        // omitting scheduleBuild2(int, Action...) since it is defined in SCMTriggerItem (could include less commonly used overloads if desired)


Actually as per this tip it could be defined here. Implementing classes would still need to define the method, but at least they could select a known super implementation, which is probably more discoverable than looking for similar methods on a mixin.

jglick · 2017-05-02T10:59:00Z

core/src/main/java/jenkins/model/ParameterizedJobMixIn.java

+
+        // omitting scheduleBuild2(int, Action...) since it is defined in SCMTriggerItem (could include less commonly used overloads if desired)
+
+        // cannot offer makeSearchIndex() since it is defined in Job


This case would still be tricky however, since the defining method is protected and we do not really want to force implementations to override it as public.

jglick · 2017-05-02T11:01:06Z

core/src/main/java/jenkins/model/ParameterizedJobMixIn.java

+         * Schedules a new build command.
+         * @see ParameterizedJobMixIn#doBuild
+         */
+        default void doBuild(StaplerRequest req, StaplerResponse rsp, @QueryParameter TimeDuration delay) throws IOException, ServletException {


The original had neither annotation. @Restricted cannot be added compatibly. @RequirePOST is unwanted since the implementation checks the request method explicitly.

jglick · 2017-05-02T16:42:39Z

Test failures are bogus.

Withdrawing for the moment since I want to check if I can offer default versions of even (public) methods defined in supertypes.

jglick · 2017-05-02T20:29:53Z

Hmm,

Failed to execute goal com.infradna.tool:bridge-method-injector:1.15:process (default) on project jenkins-core: Failed to process @WithBridgeMethods: Failed to process …/core/target/classes/hudson/model/AbstractProject.class: INVOKESPECIAL/STATIC on interfaces require ASM 5

seems like exactly what jenkinsci/bridge-method-injector#14 should have been solving. Investigating.

Explained a week ago why the design is intentional; no response since.

jglick · 2017-05-09T14:54:03Z

BTW test failures in this & related PRs are due to INFRA-1176; will make sure tests pass before merging.

oleg-nenashev

I have checked all usages of "instanceof BuildableItem". Actually there are extra implementations in tests, but I do not see anything risky within jenkinsci org and several other repos I usually check. And yes, the ParameterizedJobMixIn seems to be always buildable according to Javadoc

Here is a list of ones which attracted my attention:

SAFE - https://github.com/jenkinsci/github-plugin/blob/93d40692ff3866705175624e93ec584d4ac88132/src/main/java/org/jenkinsci/plugins/github/util/JobInfoHelpers.java#L47-L57 => 'item instanceof Job ' check leads to another branch
LIKELY SAFE - https://github.com/jenkinsci/blueocean-plugin/blob/7416f58310e3a72a24d93a95e435d1db9cbc9d2d/blueocean-rest-impl/src/main/java/io/jenkins/blueocean/service/embedded/rest/QueueUtil.java#L59
- invokes doomsday error otherwise. likely the BO code should just invoke Job#isBuildable()
- CC @i386 just in case
SAFE - https://github.com/i-m-c/jenkins-inheritance-plugin (my favorite source of edge cases outside jenkinsci) - implements Project, which is already buildable
LIKELY SAFE: Trigger plugins. From what I see, triggers will become isApplicable() to BuildableItem instances
SAFE - https://github.com/jenkinsci/computer-queue-plugin/blob/4c2091b021960c7ac1d73a7bd504ef1ee3208831/src/main/java/org/jenkinsci/plugins/computerqueue/ComputerQueue.java#L24 , no idea what the item could be doing there if it is not buildable

oleg-nenashev · 2017-05-10T07:57:22Z

core/src/main/java/jenkins/model/ParameterizedJobMixIn.java

     */
-    public interface ParameterizedJob extends hudson.model.Queue.Task, hudson.model.Item {
+    public interface ParameterizedJob<JobT extends Job<JobT, RunT> & ParameterizedJobMixIn.ParameterizedJob<JobT, RunT> & Queue.Task, RunT extends Run<JobT, RunT> & Queue.Executable> extends BuildableItem {


To follow-up on my bug in #2874 (comment) . Effectively it makes any any Parameterized job explicitly buildable. After some consideration, it seems to be a valid change according to the ParameterizedJobMixIn documentation.

🐜 since I expect ParameterizedJob Javadoc to explicitly say it.

Well the mixin Javadoc does say

be scheduled in various ways

which I guess is enough. Anyway BuildableItem is an interface which is not used all that much and not especially interesting to people grokking this code.

oleg-nenashev

🐝 after the review of possible regressions due to making all ParameterizedJobs BuildableItems.

@reviewbybees done, passing to @jenkinsci/code-reviewers

jglick · 2017-05-11T13:39:26Z

core/src/main/java/hudson/model/AbstractProject.java

@@ -143,7 +143,7 @@
 * @see AbstractBuild
 */
 @SuppressWarnings("rawtypes")
-public abstract class AbstractProject<P extends AbstractProject<P,R>,R extends AbstractBuild<P,R>> extends Job<P,R> implements BuildableItem, LazyBuildMixIn.LazyLoadingJob<P,R>, ParameterizedJobMixIn.ParameterizedJob {
+public abstract class AbstractProject<P extends AbstractProject<P,R>,R extends AbstractBuild<P,R>> extends Job<P,R> implements BuildableItem, LazyBuildMixIn.LazyLoadingJob<P,R>, ParameterizedJobMixIn.ParameterizedJob<P, R> {


implements BuildableItem is now redundant, could be removed I guess.

I have checked all usages of "instanceof BuildableItem".

The only implementations of ParameterizedJob were already BuildableItems so retrofitting it to implement that interface should not cause any behavioral change even if someone were doing that instanceof check.

oleg-nenashev · 2017-05-13T10:20:57Z

According to the discussion at the governance meeting on May 10, merging it towards 2.61

* Offering default methods on ParameterizedJob. * Javadoc typo. * Cleaner use of default methods in ParameterizedJob. * Need to pick up jenkinsci/bridge-method-injector#15 to be able to build. * Using new type bounds. * bridge-method-injector 1.17

Cf. jenkinsci/jenkins#2864 & jenkinsci/jenkins#3142.

Offering default methods on ParameterizedJob.

2e27be7

jglick requested a review from abayer May 1, 2017 19:34

jglick commented May 1, 2017

View reviewed changes

jglick mentioned this pull request May 1, 2017

Simplifying code using default methods on ParameterizedJob jenkinsci/workflow-job-plugin#45

Merged

abayer approved these changes May 1, 2017

View reviewed changes

jglick mentioned this pull request May 1, 2017

[JENKINS-24141] Pull ChangeLogSet-related logic out of AbstractBuild #2730

Merged

3 tasks

Javadoc typo.

fbadce3

oleg-nenashev previously requested changes May 2, 2017

View reviewed changes

stephenc approved these changes May 2, 2017

View reviewed changes

jglick commented May 2, 2017

View reviewed changes

jglick added the work-in-progress The PR is under active development, not ready to the final review label May 2, 2017

Cleaner use of default methods in ParameterizedJob.

626b876

Need to pick up jenkinsci/bridge-method-injector#15 to be able to build.

3139f23

jglick removed the work-in-progress The PR is under active development, not ready to the final review label May 2, 2017

jglick mentioned this pull request May 3, 2017

[JENKINS-27299] Define disabled in ParameterizedJob rather than AbstractProject #2866

Merged

jglick added the needs-more-reviews Complex change, which would benefit from more eyes label May 3, 2017

Using new type bounds.

36a5301

abayer approved these changes May 9, 2017

View reviewed changes

jglick added 2 commits May 9, 2017 13:58

bridge-method-injector 1.17

faaee4c

Merge branch 'master' into ParameterizedJobMixIn-defaults

8f49071

oleg-nenashev reviewed May 10, 2017

View reviewed changes

oleg-nenashev approved these changes May 10, 2017

View reviewed changes

jglick commented May 11, 2017

View reviewed changes

oleg-nenashev merged commit 37dfa99 into jenkinsci:master May 13, 2017

jglick deleted the ParameterizedJobMixIn-defaults branch May 15, 2017 13:56

jglick added a commit to jglick/maven-plugin that referenced this pull request Jan 5, 2018

Compilation problem with newer cores.

d0101a3

Cf. jenkinsci/jenkins#2864 & jenkinsci/jenkins#3142.

daniel-beck mentioned this pull request Apr 4, 2020

Make this compile again with a Jenkins 2.61+ dependency jenkinsci/jenkins-test-harness#207

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Offering default methods on ParameterizedJob #2864

Offering default methods on ParameterizedJob #2864

jglick commented May 1, 2017 •

edited

Loading

ghost commented May 1, 2017

jglick May 1, 2017

jglick commented May 1, 2017

oleg-nenashev left a comment

oleg-nenashev May 2, 2017

jglick May 2, 2017

oleg-nenashev May 2, 2017

stephenc left a comment

oleg-nenashev commented May 2, 2017 •

edited

Loading

stephenc commented May 2, 2017

jglick May 2, 2017

jglick May 2, 2017

jglick May 2, 2017

jglick commented May 2, 2017

jglick commented May 2, 2017

jglick commented May 9, 2017

oleg-nenashev left a comment •

edited

Loading

oleg-nenashev May 10, 2017

jglick May 10, 2017

oleg-nenashev left a comment

jglick May 11, 2017

oleg-nenashev commented May 13, 2017


		// omitting scheduleBuild2(int, Action...) since it is defined in SCMTriggerItem (could include less commonly used overloads if desired)

		// cannot offer makeSearchIndex() since it is defined in Job

Offering default methods on ParameterizedJob #2864

Offering default methods on ParameterizedJob #2864

Conversation

jglick commented May 1, 2017 • edited Loading

Description

Changelog entries

Desired reviewers

ghost commented May 1, 2017

Choose a reason for hiding this comment

jglick commented May 1, 2017

oleg-nenashev left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stephenc left a comment

Choose a reason for hiding this comment

oleg-nenashev commented May 2, 2017 • edited Loading

stephenc commented May 2, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jglick commented May 2, 2017

jglick commented May 2, 2017

jglick commented May 9, 2017

oleg-nenashev left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oleg-nenashev left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oleg-nenashev commented May 13, 2017

jglick commented May 1, 2017 •

edited

Loading

oleg-nenashev commented May 2, 2017 •

edited

Loading

oleg-nenashev left a comment •

edited

Loading