Plugin Hosting Request: job-dsl-promotions-plugin

[Dennis Schulte]

Hello,

I would like to add our plugin to the Jenkins plugin list. 

• URL: https://github.com/codecentric/job-dsl-promotions-plugin
• plugin name:  job-dsl-promotions-plugin
  
• github name: denschu
• jenkins-ci.org UserName: denschu
  
• description: This plugin is an extension for the existing Job DSL Plugin. With this extension it is possible to generate promotions with the Job DSL. See the Promoted Builds Plugin for further informations about the meaning of Promotions for a Jenkins Job.
  

Thank you and Best Regards

Dennis

[Kanstantsin Shautsou]

Sorry, i don't see any reason for having it as separate plugin, if promoted build implements job dsl extension, then put this code into promoted-builds plugin. Or we may end with 1k dsl plugins for 1k plugins.

[Kirill Merkushev]

yep, why not to pr this to original plugin? It can be in separate package and have optional dependency 

понедельник, 3 августа 2015 г., 10:01:03 UTC+3 пользователь Dennis Schulte написал:

[Kanstantsin Shautsou]

On Aug 4, 2015, at 00:07, Kirill Merkushev <twil...@gmail.com> wrote:

yep, why not to pr this to original plugin? It can be in separate package and have optional dependency 

Kirill mean @Extension(optional = true) and optional dependency on job-dsl-plugin so you will have classes during compiling.

понедельник, 3 августа 2015 г., 10:01:03 UTC+3 пользователь Dennis Schulte написал:

Hello,

I would like to add our plugin to the Jenkins plugin list. 

• URL: https://github.com/codecentric/job-dsl-promotions-plugin
• plugin name:  job-dsl-promotions-plugin
  
• github name: denschu
• jenkins-ci.org UserName: denschu
  
• description: This plugin is an extension for the existing Job DSL Plugin. With this extension it is possible to generate promotions with the Job DSL. See the Promoted Builds Plugin for further informations about the meaning of Promotions for a Jenkins Job.
  

Thank you and Best Regards

Dennis

--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4d221649-0665-49bb-96b0-eefb7500b6b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dennis Schulte]

Mh, ok, I can create a PR for the original plugin, but most of the DSL plugins are written in Groovy (like this one) and this would mean, that we add Groovy to those plugins. Is that the designated way? From my point of view there will be not 1k dsl plugins, because most of the stuff is already included in the Job DSL Plugin and only more complex will be separated in extensions. Another option would be that the DSL plugin extension must be written in Java, when the original plugin is also Java, which would be the 99% case.

Thanks

Dennis

[Richard Bywater]

Personally I think its fine to have Java & Groovy co-exist together. That's the/a reason behind the directory convention of src/main/java / src/main/groovy right?

Richard.

--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/16a2df29-c855-45bb-b9e7-de7b092bc3d7%40googlegroups.com.

[Kanstantsin Shautsou]

Just put your sources in src/main/groovy/

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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMui946-_ttvjgAYM5Ad37HkjoDUM3wqydGfdKBkrMVwv9DB6w%40mail.gmail.com.

[Dennis Schulte]

Mh,  src/main/groovy is not enough. There are a lot of plugins I have to configure in the pom.xml/build.gradle and the IDE-support is actually not very stable. I guess that my pull request will be rejected by the Promoted Build Plugin team, because my code contains Groovy ;-) I will ask them before I invest a lot of work in it....

Am Montag, 3. August 2015 09:01:03 UTC+2 schrieb Dennis Schulte:

[Kanstantsin Shautsou]

cut out your gradle and everything should work out of the box.

--
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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e6946a1a-a207-4bc4-8fc2-b42021b996f3%40googlegroups.com.

[Daniel Spilker]

Picking up the discussion from https://issues.jenkins-ci.org/browse/JENKINS-21750. I want to avoid that the job-dsl-promotions-plugin gets released outside of the Update Center. That's only a short-term solution.

The Promoted Builds Plugin does not seem to have a maintainer, but please correct me if I'm wrong. So if anyone does not agree to add Groovy code to the Promoted Builds Plugin, please reply and explain. Otherwise I suggest that Dennis opens a pull request to add the Job DSL extension to the Promoted Builds Plugin and gets commit access if necessary.

@Dennis: The plugin parent POM should contain most things necessary to compile Groovy code. I wanted to point you to https://github.com/jenkinsci/hello-world-groovy-plugin, but that seems outdated.

Daniel

--

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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/672AFF66-3334-44B4-B46D-719905104EEF%40gmail.com.

[Oleg Nenashev]

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

пятница, 25 сентября 2015 г., 11:20:46 UTC+3 пользователь Daniel Spilker написал:

[Damien]

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.

[Stephen Connolly]

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

--
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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAAe5jyNwkCaURREs3WAbpeFk8QHHgct7UvUAnEby-EVBXF7DGA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
Sent from my phone

[Oleg Nenashev]

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?

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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwpJ0Rb6bcSeZqb%2B92uXoBQCnuo8dsoKqP%2BtejTCCYYDQ%40mail.gmail.com.

[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.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6AA7F6BE-3E4C-4038-A8BD-A7EFD4F03151%40gmail.com.

[Dennis Schulte]

Thanks Daniel :-) 

I will not start with the implemtation until we are clear here. Ok, could it maybe a solution to create a complete separate plugin like in this request proposed? In this case we have not a problem with Groovy code in the Promoted Builds Plugin and Daniel has no compatiblity problems in the Job DSL Plugin.

Best Regards

Dennis

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 <o.v.ne...@gmail.com> 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 <stephen.al...@gmail.com> 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 <damien...@gmail.com> 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 <o.v.ne...@gmail.com> 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 jenkinsci-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAAe5jyNwkCaURREs3WAbpeFk8QHHgct7UvUAnEby-EVBXF7DGA%40mail.gmail.com.
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwpJ0Rb6bcSeZqb%2B92uXoBQCnuo8dsoKqP%2BtejTCCYYDQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Stefan Wolf]

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 <o.v.ne...@gmail.com> 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 <stephen.al...@gmail.com> 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 <damien...@gmail.com> 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 jenkinsci-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAAe5jyNwkCaURREs3WAbpeFk8QHHgct7UvUAnEby-EVBXF7DGA%40mail.gmail.com.
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwpJ0Rb6bcSeZqb%2B92uXoBQCnuo8dsoKqP%2BtejTCCYYDQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Victor Martinez]

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

[Oleg Nenashev]

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

Cheers

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAAe5jyNwkCaURREs3WAbpeFk8QHHgct7UvUAnEby-EVBXF7DGA%40mail.gmail.com.
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwpJ0Rb6bcSeZqb%2B92uXoBQCnuo8dsoKqP%2BtejTCCYYDQ%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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6AA7F6BE-3E4C-4038-A8BD-A7EFD4F03151%40gmail.com.

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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/08b8b6af-2e25-469c-b56a-032f2e468c72%40googlegroups.com.

[Dennis Schulte]

Mh, I'm not sure if we have a consensus ;-) Another option would be that I convert the job-promotions-dsl-extension from Groovy to Java so it's more easy to integrate the code into the Promoted Builds Plugin, but in the end I don't want to waste time. 

Another point is: Do we really have so many other DSL Extensions? Does it really make sense to separate those few extensions? The Job DSL Plugin is a complete solution which works out of the box very fine. If we distribute the DSL code into the plugins, e.g. Promoted Builds Plugin, we get maybe more and more compatibility issues.

Regards

Dennis

Cheers

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAAe5jyNwkCaURREs3WAbpeFk8QHHgct7UvUAnEby-EVBXF7DGA%40mail.gmail.com.
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwpJ0Rb6bcSeZqb%2B92uXoBQCnuo8dsoKqP%2BtejTCCYYDQ%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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6AA7F6BE-3E4C-4038-A8BD-A7EFD4F03151%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Stephen Connolly]

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

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.

[Daniel Beck]

On 29.09.2015, at 14:20, Stephen Connolly <stephen.al...@gmail.com> wrote:

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

Wouldn't that dependency be optional anyway?

[Stephen Connolly]

to quote Jesse: "optional dependencies must die"

> --
> 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 jenkinsci-de...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F102D219-20B7-47A2-9882-DEAA572D6DB8%40beckweb.net.

[Kanstantsin Shautsou]

Optional dependencies works fine for many years in linux distros. What is the problem in jenkins?
Redundant hard deps should also die.

PS bottom-quote on top-quote is bad manner.

> 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 jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwq%3Dvis9A8PsKzVvxwQEDUuEbhNzHfEkwnqU_7YXgNHFw%40mail.gmail.com.

[Stephen Connolly]

Java dependencies are not the same as Linux package dependencies

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/B88B0980-815D-468F-9823-788F4DD8C7FE%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
Sent from my phone

[Kanstantsin Shautsou]

Statement is right, but has no any clarification rather then “must die". Jenkins already supports loading plugins and allows doing optional dependencies.

Could you provide any real reason to not use optional dependency in this case?

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxXb_BrU3%3DdsR97mQ-5TEQ8%2B8ox0VrwAV%2BKZgSdSpVQcg%40mail.gmail.com.

[Oleg Nenashev]

Just to clarify...
As a maintainer of promoted-builds-plugin, I'm OK with an optional dependency.
There is already a dependency on the token-macro with a similar security flaw, so I don't see any practical reason to keep the integration code in a separate plugin if it is tested enough.

среда, 30 сентября 2015 г., 2:01:16 UTC+3 пользователь Kanstantsin Shautsou написал:

Statement is right, but has no any clarification rather then “must die". Jenkins already supports loading plugins and allows doing optional dependencies.

Could you provide any real reason to not use optional dependency in this case?

On Sep 30, 2015, at 01:46, Stephen Connolly <stephen.al...@gmail.com> wrote:

Java dependencies are not the same as Linux package dependencies

On Tuesday 29 September 2015, Kanstantsin Shautsou <kanstan...@gmail.com> wrote:

Optional dependencies works fine for many years in linux distros. What is the problem in jenkins?
Redundant hard deps should also die.

PS bottom-quote on top-quote is bad manner.

> On Sep 29, 2015, at 18:21, Stephen Connolly <stephen.alan.connolly@gmail.com> wrote:
>
> to quote Jesse: "optional dependencies must die"
>
> On 29 September 2015 at 13:47, Daniel Beck <m...@beckweb.net> wrote:
>>
>> On 29.09.2015, at 14:20, Stephen Connolly <stephen.alan.connolly@gmail.com> wrote:
>>
>>> Please do not add a dependency on job-DSL to promoted-builds (at least until job-dsl has fixed the security design issues)
>>
>> Wouldn't that dependency be optional anyway?
>>
>> --
>> 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 jenkinsci-dev+unsubscribe@googlegroups.com.

>> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F102D219-20B7-47A2-9882-DEAA572D6DB8%40beckweb.net.
>> 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 jenkinsci-dev+unsubscribe@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwq%3Dvis9A8PsKzVvxwQEDUuEbhNzHfEkwnqU_7YXgNHFw%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 jenkinsci-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/B88B0980-815D-468F-9823-788F4DD8C7FE%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Ferenc Kovacs]

hi,

any update on this? (sorry all of the open jira issues about the jobdsl <-> promoted builds integration seems to have way less activity than this thread.)

[Dennis Schulte]

Hello, I'm actually working on it. The first step was the migration of the Job DSL Promotions Plugin to Java (see https://github.com/codecentric/job-dsl-promotions-plugin). In the next days I will create a PR for the Promoted Builds Plugin....

Best Regards

Dennis

[Dennis Schulte]

Hi guys,

after some trouble with the complexity of the plugin I finally managed it to create a PR which integrates the Job DSL extension directly into the promoted-builds-plugin: https://github.com/jenkinsci/promoted-builds-plugin/pull/81

It would be great if Oleg could review the PR and merge the code to create a new release of the plugin :-)

Thanks in advance

Dennis

[Oleg Nenashev]

Hi Dennis,

I'll try to review it on this weekend.

BR, Oleg

Dennis

hi,

> On Sep 29, 2015, at 18:21, Stephen Connolly <stephen.al...@gmail.com> wrote:
>
> to quote Jesse: "optional dependencies must die"
>
> On 29 September 2015 at 13:47, Daniel Beck <m...@beckweb.net> wrote:
>>
>> On 29.09.2015, at 14:20, Stephen Connolly <stephen.al...@gmail.com> wrote:
>>
>>> Please do not add a dependency on job-DSL to promoted-builds (at least until job-dsl has fixed the security design issues)
>>
>> Wouldn't that dependency be optional anyway?
>>
>> --
>> 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 jenkinsci-de...@googlegroups.com.

>> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F102D219-20B7-47A2-9882-DEAA572D6DB8%40beckweb.net.
>> 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 jenkinsci-de...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwq%3Dvis9A8PsKzVvxwQEDUuEbhNzHfEkwnqU_7YXgNHFw%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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/B88B0980-815D-468F-9823-788F4DD8C7FE%40gmail.com.
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxXb_BrU3%3DdsR97mQ-5TEQ8%2B8ox0VrwAV%2BKZgSdSpVQcg%40mail.gmail.com.
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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/598b7005-9a4b-464c-aad8-ff251959fb7b%40googlegroups.com.