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

IntelliJ/Java: Duplicate code -- Refactored as UnstableAwareCommandInterpreter.helpCheckUnstableReturn #4077

Conversation

jsoref
Copy link
Contributor

@jsoref jsoref commented Jun 18, 2019

This is for discussion.

Notes:

  • Commits was probably created by IntelliJ for Java cleanup #4034
  • In general, commits should not change program behavior at all

Proposed changelog entries

  • Internal: Internal Java code cleanup

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
  • For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@Wadeck

@jsoref jsoref mentioned this pull request Jun 18, 2019
4 tasks
}

public boolean isApplicable(Class<? extends AbstractProject> jobType) {
return true;
}
}

static String invalidExitCodeZero() {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Need to remove this strategy as it won't do what I want, per #4034 (comment)

super(command);
}

static String invalidExitCodeZero() { return null; };
Copy link

Choose a reason for hiding this comment

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

Do they need to be static?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The problem is that the caller is:

    public static final class DescriptorImpl extends BuildStepDescriptor<Builder> {
...
        public FormValidation doCheckUnstableReturn(@QueryParameter String value) {
            return helpCheckUnstableReturn(value);

I'm not sure how to get past this. I guess the way to do it is to pass an object to helpCheckUnstableReturn

if (unstableReturn == 0) {
return FormValidation.warning(invalidExitCodeZero());
}
if (unstableReturn < 1 || unstableReturn > 255) {
Copy link

Choose a reason for hiding this comment

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

The code in BatchFile uses Integer.MIN_VALUE and Integer.MAX_VALUE so this would be changing the behaviour.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch.

return FormValidation.error(hudson.tasks.Messages.Shell_invalid_exit_code_range(unstableReturn));
}
return FormValidation.ok();
public static FormValidation doCheckUnstableReturn(@QueryParameter String value) {
Copy link

Choose a reason for hiding this comment

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

I'm not sure making it public is safe and backward compatible.

return FormValidation.error(hudson.tasks.Messages.BatchFile_invalid_exit_code_range(unstableReturn));
}
return FormValidation.ok();
static public FormValidation doCheckUnstableReturn(@QueryParameter String value) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why are we investing time in improving a method that shouldn't be used?:

@Restricted(DoNotUse.class)
This type, field, or method shall never be referenced from anywhere at all.

Copy link
Contributor

Choose a reason for hiding this comment

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

FTR the @Restricted(DoNotUse.class) is meant for Jelly calls. It's a method that is called by Stapler, detected using reflection during the form build process.

Copy link
Contributor

Choose a reason for hiding this comment

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

Are you sure? I think it's used to warn programmers

Copy link
Member

Choose a reason for hiding this comment

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

@daniel-beck daniel-beck added the plugin-api-changes Changes the API of Jenkins available for use in plugins. label Oct 11, 2019
@MRamonLeon
Copy link
Contributor

Although the improvements are good, my feeling is that we don't need to improve it because we are breaking the API and the methods shouldn't be used. So my proposal is to close this PR unless the API changes are reverted. Anyway, thanks Jsoref for your work.

@rsandell rsandell added the proposed-for-close There is no consensus about feasibility of this PR, and maintainers do not see a way forward for it label Mar 26, 2020
@varyvol
Copy link

varyvol commented Apr 16, 2020

I'm closing this given there's been no activity for some time. Please feel free to reopen if you plan to work on this again.

@varyvol varyvol closed this Apr 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
plugin-api-changes Changes the API of Jenkins available for use in plugins. proposed-for-close There is no consensus about feasibility of this PR, and maintainers do not see a way forward for it
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants