Ewelina, Nicolas, I'm jumping in because I don't see anyone mentioning who will be doing this.
As JEP-1 sponsor, I would like to remind you that part of your duties as sponsors of JEP-201 include different viewpoints and design suggestions in your JEP. (I'm jumping in because I don't see anyone mentioning who will be doing this.) Even if you choose not to use the suggestions, they need to be represented in the "Reasoning" section. Just as Jesse pulled this feedback to a discussion here so it wouldn't be lost in IRC, it will need to be distilled from this extended discussion to be added to the JEP. Here's two examples of "Reasoning" sections with significant content: https://github.com/jenkinsci/jep/tree/master/jep/1#reasoning https://github.com/jenkinsci/jep/tree/master/jep/200#reasoning It looks to me like there are at least three threads here: automatic symbol inference, YAML Map syntax and Credentials, and Replacing Job DSL Groovy syntax. There might also be a general list of features that have been deemed out-of-scope for the current release. You may ask Jesse if he'd be willing to submit PRs (adding to "Specification" or "Reasoning"), but ultimately it is your responsibility to make sure it happens. Thanks, -L. On Tuesday, April 17, 2018 at 11:31:30 PM UTC-7, Ewelina Wilkosz wrote: > > interesting discussion! > > I agree we can have a nicer way of configuring job, to keep the > consistency, but I also agree with Nicolas about not wanting to "re-invent > the wheel" - many users have their job dsls ready, so the transition may be > easier if they don't need to learn a new syntax, that was my motivation for > keeping job dsl. Alternative solution may exist next to job dsl support I > believe > > On Wednesday, April 18, 2018 at 6:53:58 AM UTC+2, nicolas de loof wrote: >> >> >> >> 2018-04-18 0:42 GMT+02:00 Jesse Glick <[email protected]>: >> >>> On Tue, Apr 17, 2018 at 4:45 PM, nicolas de loof >>> <[email protected]> wrote: >>> > Job class hierarchy is full of hand written JSON parsing >>> >>> I suspect such cases are fixable, which would take some work, but on >>> the other hand we would get a clearer code base as a result anyway. >>> >> >> Sure, but this will be for future version then >> We want JCasC to support current releases of Jenkins by Praqma customers >> (and others), not require bleeding edge Jenkins core. >> >> >>> >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr03rVj6r1tWfwYeO1QKeDMtDYjuc8fF0Se%2B4Rh9qbZFvg%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/80dad51b-9adb-4f23-8e2a-d6f41dabf45a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
