Seems we have a consensus that the best way is to update the Promoted Builds plugin. Feel free to create a pull request to to the plugin, let's see how to integrate it.
Workflow & JobDSL: Yes, they should be integrated somehow, but it's definitely out of the scope of this change :) > have not seen how Workflow provides unit testing yet It provides a testing opportunity, but I would not call it a separate "framework". E.g. https://github.com/jenkinsci/htmlpublisher-plugin/blob/master/src/test/java/htmlpublisher/workflow/PublishHTMLStepTest.java#L170-L187 2015-09-29 9:17 GMT+03:00 Victor Martinez <[email protected]>: > I've been thinking about this for the last few weeks and I strongly > believe both plugins should converge somehow. I have not seen how Workflow > provides unit testing yet, and likely when it will provide that kind of > framework as part of its process it will be similar to the one JobDSL > already provides. I'm not sure right now whether this is the right thread, > but since you already pointed out that, I thought it was a good moment to > say my ideas. > > Cheers > > > On Tuesday, 29 September 2015 06:51:32 UTC+2, Stefan Wolf wrote: >> >> Hi, >> >> I think that plugins should host there own DSL using the job-dsl-plugin >> extension point. Daniel already gave some good reasons. >> I would like to compare the job-dsl-plugin to the workflow plugin. Here >> the "DSL" is also hosted by other plugins and not centralized in the >> workflow plugin. Since both plugins have basically the same need - >> configure parts of a plugin in form of a DSL - I even think there could be >> the possibility to use the same DSL for both. If we could manage to do this >> then also the workflow plugin would become much more usable in my opinion. >> In order to write the DSL extension itself, no groovy is required. See >> for example >> https://github.com/jenkinsci/jgiven-plugin/blob/master/src/main/java/org/jenkinsci/plugins/jgiven/JgivenDslContextExtension.java >> >> Best regards, >> Stefan >> >> Am Montag, 28. September 2015 12:44:04 UTC+2 schrieb Daniel Spilker: >>> >>> I don't like that option. The optional dependencies have been added >>> before the extension point was available. They will be kept for >>> compatibility, but any new DSL features which require more logic than >>> simply generating a config.xml should be implemented through the extension >>> point. Otherwise the Job DSL plugin will end up with dozens of optional >>> dependencies for all plugins which require extra configuration and relying >>> on API which might not be considered as public and stable API by the plugin >>> maintainers because it was not intended to be used by something like the >>> Job DSL plugin. And I don't want to spend time with tracking API changes >>> from plugins. I'm maintaining the Job DSL plugin for some month now and >>> there have been plugins which changed the on-disk config.xml format >>> (accidentially and not, e.g. JENKINS-26561 and JENKINS-29678). And that >>> broke the Job DSL plugin from a user perspective. I expect that API-level >>> changes happen more often because plugin developers are aware to keep the >>> on-disk config stable, but do not expect that "internal" plugin classes are >>> used from the outside (e.g. JENKINS-30013). The Job DSL plugin on the other >>> hand offers a stable extension point for all plugins to contribute DSL >>> features designed for that very specific reason. >>> >>> If this boils down to having Groovy code or not in a plugin, the >>> decision is up the the plugin's maintainers. Groovy code is as testable and >>> maintainable as Java code if done right. You can use JUnit to test Groovy >>> classes, you do not have to use Groovy frameworks like Spock. And you can >>> use CodeNarc for static code analysis. >>> >>> The Job DSL extension point can be implemented in Java or Groovy. I >>> expected a discussion like this and avoided any Groovy dependencies when >>> designing the extension point API. >>> >>> I just want to make sure that we send a clear signal to Dennis before he >>> creates a pull request that has little or no chance to get merged. >>> >>> >>> >>> On Sun, Sep 27, 2015 at 10:39 AM, Oleg Nenashev <[email protected]> >>> wrote: >>> >>>> Yes, it ay be the best option, because Job DSL plugin already >>>> optionally depends on 4 plugins due to the same reason. >>>> Daniel (Spilker), WDYT? >>>> >>>> >>>> On 27 Sep 2015, at 10:17, Stephen Connolly <[email protected]> >>>> wrote: >>>> >>>> Why can't he optional dep not be inverted and just have job-dsl >>>> optionally depend on promoted builds. >>>> >>>> Would seem to me that promotion is the more "core" functionality than >>>> job-dsl so the onus should be on job-dsl to add support for promoted builds >>>> rather than the other way. >>>> >>>> In any case I see nothing wrong with having this as a separate plugin >>>> either >>>> >>>> On Sunday 27 September 2015, Damien <[email protected]> wrote: >>>> >>>>> Hi All, >>>>> as Oleg mentioned, he is the current maintainer. As my current job >>>>> responsibilities does not involve using Jenkins as much, I don't have a >>>>> strong opinion what the direction is. Groovy or Java is irrelevant to me >>>>> as >>>>> long as a strong focus on maintainability and testability remains. >>>>> >>>>> good luck with the merge. >>>>> >>>>> On Sat, Sep 26, 2015 at 3:16 PM, Oleg Nenashev wrote: >>>>> >>>>>> The previous maintainer (Damien Nozay, in Cc) of Promoted Builds >>>>>> plugin granted me the persmissions to merge PRs and relelase . >>>>>> Technically >>>>>> I'm the current plugin's maintainer. >>>>>> >>>>>> I don't think that Groovy is a showstopper for integrating the >>>>>> functionality into Promoted Builds plugin. Personally I would prefer to >>>>>> have a Java-only code due to the maintenability & static analysis >>>>>> reasons, >>>>>> but I will accept Groovy-based pieces if they are tested enough and do >>>>>> not >>>>>> require a special build flow. >>>>>> >>>>>> Best regards, >>>>>> Oleg >>>>>> >>>>>> >>>>> -- >>>>> 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/CAAe5jyNwkCaURREs3WAbpeFk8QHHgct7UvUAnEby-EVBXF7DGA%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAAe5jyNwkCaURREs3WAbpeFk8QHHgct7UvUAnEby-EVBXF7DGA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> -- >>>> Sent from my phone >>>> >>>> -- >>>> 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/IZ3kBFhIYYg/unsubscribe >>>> . >>>> To unsubscribe from this group and all its topics, send an email to >>>> [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwpJ0Rb6bcSeZqb%2B92uXoBQCnuo8dsoKqP%2BtejTCCYYDQ%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwpJ0Rb6bcSeZqb%2B92uXoBQCnuo8dsoKqP%2BtejTCCYYDQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> 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/6AA7F6BE-3E4C-4038-A8BD-A7EFD4F03151%40gmail.com >>>> <https://groups.google.com/d/msgid/jenkinsci-dev/6AA7F6BE-3E4C-4038-A8BD-A7EFD4F03151%40gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- > 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/IZ3kBFhIYYg/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/08b8b6af-2e25-469c-b56a-032f2e468c72%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-dev/08b8b6af-2e25-469c-b56a-032f2e468c72%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > 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/CAPfivLD51KwNLwhrfu27EA%2B%2Btjg98G_ygDhRGikL8zRYK%3D0NJg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
