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 <[email protected]> >> 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 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/CAKqW32CZrBjYO26HUiPLVSfxfOCynp7LHpg3H28woSfD_k08cw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
