Anyway you have over complicated yourself. Also you don't call the shim tag <icon-shim> you call it <icon> but in a different namespace. That makes migration simples
We should chat tomorrow On Tuesday, 1 July 2014, Stephen Connolly <[email protected]> wrote: > You can't update core to use the plugin, as circular dependency... So as > soon as you want to use your tag in core your plugin is... Oh look its a > shim! > > Would a rose by any other name smell as sweet? > > On Monday, 30 June 2014, Tom Fennelly <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> 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. >> > > > -- > Sent from my phone > -- 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]. For more options, visit https://groups.google.com/d/optout.
