Re: Annotation versions
On Fri, Dec 17, 2021 at 5:34 PM Basil Crow wrote: > I suppose by the same logic we should remove > access-modifier-annotation, spotbugs-annotations, and > animal-sniffer-annotations from plugin-pom as well. > To the extent that you can verify that these libraries would be in the classpath for any plugin using any supported `jenkins.version`. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0_27wm%2Bjs%3DuK8270Laj3L73%3DPEz_tptKkDcZcvvYHfzw%40mail.gmail.com.
Re: Annotation versions
On Fri, Dec 17, 2021 at 2:12 PM 'Jesse Glick' via Jenkins Developers wrote: > > It is just listed as a plain dependency of `jenkins-core`. So it should be in > the plugin classpath already, just like any other library. Good point. I suppose by the same logic we should remove access-modifier-annotation, spotbugs-annotations, and animal-sniffer-annotations from plugin-pom as well. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjpv%2B%3DstMN0Xy1mOXDkkMwss4Lm%2BkC8m3knrN_JQfzrnAg%40mail.gmail.com.
Re: Annotation versions
On Fri, Dec 17, 2021 at 4:30 PM Basil Crow wrote: > Sorry, I should have clarified that I was proposing that we add > symbol-annotation to plugin-pom with scope=provided and optional=true Do we even need to? It is just listed as a plain dependency of `jenkins-core`. So it should be in the plugin classpath already, just like any other library. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1q8b9%3DUuerCrifvfRjogWLt34EcCEnO-i13WiWpCTUtw%40mail.gmail.com.
Re: Annotation versions
On Fri, Dec 17, 2021 at 1:22 PM 'Jesse Glick' via Jenkins Developers wrote: > > This is already in the core BOM. What else would we need to do? Sorry, I should have clarified that I was proposing that we add symbol-annotation to plugin-pom with scope=provided and optional=true matching spotbugs-annotations, jcip-annotations, and access-modifier-annotation. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjoTYbDypt9vbhFGg1aO55-zrKwOoP-Aybj912vyTM4kVw%40mail.gmail.com.
Re: Annotation versions
On Fri, Dec 17, 2021 at 3:51 PM Basil Crow wrote: > I propose we explicitly add javax.annotation-api to the core BOM and > plugin POM as we already do for spotbugs-annotations, > jcip-annotations, and access-modifier-annotation. Seems reasonable. A similar question applies to symbol-annotation. Now that we're > recommending that plugins get this from core rather than from structs, > it seems to me that we should give it the same treatment. > This is already in the core BOM. What else would we need to do? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3ZoEsx660GrHGmm%3DPdMB8a5xuO9JhiLNsfD0Luue9RFA%40mail.gmail.com.
Re: Annotation versions
Thanks for the replies! I have been proceeding along the second path as we discussed. I saw an interesting problem in nodelabelparameter-plugin: Require upper bound dependencies error for javax.annotation:javax.annotation-api:1.2 [provided] paths to dependency are: +-org.jenkins-ci.plugins:nodelabelparameter:1.10.3-SNAPSHOT +-org.jenkins-ci.main:jenkins-core:2.289.1 [provided] +-org.kohsuke.stapler:stapler:1.263 [provided] (managed) <-- org.kohsuke.stapler:stapler:1.263 [provided] +-javax.annotation:javax.annotation-api:1.2 [provided] and +-org.jenkins-ci.plugins:nodelabelparameter:1.10.3-SNAPSHOT +-org.jenkins-ci.plugins:parameterized-trigger:2.36 +-org.jenkins-ci.plugins:matrix-project:1.19 (managed) <-- org.jenkins-ci.plugins:matrix-project:1.6 +-org.jenkins-ci.plugins:junit:1.53 (managed) <-- org.jenkins-ci.plugins:junit:1.47 +-io.jenkins.plugins:plugin-util-api:2.5.1 (managed) <-- io.jenkins.plugins:plugin-util-api:2.4.0 +-javax.annotation:javax.annotation-api:1.3.2 [provided] and +-org.jenkins-ci.plugins:nodelabelparameter:1.10.3-SNAPSHOT +-org.jenkins-ci.plugins:parameterized-trigger:2.36 +-org.jenkins-ci.plugins:matrix-project:1.19 (managed) <-- org.jenkins-ci.plugins:matrix-project:1.6 +-org.jenkins-ci.plugins:junit:1.53 (managed) <-- org.jenkins-ci.plugins:junit:1.47 +-io.jenkins.plugins:plugin-util-api:2.5.1 (managed) <-- io.jenkins.plugins:plugin-util-api:2.4.0 +-edu.hm.hafner:codingstyle:2.10.0 [provided] +-javax.annotation:javax.annotation-api:1.3.2 [provided] Now core _does_ ship javax.annotation-api-1.3.2.jar in the WAR (transitively via Stapler) but does not declare it in the core BOM. plugin-util-api depends on it with scope=provided (good, because core does indeed provide it) but with an explicit version (bad, because the version plugin-util-api compiles against could be newer than the version shipped by plugin-util-api's core baseline). To resolve this I propose we explicitly add javax.annotation-api to the core BOM and plugin POM as we already do for spotbugs-annotations, jcip-annotations, and access-modifier-annotation. Then plugin-util-api can drop its version, instead getting the version corresponding to its core baseline via the core BOM provided by the plugin POM. Does that seem reasonable? A similar question applies to symbol-annotation. Now that we're recommending that plugins get this from core rather than from structs, it seems to me that we should give it the same treatment. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjo6nw0QO3i1cOPCeQgtUEm%3DK_Zm2CUaY0V3i2KGorncCw%40mail.gmail.com.
Re: Annotation versions
On Wed, Dec 15, 2021 at 4:35 PM James Nord wrote: > The plugin pom probably needs to remove a lot of cruft that makes it work > with older release now. > I tried in https://github.com/jenkinsci/plugin-pom/pull/457 but apparently got it wrong; if someone has time to dig deeper that would be great. The spotbugs annotations are source retention not runtime so unclear if > that could cause tools issues. > Class retention I think you mean, so yes they could (again depending on the tool). AccessModifier could iiuc be not shipped in the war as that is compile time > processing in plugins. > Currently runtime retention though. Could probably be downgraded to class retention, but again that could still cause tool issues if omitted from the WAR. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr27BbSfOXXvWU0%2Bj3y%2BBETBbXdeCqyidhV1TbZM7ocSWQ%40mail.gmail.com.
Re: Annotation versions
Iirc configuration-as-code plugin blew up when core no longer shipped the spotbugs annotations. The plugin pom probably needs to remove a lot of cruft that makes it work with older release now. The spotbugs annotations are source retention not runtime so unclear if that could cause tools issues. The BOM may well be to align transitive versions from dependencies so that upper bounds does not kill us Rather than anything else AccessModifier could iiuc be not shipped in the war as that is compile time processing in plugins. On Wednesday, 15 December 2021 at 19:41:31 UTC Jesse Glick wrote: > On Tue, Dec 14, 2021 at 11:12 PM Basil Crow wrote: > >> 1) … stop shipping the JARs in core > > > This could cause issues. Though class loaders are OK just ignoring > unloadable annotations, some tools which work with bytecode and reflective > APIs can encounter errors. Safest to have the annotation present, and > resolvable in the core/plugin class loader hierarchy, like any other > dependency. > > without scope=provided > > > Not good, because then the plugin would *bundle* the annotation JAR, > which we do not want. > > 2) … This means plugins would get the versions corresponding to their core >> baseline. >> > > Seems simplest and safest to me, and also ensures that the meaning of > annotations is consistent when applied to plugin references to core APIs. > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5a9f37ad-2fe7-4e29-94ec-8379440fbe2cn%40googlegroups.com.
Re: Annotation versions
On Tue, Dec 14, 2021 at 11:12 PM Basil Crow wrote: > 1) … stop shipping the JARs in core This could cause issues. Though class loaders are OK just ignoring unloadable annotations, some tools which work with bytecode and reflective APIs can encounter errors. Safest to have the annotation present, and resolvable in the core/plugin class loader hierarchy, like any other dependency. without scope=provided Not good, because then the plugin would *bundle* the annotation JAR, which we do not want. 2) … This means plugins would get the versions corresponding to their core > baseline. > Seems simplest and safest to me, and also ensures that the meaning of annotations is consistent when applied to plugin references to core APIs. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3b-kwF2%3DMSCXJshvgJDki2LHQ4UJ29NVPTwn3H6Cpf1w%40mail.gmail.com.
Re: Annotation versions
Former sounds better On Wed, 15 Dec 2021 at 04:12, Basil Crow wrote: > The Jenkins core BOM currently defines versions for > spotbugs-annotations, jcip-annotations, and > access-modifier-annotation, and core ships JARs for > spotbugs-annotations and access-modifier-annotation (but not > jcip-annotations, which is inconsistent). plugin-pom depends on > spotbugs-annotations at version 4.5.1 (which doesn't make sense > because it also imports the core BOM which defines this version > already) with scope=provided (which makes sense because core ships the > JAR) and optional=true (which makes sense because this isn't needed at > runtime). plugin-pom depends on jcip-annotations without an explicit > version (which makes sense because a version is already defined in the > core BOM which is imported by plugin-pom) with scope=provided (which > doesn't make sense because core doesn't ship the JAR) and > optional=true (which makes sense because this isn't needed at > runtime). plugin-pom depends on access-modifier-annotation at version > 1.25 (which doesn't make sense because it also imports the core BOM > which defines this version already), with scope=provided (which makes > sense because core ships the JAR) and optional=false (which doesn't > make sense because this isn't needed at runtime). > > Clearly this is a mess. But how should we fix it? I can see us going > in two different directions. > > 1) We could remove spotbugs-annotations, jcip-annotations, and > access-modifier-annotation from the core BOM and stop shipping the > JARs in core. In plugin-pom, we'd depend on a specific version of each > of these without scope=provided (because these aren't shipped by core) > but with optional=true (because they aren't needed at runtime). This > means plugins would get the versions defined in the plugin parent POM. > > 2) We could also keep spotbugs-annotations, jcip-annotations, and > access-modifier-annotation in the core BOM, continue shipping the JARs > in core (adding jcip-annotations), and remove the dependency on > specific versions from plugin-pom (thus getting the version from the > core BOM). We'd set scope=provided (because they would be shipped by > core) and optional=true (because they aren't needed at runtime). This > means plugins would get the versions corresponding to their core > baseline. > > Does anyone have a preference as to which direction we should go? I > suppose I have a slight preference for the former, because most > plugins update their plugin parent POM more often than their core > baseline, so it would be easier to push out changes to plugins if we > went in that direction. > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjqkfW2f_3YK1%2BWtMP_AGAjXNcpU3%2B%3DPc7xHdWWNSgR6KQ%40mail.gmail.com > . > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bic8YHcjVhb%2BV7DOyHOxPX_BcLcom6LdovrcGWdQ2pTPOw%40mail.gmail.com.
Annotation versions
The Jenkins core BOM currently defines versions for spotbugs-annotations, jcip-annotations, and access-modifier-annotation, and core ships JARs for spotbugs-annotations and access-modifier-annotation (but not jcip-annotations, which is inconsistent). plugin-pom depends on spotbugs-annotations at version 4.5.1 (which doesn't make sense because it also imports the core BOM which defines this version already) with scope=provided (which makes sense because core ships the JAR) and optional=true (which makes sense because this isn't needed at runtime). plugin-pom depends on jcip-annotations without an explicit version (which makes sense because a version is already defined in the core BOM which is imported by plugin-pom) with scope=provided (which doesn't make sense because core doesn't ship the JAR) and optional=true (which makes sense because this isn't needed at runtime). plugin-pom depends on access-modifier-annotation at version 1.25 (which doesn't make sense because it also imports the core BOM which defines this version already), with scope=provided (which makes sense because core ships the JAR) and optional=false (which doesn't make sense because this isn't needed at runtime). Clearly this is a mess. But how should we fix it? I can see us going in two different directions. 1) We could remove spotbugs-annotations, jcip-annotations, and access-modifier-annotation from the core BOM and stop shipping the JARs in core. In plugin-pom, we'd depend on a specific version of each of these without scope=provided (because these aren't shipped by core) but with optional=true (because they aren't needed at runtime). This means plugins would get the versions defined in the plugin parent POM. 2) We could also keep spotbugs-annotations, jcip-annotations, and access-modifier-annotation in the core BOM, continue shipping the JARs in core (adding jcip-annotations), and remove the dependency on specific versions from plugin-pom (thus getting the version from the core BOM). We'd set scope=provided (because they would be shipped by core) and optional=true (because they aren't needed at runtime). This means plugins would get the versions corresponding to their core baseline. Does anyone have a preference as to which direction we should go? I suppose I have a slight preference for the former, because most plugins update their plugin parent POM more often than their core baseline, so it would be easier to push out changes to plugins if we went in that direction. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjqkfW2f_3YK1%2BWtMP_AGAjXNcpU3%2B%3DPc7xHdWWNSgR6KQ%40mail.gmail.com.