yep... only now you are back to doing a shim plugin.... See... I told you there was no escape!
OTOH you now do not need to get the changes into core to release your module On 1 July 2014 13:20, Tom Fennelly <[email protected]> wrote: > Thanks Robert. Good point!! > > So maybe what we could do then is a cross between what I was referring to, > and "shim" plugin i.e. a "jenkins-icons" plugin that just depends on the > "jenkins-icons" module (in the same way as Jenkins core would depend on it) > and nothing more i.e. doesn't define any new tags etc. Then, have the > other plugins add the "jenkins-icons" plugin as a dependency plugin. That > would resolve that issue, right? > > > On 01/07/2014 13:11, Sandell, Robert wrote: > > Yes, that’s true, but a bit confusing. In the scenario where many > plugins are using the lib in a Jenkins core that doesn’t have it; the > plugin that loads first would dictate what version of the lib to use for > the other plugins, even though it is bundled in each plugin (unless they > use pluginFirstClassLoader), and that could cause confision/issues like the > once we have with guava today for example. > > But when the user upgrades to a core that has the lib then core will be > the one dictating what version of the lib to use. > > > > > > > > > > *Robert Sandell* > > Software Tools Engineer - SW Environment and Product Configuration > > Sony Mobile Communications > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Tom Fennelly > *Sent:* den 1 juli 2014 12:41 > *To:* [email protected] > *Subject:* Re: New Jelly tags - via Jenkins Core + Plugin "shim", or via > simple Java jar dependency ?? > > > > But wouldn't that be the case anyway if we defined the base tag in the > normal way inside Jenkins core i.e. plugins using the tag would need to > wait for a core update to get fixes on that tag? > > On 01/07/2014 09:19, Sandell, Robert wrote: > > If there is a bug in your little library that is fixed and released, all > plugins using it will probably have to update the dependency and release a > new version of the plugin, until it appears in core. > > If the library was a plugin all plugins would get the bugfix when the new > icon plugin version gets installed. > > > > > > > > > > *Robert Sandell* > > Software Tools Engineer - SW Environment and Product Configuration > > Sony Mobile Communications > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Tom Fennelly > *Sent:* den 1 juli 2014 00:33 > *To:* [email protected] > *Subject:* New Jelly tags - via Jenkins Core + Plugin "shim", or via > simple Java jar dependency ?? > > > > Hi. > > We're in the process of creating a new <icon> in the hope of allowing more > control over icons in the UI [1]. As part of that, we want to allow plugins > that adopt this new tag to remain backward compatible with older versions > of Jenkins. > > > > Up to now, the convention seems to have been that all core jelly taglibs > (forms etc) live in Jenkins core and plugins get them from there: > > > > > <https://lh5.googleusercontent.com/-bnwMqmtmK4I/U7HdvP9_azI/AAAAAAAABIg/9ZtjRLr_kQU/s1600/Screenshot+2014-06-30+22.54.39.png> > > Of course, this means that a given plugin has a dependency on a particular > version of Jenkins on which it is installed. For that reason, we talked > [1] about creating "shim" plugin. This would be a plugin that defines an > intermediate icon tag (maybe call it <icon-shim>) that has Jenkins version > switching code inside it i.e. > > > > if (jenkinsVersion >= 1.571) { > > // use new <l:icon> tag ... > > } else { > > // use display icon in traditional way (as <img>) > > } > > > > > > > <https://lh3.googleusercontent.com/-po0x1R8HUj0/U7HioP8dtXI/AAAAAAAABIw/wBNp2arHqD8/s1600/Screenshot+2014-06-30+23.09.04.png> > > This all seemed a bit clumsy/ugly/messy to me, requiring multiple icon > related tags... plugin release management for the shim plugin etc etc. So > I decided to try creating a simple <icon> taglib jar (i.e. not putting the > <icon> taglib in Jenkins Core). Then, Jenkins Core and whatever plugins > wish to upgrade (to using the new <icon> tag) simple add this new taglib as > a dependency, independently of each other. So long as the <icon> taglib > does not use anything in a newer release of Jenkins, then the plugin should > work all the way back down the Jenkins releases: > > > <https://lh6.googleusercontent.com/-OMgCDihqezQ/U7HjQ9oJoUI/AAAAAAAABI4/pVCDvV2M2TI/s1600/Screenshot+2014-06-30+23.09.17.png> > > I have some code here [2]. It works fine from a Jenkins Core perspective. > I'm going to change the Credentials plugin now and test that it works on > new and old versions of Jenkins. I'm fairly confident it will. The icon > taglib is currently in an "icon" module of the root the project. I know > that's probably not a good long-term location - if the idea sticks, we can > easily move it to a new home. > > So.... what's "wrong" with doing it this way Vs using a "shim" plugin ? :) > > > > [1] > https://groups.google.com/forum/?hl=en#!topic/jenkinsci-dev/GOiQdvctBB0 > > [2] https://github.com/tfennelly/jenkins/compare/icon-tag > > -- > 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]. > 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/YiR-u6wz6lI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > 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]. > 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/YiR-u6wz6lI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > 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]. > 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]. For more options, visit https://groups.google.com/d/optout.
