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 <tom.fenne...@gmail.com> 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 <tom.fenne...@gmail.com> 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:* jenkinsci-dev@googlegroups.com [ >> mailto:jenkinsci-dev@googlegroups.com <jenkinsci-dev@googlegroups.com>] *On >> Behalf Of *Tom Fennelly >> *Sent:* den 1 juli 2014 12:41 >> *To:* jenkinsci-dev@googlegroups.com >> *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:* jenkinsci-dev@googlegroups.com [ >> mailto:jenkinsci-dev@googlegroups.com <jenkinsci-dev@googlegroups.com>] *On >> Behalf Of *Tom Fennelly >> *Sent:* den 1 juli 2014 00:33 >> *To:* jenkinsci-dev@googlegroups.com >> *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 jenkinsci-dev+unsubscr...@googlegroups.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/YiR-u6wz6lI/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> jenkinsci-dev+unsubscr...@googlegroups.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+unsubscr...@googlegroups.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/YiR-u6wz6lI/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> jenkinsci-dev+unsubscr...@googlegroups.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+unsubscr...@googlegroups.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/YiR-u6wz6lI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > jenkinsci-dev+unsubscr...@googlegroups.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+unsubscr...@googlegroups.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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
