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.

Reply via email to