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]] *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 <https://groups.google.com/forum/?hl=en#%21topic/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]
<mailto:[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]
<mailto:[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.
