RE: New Jelly tags - via Jenkins Core + Plugin shim, or via simple Java jar dependency ??
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] 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/BIg/9ZtjRLr_kQU/s320/Screenshot+2014-06-30+22.54.39.png]https://lh5.googleusercontent.com/-bnwMqmtmK4I/U7HdvP9_azI/BIg/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/BIw/wBNp2arHqD8/s320/Screenshot+2014-06-30+23.09.04.png]https://lh3.googleusercontent.com/-po0x1R8HUj0/U7HioP8dtXI/BIw/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/BI4/pVCDvV2M2TI/s320/Screenshot+2014-06-30+23.09.17.png]https://lh6.googleusercontent.com/-OMgCDihqezQ/U7HjQ9oJoUI/BI4/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.commailto: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.
Re: New Jelly tags - via Jenkins Core + Plugin shim, or via simple Java jar dependency ??
Maybe there's a misunderstanding ... I created a jenkins-icon module
(a simple java jar containing just the icon taglib). It doesn't depend
on anything in Jenkins - it just depends on Stapler. Jenkins core
depends on this module to get the icon tag. Plugins can also
independently depend on that module to get the icon tag. Where's the
circular dependency?
On 01/07/2014 00:27, Stephen Connolly wrote:
You can't update core to use the plugin, as circular dependency... So
as soon as you want to use your tag in core your plugin is... Oh look
its a shim!
Would a rose by any other name smell as sweet?
On Monday, 30 June 2014, Tom Fennelly tom.fenne...@gmail.com
mailto:tom.fenne...@gmail.com wrote:
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/BIg/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/BIw/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/BI4/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 jenkinsci-dev+unsubscr...@googlegroups.com
javascript:_e(%7B%7D,'cvml','jenkinsci-dev%2bunsubscr...@googlegroups.com');.
For more options, visit https://groups.google.com/d/optout.
--
Sent from my phone
--
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
mailto: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.
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] *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/BIg/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/BIw/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/BI4/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 jenkinsci-dev+unsubscr...@googlegroups.com
mailto: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
mailto: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.
Re: New Jelly tags - via Jenkins Core + Plugin shim, or via simple Java jar dependency ??
Ah ok. Yeah that will work
On Tuesday, 1 July 2014, Tom Fennelly tom.fenne...@gmail.com wrote:
Maybe there's a misunderstanding ... I created a jenkins-icon module (a
simple java jar containing just the icon taglib). It doesn't depend on
anything in Jenkins - it just depends on Stapler. Jenkins core depends on
this module to get the icon tag. Plugins can also independently depend on
that module to get the icon tag. Where's the circular dependency?
On 01/07/2014 00:27, Stephen Connolly wrote:
You can't update core to use the plugin, as circular dependency... So as
soon as you want to use your tag in core your plugin is... Oh look its a
shim!
Would a rose by any other name smell as sweet?
On Monday, 30 June 2014, Tom Fennelly tom.fenne...@gmail.com
javascript:_e(%7B%7D,'cvml','tom.fenne...@gmail.com'); wrote:
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/BIg/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/BIw/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/BI4/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.
--
Sent from my phone
--
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
javascript:_e(%7B%7D,'cvml','jenkinsci-dev%2bunsubscr...@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
javascript:_e(%7B%7D,'cvml','jenkinsci-dev%2bunsubscr...@googlegroups.com');
.
For more options, visit https://groups.google.com/d/optout.
--
Sent from my phone
--
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.
RE: New Jelly tags - via Jenkins Core + Plugin shim, or via simple Java jar dependency ??
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] 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.commailto:jenkinsci-dev@googlegroups.com
[mailto:jenkinsci-dev@googlegroups.com] On Behalf Of Tom Fennelly
Sent: den 1 juli 2014 00:33
To: jenkinsci-dev@googlegroups.commailto: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/BIg/9ZtjRLr_kQU/s320/Screenshot+2014-06-30+22.54.39.png]https://lh5.googleusercontent.com/-bnwMqmtmK4I/U7HdvP9_azI/BIg/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/BIw/wBNp2arHqD8/s320/Screenshot+2014-06-30+23.09.04.png]https://lh3.googleusercontent.com/-po0x1R8HUj0/U7HioP8dtXI/BIw/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/BI4/pVCDvV2M2TI/s320/Screenshot+2014-06-30+23.09.17.png]https://lh6.googleusercontent.com/-OMgCDihqezQ/U7HjQ9oJoUI/BI4/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/GOiQdvctBB0https://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
jenkinsci-dev+unsubscr...@googlegroups.commailto:jenkinsci-dev
Re: New Jelly tags - via Jenkins Core + Plugin shim, or via simple Java jar dependency ??
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] *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
[mailto:jenkinsci-dev@googlegroups.com] *On Behalf Of *Tom Fennelly
*Sent:* den 1 juli 2014 00:33
*To:* jenkinsci-dev@googlegroups.com
mailto: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/BIg/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/BIw/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/BI4/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
Re: New Jelly tags - via Jenkins Core + Plugin shim, or via simple Java jar dependency ??
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/BIg/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/BIw/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/BI4/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
Re: New Jelly tags - via Jenkins Core + Plugin shim, or via simple Java jar dependency ??
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
mailto: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
[mailto:jenkinsci-dev@googlegroups.com] *On Behalf Of *Tom Fennelly
*Sent:* den 1 juli 2014 12:41
*To:* jenkinsci-dev@googlegroups.com
mailto: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
[mailto:jenkinsci-dev@googlegroups.com] *On Behalf Of *Tom
Fennelly
*Sent:* den 1 juli 2014 00:33
*To:* jenkinsci-dev@googlegroups.com
mailto: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/BIg/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/BIw/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
Re: New Jelly tags - via Jenkins Core + Plugin shim, or via simple Java jar dependency ??
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/BIg/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/BIw/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/BI4/pVCDvV2M2TI/s1600/Screenshot+2014-06-30+23.09.17.png
I have some code here [2]. It works fine from a Jenkins
Re: New Jelly tags - via Jenkins Core + Plugin shim, or via simple Java jar dependency ??
You did that too ;) Ah I'm just kidding... thanks Stephen !!!
On 01/07/2014 16:29, Stephen Connolly wrote:
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
mailto: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
mailto: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
[mailto:jenkinsci-dev@googlegroups.com] *On Behalf Of *Tom
Fennelly
*Sent:* den 1 juli 2014 12:41
*To:* jenkinsci-dev@googlegroups.com
mailto: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
[mailto:jenkinsci-dev@googlegroups.com] *On Behalf Of
*Tom Fennelly
*Sent:* den 1 juli 2014 00:33
*To:* jenkinsci-dev@googlegroups.com
mailto: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/BIg/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
Re: New Jelly tags - via Jenkins Core + Plugin shim, or via simple Java jar dependency ??
You can't update core to use the plugin, as circular dependency... So as
soon as you want to use your tag in core your plugin is... Oh look its a
shim!
Would a rose by any other name smell as sweet?
On Monday, 30 June 2014, Tom Fennelly tom.fenne...@gmail.com wrote:
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/BIg/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/BIw/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/BI4/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
javascript:_e(%7B%7D,'cvml','jenkinsci-dev%2bunsubscr...@googlegroups.com');
.
For more options, visit https://groups.google.com/d/optout.
--
Sent from my phone
--
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.
Re: New Jelly tags - via Jenkins Core + Plugin shim, or via simple Java jar dependency ??
Anyway you have over complicated yourself.
Also you don't call the shim tag icon-shim you call it icon but in a
different namespace. That makes migration simples
We should chat tomorrow
On Tuesday, 1 July 2014, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
You can't update core to use the plugin, as circular dependency... So as
soon as you want to use your tag in core your plugin is... Oh look its a
shim!
Would a rose by any other name smell as sweet?
On Monday, 30 June 2014, Tom Fennelly tom.fenne...@gmail.com
javascript:_e(%7B%7D,'cvml','tom.fenne...@gmail.com'); wrote:
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/BIg/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/BIw/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/BI4/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.
--
Sent from my phone
--
Sent from my phone
--
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.
