Not at all... I just pointed out that if you go the way I originally suggested you get a nice clean tag in core and all the mess in a shim plugin that will go away eventually...
On 1 July 2014 16:18, Tom Fennelly <[email protected]> wrote: > OK.... after talking to Stephen again we're heading back in the old > "shim" direction (he has beaten me into submission lol). > > > On 01/07/2014 13:53, Stephen Connolly wrote: > > 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 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.
