[Proposal] Making DataBound components more declarative

97 views
Skip to first unread message

nicolas de loof

unread,
Jun 7, 2018, 4:52:53 AM6/7/18
to jenkin...@googlegroups.com
Hi there

I've noticed most Jenkins components, when then don't parse json stream for UI data binding with human-written code, do only rely on a DataBoundConstructor with some @Nonnull annotation as sole definition of constraints on data (I don't even think Stapler will prevent passing null by the way).

Such constructor then has to invoke various Util.trimToNull / checkForNull / etc to convert and validate incoming data. As a result we don't expose a "model" that could benefit a better UI nor can be reused in another context (I have configuration-as-code in mind, but this would also be useful for Pipeline IIUC)

I suggest we embrace bean-validation (jsr-303) to declare model constraints, and as well offer some generic mechanisms so a maximum boiler-plate data filtering is managed by stappler based on declarative constraints.

For this purpose, I've implemented https://github.com/stapler/stapler/pull/140

This allows to write a DataBound component as :

public static class DataBoundBean {

@DataBound @Positive @Max(100)
private int x;

@DataBound @NotBlank
private String y;

@DataBound(trim = DataBound.Trim.TONULL)
private String z;
}

The equivalent DataBound class with current Stapler codebase would look like this : 

public static class DataBoundBean {

private int x;
private final String y;
private String z;

@DataBoundConstructor
public DataBoundBean(int x, @Nonnull String y, String z) {
if (x < 0 || x > 100) throw new IllegalArgumentException("x must be positive < 100");
if (StringUtils.isBlank(y)) throw new IllegalArgumentException("y can't be blank");
this.x = x;
this.y = y;
this.z = StringUtils.trimToNull(z);
}
}
(or alternatively use DataBoundSetters and a @PostConstruct method for conversion/validation)

What do you think about this ?

Bruno P. Kinoshita

unread,
Jun 7, 2018, 5:37:22 AM6/7/18
to jenkin...@googlegroups.com
The code looks much nicer, and developers probably will have already used jsr-303 in some project.

Had a brief look at the code and it looks good (minor nit-pick for the @author tag in one of the files, maybe drop it or replace kohsuke by your user?).

Would it also work if a plugin developer tried to implement a custom ConstraintValidator?


+1

Thanks
Bruno




________________________________
From: nicolas de loof <nicolas...@gmail.com>
To: jenkin...@googlegroups.com
Sent: Thursday, 7 June 2018 8:52 PM
Subject: [Proposal] Making DataBound components more declarative
--
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-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzkhxCcspfcNxZJTwcw%3Dg1QcmEz9n9k4homP6rXvaqYSNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

nicolas de loof

unread,
Jun 7, 2018, 5:48:11 AM6/7/18
to jenkin...@googlegroups.com
2018-06-07 11:37 GMT+02:00 'Bruno P. Kinoshita' via Jenkins Developers <jenkin...@googlegroups.com>:
The code looks much nicer, and developers probably will have already used jsr-303 in some project.

Had  a brief look at the code and it looks good (minor nit-pick for the @author tag in one of the files, maybe drop it or replace kohsuke by your user?).
good catch 

Would it also work if a plugin developer tried to implement a custom ConstraintValidator?

yes indeed. this is plain JSR 303 reference implementation used internally 
 
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1172002936.1614566.1528364231154%40mail.yahoo.com.

Oleg Nenashev

unread,
Jun 7, 2018, 7:06:13 AM6/7/18
to Jenkins Developers
Yes, such annotation would help a lot with our current issues in the code.
So +1 from me to implement it.

Some notes:
  • I would suggest a "required" attribute in @DataBound which defaults to true
  • I would recommend moving annotations to a separate library which we could include into plugins so that they do not require new core dependency to start putting annotations
    • New core will be still required to do binding from Web UI forms
    • Configuration-as-Code plugin and Pipeline can start using the annotations even on older cores
  • It would be great to add support of custom Validator classes within the annotation
  • It would be great to also define some conversion logic on the top level, so that classes can implement migration logic should the data model change (like readResolve)
    • Use-case: support old submissions when a field is removed (add field converter class or so)

BR, Oleg
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzkhxCcspfcNxZJTwcw%3Dg1QcmEz9n9k4homP6rXvaqYSNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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-de...@googlegroups.com.

nicolas de loof

unread,
Jun 7, 2018, 7:16:10 AM6/7/18
to jenkin...@googlegroups.com
2018-06-07 13:06 GMT+02:00 Oleg Nenashev <o.v.ne...@gmail.com>:
Yes, such annotation would help a lot with our current issues in the code.
So +1 from me to implement it.

Some notes:
  • I would suggest a "required" attribute in @DataBound which defaults to true
I also considered this, but wouldn't this be equivalent to jsr-303 annotation @NotNull ? Can do both anyway
  • I would recommend moving annotations to a separate library which we could include into plugins so that they do not require new core dependency to start putting annotations
    • New core will be still required to do binding from Web UI forms
    • Configuration-as-Code plugin and Pipeline can start using the annotations even on older cores
this is plain javax.validation API, so already a separate library
So you suggest plugin developer will mark fields with those annotations, without getting benefits for UI databinding ?
 
  • It would be great to add support of custom Validator classes within the annotation
Already the case, jsr-303 do support custom validators (http://www.captaindebug.com/2011/07/writng-jsr-303-custom-constraint_26.html)
  • It would be great to also define some conversion logic on the top level, so that classes can implement migration logic should the data model change (like readResolve)
    • Use-case: support old submissions when a field is removed (add field converter class or so)

Good point. This would be needed for Configuraiton-as-Code backward compatibility as well. I guess a @PostConstruct method would be fine for this purpose. just mark legacy field as (transient) @Deprecated, but keep @DataBound annotation so that binding still happens.
 
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8c888e0f-7fdc-4712-bc53-4ee66388a65e%40googlegroups.com.

Oleg Nenashev

unread,
Jun 7, 2018, 7:34:13 AM6/7/18
to JenkinsCI Developers

Some notes:
  • I would suggest a "required" attribute in @DataBound which defaults to true
I also considered this, but wouldn't this be equivalent to jsr-303 annotation @NotNull ? Can do both anyway

@NonNull makes no sense for primitive types, so they are quite orthogonal IMHO.
I would rather add "required" and maybe "defaultValue" annotations similarly to what Jackson databind and args4j do in Jenkins.

  • I would recommend moving annotations to a separate library which we could include into plugins so that they do not require new core dependency to start putting annotations
    • New core will be still required to do binding from Web UI forms
    • Configuration-as-Code plugin and Pipeline can start using the annotations even on older cores
this is plain javax.validation API, so already a separate library
So you suggest plugin developer will mark fields with those annotations, without getting benefits for UI databinding ?

BR, Oleg







--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/Bb4pIdpMMIY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJznpvHuQaE%2BODejhrv5H1OuzJVM26piimBirDn9j2bsf-A%40mail.gmail.com.

Baptiste Mathus

unread,
Jun 7, 2018, 8:21:23 AM6/7/18
to Jenkins Developers
All for this. Great idea and initiative Nicolas!

nicolas de loof

unread,
Jun 7, 2018, 8:26:14 AM6/7/18
to jenkin...@googlegroups.com
Got it, implemented as https://github.com/stapler/stapler/pull/140/commits/60945d14fe3da876ce5bd7da699e78f6062e8447

As a result, my initial sample would now look like :

public static class DataBoundBean {

@DataBound(required = true) @Positive
    private int x;

@DataBound @NotBlank
private String y;

    @DataBound @Trim
private String z;




James Nord

unread,
Jun 7, 2018, 9:23:28 AM6/7/18
to Jenkins Developers

I didn't look at the implementation but IMO the annotations must go on the setters (or parameters) and not on private fields, and then the checks need to be done on the setters or (injected into the constructor)

Why?

Because things other than DataBinding create these objects (ie calling the API directly from another piece of code).  and if I can vilaote a requirement from code that would cause the UI or stapler to fail a round trip then that is a bad bug.

Also the public setters are documented as part of the javadoc but private fields are not, and as such the annotaions if defined on something public would then also be documented.
Tied to this I was wondering how this ties in the any doCheckXYZ() methods?  does it need to be repeated will they be generated for formbinding?

but +100 for writing less code.
Regards

/James

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/Bb4pIdpMMIY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

--
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-de...@googlegroups.com.

nicolas de loof

unread,
Jun 7, 2018, 9:59:08 AM6/7/18
to jenkin...@googlegroups.com
2018-06-07 15:23 GMT+02:00 James Nord <jn...@cloudbees.com>:

I didn't look at the implementation but IMO the annotations must go on the setters (or parameters) and not on private fields, and then the checks need to be done on the setters or (injected into the constructor)

Why?

Because things other than DataBinding create these objects (ie calling the API directly from another piece of code).  and if I can vilaote a requirement from code that would cause the UI or stapler to fail a round trip then that is a bad bug.

so the question : is this a good thing to have "another piece of code" create a DataBound object ? Do you have any legitimate use case in mind ?
What you call "API" is just a public class within many because java don't let us do it any other way. Do we really want anything public to be considered "an API" ? (yes I know about @Restricted. Just would like this to be the default)

Another way to ask : Do you think JAX-B and JPA are all wrong in their design using field annotations ? 
I remember I had this exact debate with Hibernate-annotation folks some years ago, unfortunately can't remember the reasoning. Sounds to me some endless debate with various valuable argument on both sides.

So, some option I can offer :
  • allow this annotation both on fields and methods, just like JPA does.
  • make @DataBound a class level annotation, all fields (and setters) would then be considered for databinding (same as JPA's @Entity). DataBound would then imply a @Restricted annotation, to ensure nobody does bad things with this code.

Also the public setters are documented as part of the javadoc but private fields are not, and as such the annotaions if defined on something public would then also be documented.

So we have found this guy who read the doc :)
 
 
Tied to this I was wondering how this ties in the any doCheckXYZ() methods?  does it need to be repeated will they be generated for formbinding?

Part of this effort I've considered the jelly tags could be enhanced to integrate client side validation for comparable rules. Afaik the doCheck methods are mostly used to validate a parameter is valid within a specific context (like credentialsId), not to check they follow some formal design. But with custom jsr-330 annotation one could probably implement an alternative to doCheck methods. Not sure this would be a better design but feasible afaict
 
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/99356e40-a6ab-483a-bcdc-ed25de0f0db0%40googlegroups.com.

nicolas de loof

unread,
Jun 7, 2018, 10:59:53 AM6/7/18
to jenkin...@googlegroups.com
2018-06-07 15:58 GMT+02:00 nicolas de loof <nicolas...@gmail.com>:


2018-06-07 15:23 GMT+02:00 James Nord <jn...@cloudbees.com>:

I didn't look at the implementation but IMO the annotations must go on the setters (or parameters) and not on private fields, and then the checks need to be done on the setters or (injected into the constructor)

Why?

Because things other than DataBinding create these objects (ie calling the API directly from another piece of code).  and if I can vilaote a requirement from code that would cause the UI or stapler to fail a round trip then that is a bad bug.

so the question : is this a good thing to have "another piece of code" create a DataBound object ? Do you have any legitimate use case in mind ?
What you call "API" is just a public class within many because java don't let us do it any other way. Do we really want anything public to be considered "an API" ? (yes I know about @Restricted. Just would like this to be the default)

Another way to ask : Do you think JAX-B and JPA are all wrong in their design using field annotations ? 
I remember I had this exact debate with Hibernate-annotation folks some years ago, unfortunately can't remember the reasoning. Sounds to me some endless debate with various valuable argument on both sides.

So, some option I can offer :
  • allow this annotation both on fields and methods, just like JPA does.


previous sample can be implemented when one prefer setters annotations as  :

public static class DataBoundBean {

@DataBound(required = true) @Positive
private int x;

@DataBound @NotBlank
private String y;

    private String z;

@DataBound @Trim
public void setZ(String z) {
this.z = z;
}

nicolas de loof

unread,
Jun 7, 2018, 11:24:57 AM6/7/18
to jenkin...@googlegroups.com
b905c1fc allows use of @DataBound at class level, comparable to JPA's @Entity, also introducing @Required annotation

so you can use :

@DataBound
public static class DataBoundBean {

@Required @Positive
private int x;

@NotBlank
private String y;

@Trim
private String z;

which automatically makes the class @Restricted and excluded from any "API", considering such a class only is public to allow web UI data binding framework constraints

or if you want finer grain control :

public static class ValidatedBean {

@DataBound @Required @Positive
    private int x;

@DataBound @NotBlank
private String y;

private String z;

@DataBound @Trim
public void setZ(String z) {
this.z = z;
}

with support both for field and setter based injection

Matt Sicker

unread,
Jun 7, 2018, 11:45:14 AM6/7/18
to jenkin...@googlegroups.com
I like the idea, but could it be more focused on annotating public members? Java 9+ discourages things like setAccessible() for reflection nonsense like this. I'd prefer to annotate the constructor and/or methods only. Or public fields I suppose, but why use those?

As for annotations for validations, since Java doesn't support higher kinded types, I think that's a nice compromise. Ideally the types themselves could enforce the constraints, but that's more of an academic topic still.


For more options, visit https://groups.google.com/d/optout.



--
Matt Sicker
Software Engineer, CloudBees

Liam Newman

unread,
Jun 7, 2018, 12:12:12 PM6/7/18
to Jenkins Developers
This looks really cool.  Seems like there's also some interesting feedback on this. 

I'll look forward to seeing the resulting JEP for this.  

--
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-de...@googlegroups.com.

nicolas de loof

unread,
Jun 7, 2018, 12:28:37 PM6/7/18
to jenkin...@googlegroups.com
2018-06-07 17:45 GMT+02:00 Matt Sicker <msi...@cloudbees.com>:
I like the idea, but could it be more focused on annotating public members? Java 9+ discourages things like setAccessible() for reflection nonsense like this. I'd prefer to annotate the constructor and/or methods only. Or public fields I suppose, but why use those?

Both are supported
Java 9 discourage setAccessible() but also provide a (better?) mechanism with variable handles. We probably could rely on this (need more investigations)
 

Matt Sicker

unread,
Jun 7, 2018, 12:32:53 PM6/7/18
to jenkin...@googlegroups.com
I haven't looked at var handles in a while, but from what I recall, those are replacements for using Unsafe.compareAndSet along with the other ops there. Personally, I try to use AtomicReference instead where possible, but that's not always the best way to go about implementing atomic operations (hence VarHandle).


For more options, visit https://groups.google.com/d/optout.

Keith Zantow

unread,
Jun 7, 2018, 1:11:49 PM6/7/18
to jenkin...@googlegroups.com
Sorry to be the dissonant here, but @PostConstruct is invaluable/necessary in certain contexts, so use it!

--
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+unsubscribe@googlegroups.com.



--

Keith Zantow
Senior Software Engineer
CloudBees, Inc.

CloudBees-Logo.png


E: kza...@cloudbees.com

Jesse Glick

unread,
Jun 7, 2018, 2:44:11 PM6/7/18
to Jenkins Dev
On Thu, Jun 7, 2018 at 9:58 AM, nicolas de loof
<nicolas...@gmail.com> wrote:
> Part of this effort I've considered the jelly tags could be enhanced to
> integrate client side validation for comparable rules.

Some controls _do_ have client-side validation already, though today
of course you must explicitly select that option in your
`config.jelly`. See for example `f:number` and CSS classes like
`INPUT.positive-number-required`. It would be nice if either client-
or server-side validation to match bean annotations were automatic.

Thinking a bit more broadly, it would be very helpful if we could
mechanically generate a basic form for a given bean just based on its
element structure and annotations. For example, last I checked the
Blue Ocean Pipeline editor hard-codes support for a bunch of `Step`s,
since the plugin code implementing the step only defines a
`config.jelly` and the B.O. UI cannot embed those controls in any way,
which means you are out of luck if your plugin is not in that special
list. While we could urge the maintainer of every plugin which defines
a `Step` to also define a B.O. view for its configuration, we could
get a lot more traction by having B.O. introspect the `Step`’s
parameters and their constraints and offer a way to configure each
automatically.

Really that is not so different from what we already need to do for
JEP-201 to offer good IDE completion schemas, static validation, and
the like; or what the static step reference

https://jenkins.io/doc/pipeline/steps/

does by ignoring `config.jelly` but paying attention to
`Descriptor.displayName` and `help*.html` files.

nicolas de loof

unread,
Jun 7, 2018, 2:54:21 PM6/7/18
to jenkin...@googlegroups.com
Your perfectly right, this experiment was initially driven by the need to "document" the UI binding model in some discoverable way for use in Configuration-as-Code (JEP-201). The fact it allows to reduce boiler-plate coding is a bonus (but a nice one). I've been frustrated with DataBound model for a while, but here I have good reasons to propose an alternative :D

I haven't yet explored jelly tag integration, but I expect using:
<f:entry field="foo">
would allow to discover many details about target attribute (or setter) then add adequate classes, or maybe even use specific input type (number, date, time, range, etc).

I also like your idea to dynamically generate a "default" config.jelly file for a DataBound component, sounds perfectly feasible.

--
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+unsubscribe@googlegroups.com.

James Nord

unread,
Jun 8, 2018, 9:32:46 AM6/8/18
to Jenkins Developers


On Thursday, June 7, 2018 at 2:59:08 PM UTC+1, nicolas de loof wrote:


2018-06-07 15:23 GMT+02:00 James Nord <jn...@cloudbees.com>:

I didn't look at the implementation but IMO the annotations must go on the setters (or parameters) and not on private fields, and then the checks need to be done on the setters or (injected into the constructor)

Why?

Because things other than DataBinding create these objects (ie calling the API directly from another piece of code).  and if I can vilaote a requirement from code that would cause the UI or stapler to fail a round trip then that is a bad bug.

so the question : is this a good thing to have "another piece of code" create a DataBound object ?

Why not?  Why should I not be able to programatically generate a collection of some things based on some runtime / environmental state in a plugin?

Do you have any legitimate use case in mind ?

several all in a proprietary code base you have access to :)

But also, unit tests (JenkinsRule), why should a unit test not fail with an error IllegalArgumentExcetion "MyClass.foo 10 > 4" if it tries to set a value greater than the allowed version?
 
What you call "API" is just a public class within many because java don't let us do it any other way. Do we really want anything public to be considered "an API" ? (yes I know about @Restricted. Just would like this to be the default)


That is what Jenkins project defines as an API as that is why we are stuck with not removing anything for the past 10 years ;0
 
Another way to ask : Do you think JAX-B and JPA are all wrong in their design using field annotations ? 

Well yes.  If the annotation is of interest to an external party then there is no excuse for not documenting it.  (the colum name etc are of interest to hiberante only and not code so setting a column name of bob on an field is fair game).
 
I remember I had this exact debate with Hibernate-annotation folks some years ago, unfortunately can't remember the reasoning. Sounds to me some endless debate with various valuable argument on both sides.

So, some option I can offer :
  • allow this annotation both on fields and methods, just like JPA does.
  • make @DataBound a class level annotation, all fields (and setters) would then be considered for databinding (same as JPA's @Entity). DataBound would then imply a @Restricted annotation, to ensure nobody does bad things with this code.

Also the public setters are documented as part of the javadoc but private fields are not, and as such the annotaions if defined on something public would then also be documented.

So we have found this guy who read the doc :)

I'm sure there are others but yes - I find it quicker to go to javadoc.jenkins.io and to read a formatted page than decipher raw HTML, or find the bits in an IDE.
 
 
 
Tied to this I was wondering how this ties in the any doCheckXYZ() methods?  does it need to be repeated will they be generated for formbinding?

Part of this effort I've considered the jelly tags could be enhanced to integrate client side validation for comparable rules. Afaik the doCheck methods are mostly used to validate a parameter is valid within a specific context (like credentialsId), not to check they follow some formal design.

They can be for anything you want :-)  (I think the JNLP port uses a do check to check the number is not negative, there is certainly something somewhere that does something like that)
 

nicolas de loof

unread,
Jun 8, 2018, 9:53:39 AM6/8/18
to jenkin...@googlegroups.com
2018-06-08 15:32 GMT+02:00 James Nord <jn...@cloudbees.com>:


On Thursday, June 7, 2018 at 2:59:08 PM UTC+1, nicolas de loof wrote:


2018-06-07 15:23 GMT+02:00 James Nord <jn...@cloudbees.com>:

I didn't look at the implementation but IMO the annotations must go on the setters (or parameters) and not on private fields, and then the checks need to be done on the setters or (injected into the constructor)

Why?

Because things other than DataBinding create these objects (ie calling the API directly from another piece of code).  and if I can vilaote a requirement from code that would cause the UI or stapler to fail a round trip then that is a bad bug.

so the question : is this a good thing to have "another piece of code" create a DataBound object ?

Why not?  Why should I not be able to programatically generate a collection of some things based on some runtime / environmental state in a plugin?

Do you have any legitimate use case in mind ?

several all in a proprietary code base you have access to :)

But also, unit tests (JenkinsRule), why should a unit test not fail with an error IllegalArgumentExcetion "MyClass.foo 10 > 4" if it tries to set a value greater than the allowed version?

ok, let's assume this use-case is legitimate then (feel free to send me a link in private to convince me).

Do those scenario you have in mind take care of invoking @PostConstruct method to fully replicate component lifecycle as handled by Stapler ? As a plugin developer defining a DataBound component, I may rely on this behaviour and never know some proprietary code is assuming my code can work without this extra step. 
And if you do so, can't you just run bean-validation the exact same way ?

Makes me wonder, as a more general consideration, if we could make Stapler a bit more generic and handle databinding from various text-based representation of data (json, xml, yaml) so we don't have to re-implement this in various ways from external components.


By the way, initial write up as a JEP proposal : https://github.com/jenkinsci/jep/pull/120/files

 
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/77220835-5b84-4902-b2d6-9faafa4086cf%40googlegroups.com.

Jesse Glick

unread,
Jun 8, 2018, 1:00:50 PM6/8/18
to Jenkins Dev
On Fri, Jun 8, 2018 at 9:53 AM, nicolas de loof
<nicolas...@gmail.com> wrote:
> Makes me wonder, as a more general consideration, if we could make Stapler a
> bit more generic and handle databinding from various text-based
> representation of data (json, xml, yaml) so we don't have to re-implement
> this in various ways from external components.

Well, Stapler is specifically a web app framework, so it makes sense
for it to implement just the databinding from JSON as supplied by
configuration form posts. The idea behind the `structs` plugin was to
define a broader set of operations on “structs” that could be used in
different contexts—initially Pipeline (binding `Step`s to Groovy
expressions) and `job-dsl`. Now if we need to do some structural
extensions to Stapler form binding, then for technical reasons (the
fact that Stapler is a library used by Jenkins core rather than the
other way around) it would be appropriate to define a lower-level
library that Stapler consumes and that `structs` can also use for part
of its implementation.

nicolas de loof

unread,
Jun 10, 2018, 4:51:18 AM6/10/18
to jenkin...@googlegroups.com
Not sure I get your point. Let's assume stapler do evolve to offer an equivalent for structs DataModel introspection, which it internally relies on to handle databinding. Can't structs plugin then just use this new API when adequate Jenkins-core version is used ? Or maybe do you want structs to be able to consume this lib without dependency on jenkins-core version being used ?
I think this would make sense, and could benefit Configuration-as-Code as well - too much stapler/structs code has been re-implemented there

off topic: 
This makes me wonder if we could define sort of a jenkins-centric implementation of multi-release jar so a plugin can provide code for jenkins version < x and automatically switch to alternate implementation if it runs on jenkins >= x. This require more complex maven project layout but I wonder this would make our life easier with version upgrades, without reading comments in codebase like "// can be remove once we upgrade to jenkins 2.xxx".

 

--
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+unsubscribe@googlegroups.com.

Jesse Glick

unread,
Jun 11, 2018, 6:11:41 PM6/11/18
to Jenkins Dev
On Sun, Jun 10, 2018 at 4:50 AM, nicolas de loof
<nicolas...@gmail.com> wrote:
> Let's assume stapler do evolve to offer an
> equivalent for structs DataModel introspection, which it internally relies
> on to handle databinding. Can't structs plugin then just use this new API
> when adequate Jenkins-core version is used?

Yes that is an option. In that case we might deprecate some APIs in
`structs` (perhaps all of it?) and direct callers to use Stapler APIs
directly instead.

> Or maybe do you want structs to
> be able to consume this lib without dependency on jenkins-core version being
> used?

I do not think that is necessary. You are talking about new feature
development, so we can pick any dependency version we like.

> This makes me wonder if we could define sort of a jenkins-centric
> implementation of multi-release jar so a plugin can provide code for jenkins
> version < x and automatically switch to alternate implementation if it runs
> on jenkins >= x.

-1. Essentials obsoletes this way of thinking.

nicolas de loof

unread,
Jun 11, 2018, 6:18:54 PM6/11/18
to jenkin...@googlegroups.com
Do you expect all installations to use Jenkins Essentials in near future ?
That being said I'm fine we first get this implemented this in stapler within only most recent jenkins-core release. 

 

--
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-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0R6t3MBzT%2B4rkf8AF4_1RsnWcyAowGRhWSaRoiBhjicg%40mail.gmail.com.

nicolas de loof

unread,
Jun 11, 2018, 6:22:19 PM6/11/18
to jenkin...@googlegroups.com

Ivan Fernandez Calvo

unread,
Jun 12, 2018, 1:53:20 PM6/12/18
to Jenkins Developers
+1000
Which jsr-303 implementation is planned to use?

nicolas de loof

unread,
Jun 12, 2018, 1:57:28 PM6/12/18
to jenkin...@googlegroups.com
I've been using hibernate-validator (2.0 reference implementation) but if there's reasons to not use this one I'm fine to switch

Le mar. 12 juin 2018 à 10:53, Ivan Fernandez Calvo <kuisat...@gmail.com> a écrit :
+1000
Which jsr-303 implementation is planned to use?

--
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-de...@googlegroups.com.

Liam Newman

unread,
Jun 12, 2018, 2:24:18 PM6/12/18
to Jenkins Developers
I've merged JEP-205: Declarative Data Binding as Draft.

nicolas de loof

unread,
Jun 12, 2018, 2:27:30 PM6/12/18
to jenkin...@googlegroups.com
thanks, I'll prepare a follow-up pull request to describe in more details reasoning and technical details

Reply all
Reply to author
Forward
0 new messages