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]>
[mailto:[email protected]] *On Behalf Of *Tom
Fennelly
*Sent:* den 1 juli 2014 12:41
*To:* [email protected]
<mailto:[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]>
[mailto:[email protected]] *On Behalf Of
*Tom Fennelly
*Sent:* den 1 juli 2014 00:33
*To:* [email protected]
<mailto:[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]
<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.
