Active Choices: What will it take to return to Jenkins Update Center?

[Ioannis Moutsatsos]

Greetings to all;

In the recent BioUno hangout (June 30, 2017) we've discussed the possibility of removing the Active Choices dependency on Scriptler so that Active Choices can be removed from the Jenkins security blacklist.

We have now posted this idea for discussion on the Jenkins developer list.

https://groups.google.com/forum/#!topic/jenkinsci-dev/T5LetkdQjHs

Please, feel free to review and discuss the ideas presented there.

Best regards

Ioannis

[Bruno P. Kinoshita]

Thanks for doing that Ioannis.

I think Jesse's suggestion points at the easiest solution, having two plug-ins.

- active-choices-plugin

- active-choices-scriptler-integration - not really a plug-in per se. Depends on the main plugin, and adds scriptler params

Then maybe later we can follow the pattern and release active-choices-database-integration, active-choices-r-integration, active-choices-templates, and so on.

Trying to keep the core to a minimum, so that it's not blacklisted again.

Doesn't sound so hard to implement, might be able to pull it together in a few days.

Cheers

Bruno

---

--
You received this message because you are subscribed to the Google Groups "BioUno Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to biouno-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ioannis Moutsatsos]

Glad that Jesse's reply can be an inspiration for a solution! I was not sure what he meant but I was sure his reply would be better understood by you:-)

Do we have any other examples of such a plugin structure? Where there is a main plugin and a bunch of auxiliary ones?

It would be good to know.

Best regards

Ioannis

[Bruno P. Kinoshita]

I am quite sure I've seen this before... but can't recall which plug-in... Looking at github.com/jenkinsci I might remember which plug-in it was.

The issue right now is that if we cut out the scriptler part, and release the plug-in, next time users load their jobs they may get some nasty errors. Jenkins would have an XML file that could contain scriptler entries.

Trying to deserialize that would make Jenkins a bit unhappy.

A better approach would be to release 1.5.4 and have scriptler security issue fixed. And then split it and tell users to update to 1.6 and install the extra plug-in if they intend to use scriptler...

Cheers

Bruno

---

On Thursday, 6 July 2017, 10:30:30 PM NZST, Ioannis Moutsatsos <imout...@gmail.com> wrote:

Glad that Jesse's reply can be an inspiration for a solution! I was not sure what he meant but I was sure his reply would be better understood by you:-)

Do we have any other examples of such a plugin structure? Where there is a main plugin and a bunch of auxiliary ones?

It would be good to know.

Best regards

Ioannis

On Wednesday, July 5, 2017 at 5:51:27 PM UTC-4, Bruno Kinoshita wrote:

Thanks for doing that Ioannis.

I think Jesse's suggestion points at the easiest solution, having two plug-ins.

- active-choices-plugin

- active-choices-scriptler- integration - not really a plug-in per se. Depends on the main plugin, and adds scriptler params

Then maybe later we can follow the pattern and release active-choices-database- integration, active-choices-r-integration, active-choices-templates, and so on.

Trying to keep the core to a minimum, so that it's not blacklisted again.

Doesn't sound so hard to implement, might be able to pull it together in a few days.

Cheers

Bruno

[Ioannis Moutsatsos]

Hmm... Why can't we adopt Occam's Razor principle? 

How difficult is it for Active Choices to detect the presence of an installed plugin (like scriptler) and only install the scriptler (or the R or the database or etc) option then? To me that's the simplest of all options (but not necessarily from implementation standpoint). So deferring to you Bruno.

Now that you explain what would happen if we were to split the plugin to 2 I'm concerned.

Best regards

Ioannis

[Bruno P. Kinoshita]

If it were Python, PHP, perhaps it would be easier. In Java, unless we had adopted something like a ServiceLocator, or some other strategy to separate the code and allow us to change implementations, I don't see how else we could do it right now... not in any clean way.

Will continue thinking about how to fix it... the easiest solution now became Jesse's suggestion I believe :)

Cheers

Bruno

---

[Lionel Orellana]

It reminds me of the Pipeline Plugin which is split into a number of actual plugins.