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] 
> <javascript:>> 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] 
>> <javascript:>> 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] <javascript:>> 
>> 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] <javascript:>.
>> 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] <javascript:>.
>> 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/06a99dd9-f4d9-4061-b20c-e46609921c86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to