On Wed, Apr 6, 2016 at 4:27 AM, Daniel Spilker <m...@daniel-spilker.com> wrote:
> My
> workaround is to add a dependency to the Structs plugin to any plugin using
> the @Symbol annotation.
That is by design, not a workaround.
> But that voids the decision to have a separate
> library for @Symbol
No, this was to allow the annotation to be used on core code.
> Having @Symbol for aliasing class names is a right step for building
> concise DSLs. Having aliases for parameter names would be nice to have as
> well. E.g. GerritTrigger uses parameter names like
> gerritBuildFailedCodeReviewValue, gerritBuildFailedVerifiedValue,
> gerritBuildStartedCodeReviewValue, etc, which is not very concise.
Yes, this would probably be useful.
There are also a number of cases where the parameter type is either
inconsistent between getter/field and setter, or is of an
inappropriate type, due to hackish Jelly tricks (such as use of
nonstandard controls) and/or `Descriptor.newInstance` overrides. See
JENKINS-26143 for an example. Rather than merely letting you pick a
different name, it might be more generally useful to have a way to
designate an alternate getter/setter with a scripting-friendly
signature. For example, `ChoiceParameterDefinition` could get
something like
@Exported
@Parameter(countermands="choices") // do not use String type from
@DataBoundConstructor
public List<String> getChoices() {
return choices;
}
@DataBoundSetter
public void setChoices(List<String> choices) {
this.choices = choices;
}
without touching the UI code.
> Plugin developers need to take greater care for compatibility. Following
> the hints on retaining backward compatibility will only solve the issue
> for XStream, but DSL scripts will break when removing a
> @DataBoundConstructor parameter or a @DataBoundSetter.
Yes. IIRC Andres Rodriguez was investigating adding a binary
compatibility checker to `plugin-pom` to help catch mistakes in Java
signatures generally, which would include unintentional breakages of
data-bound parameters.
> when planning to
> remove a parameter, a @DataBoundConstructor parameter should be converted to
> a @DataBoundSetter and that setter should be marked as @Deprecated.
Yes. In general, a `@DataBoundConstructor` parameter should be
converted to `@DataBoundSetter` whenever it has some reasonable
default value. Tips:
https://github.com/jenkinsci/workflow-plugin/blob/d9234cc89d6bf7245d0d1f71e96faf8d2ea99ee4/COMPATIBILITY.md#constructor-vs-setters
> The
> DescribableParameter API from the Structs plugin [5] should be able to tell
> that a parameter is deprecated.
Sure, this should be easy enough to add.
> Currently it seems to be a best practice to use @DataBoundConstructor
> parameters for everything.
No! That was the only option *historically*, before `@DataBoundSetter`
was introduced.
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3JHVSquvGTzQJdoH9eMCpV2z-r7KHQNR0POw0-_SbS9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
