Re: Annotation versions

2021-12-20 Thread 'Jesse Glick' via Jenkins Developers
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

2021-12-17 Thread Basil Crow
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

2021-12-17 Thread 'Jesse Glick' via Jenkins Developers
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

2021-12-17 Thread Basil Crow
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

2021-12-17 Thread 'Jesse Glick' via Jenkins Developers
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

2021-12-17 Thread Basil Crow
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

2021-12-16 Thread 'Jesse Glick' via Jenkins Developers
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

2021-12-15 Thread James Nord
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

2021-12-15 Thread 'Jesse Glick' via Jenkins Developers
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

2021-12-14 Thread Tim Jacomb
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.