Please do not add a dependency on job-DSL to promoted-builds (at least
until job-dsl has fixed the security design issues)

My favoured solution is the separate plugin

On Tuesday 29 September 2015, Oleg Nenashev <[email protected]> wrote:

> 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]
> <javascript:_e(%7B%7D,'cvml','[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]
>> <javascript:_e(%7B%7D,'cvml','jenkinsci-dev%[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]
> <javascript:_e(%7B%7D,'cvml','jenkinsci-dev%[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
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLD51KwNLwhrfu27EA%2B%2Btjg98G_ygDhRGikL8zRYK%3D0NJg%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 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/CA%2BnPnMxKuT%2Brou0DXg-LM2UhM%2B%3DcShTX3Tf%2Bs8z2xphOsVq4aw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to