Re: ASM in core

On Thu, Jun 10, 2021 at 1:46 AM jn...@cloudbees.com wrote: > > I have just noticed a few PRs (some merged) to change ASM in core or > libraries that core depdns on (stapler). > I think we need to revert these […]. Thanks, James! Valentin Delaye has removed ASM from Jenkins c

Re: ASM in core

On Sat, Jan 13, 2024 at 5:09 AM Valentin Delaye (jonesbusy) wrote: > > Jumping into this Are you still interested in removing ASM from core? I checked usage in plugins, and I believe all significant plugins are now linking against the ASM library plugin. The last major blocker was the

Re: ASM in core

e rest will probably follow step by step, it's a long journey until ASM can be safely removed from core Regards, On Thursday, January 4, 2024 at 7:55:36 PM UTC+1 m...@basilcrow.com wrote: > Fast forward a little over a year and removing ASM from core in favor > of dynamic linking throu

Re: ASM in core

Fast forward a little over a year and removing ASM from core in favor of dynamic linking through a library plugin seems more achievable, though still quite a bit of work. The following plan seems achievable: - Create a new ASM library plugin. It would be unused as long as core keeps shipping ASM

Re: ASM in core

On previous detaches we faced the same issue 10-15 plugins dependencies and most of them outdated, I remember (tripled-ssh2, sshd), we made a cut on plugins not updated in the last two years (maybe three) that removed most of the problem. Those plugins with more than 2-3 years without updates

Re: ASM in core

I think detaching is riskier than I expected: a lot of plugins bundle old copies of ASM (or depend on other plugins that do). With core's copy no longer taking precedence, I fear that there might be a high risk of regression with a detached plugin. Seems safer to deal with each plugin on a

Re: ASM in core

On Thu, Aug 18, 2022 at 10:30 AM 'Daniel Beck' via Jenkins Developers wrote: > I might miss some context, as this thread has been going for a while, but is > a clean removal like JNR doable here as well? A quick GH search indicates > that only a few plugins use ASM. Probably doable with a

Re: ASM in core

On Thu, Aug 18, 2022 at 6:40 AM Basil Crow wrote: > Recent weeklies no longer consume ASM. So shall we detach it to a > library plugin? > I might miss some context, as this thread has been going for a while, but is a clean removal like JNR doable here as well? A quick GH search indicates that

Re: ASM in core

+1 for detaching On Thursday, 18 August 2022 at 08:36:25 UTC+2 timja...@gmail.com wrote: > If core no longer uses it the. Yes absolutely +1 > > On Thu, 18 Aug 2022 at 05:40, Basil Crow wrote: > >> Recent weeklies no longer consume ASM. So shall we detach it to a >> library plugin? >> >> -- >>

Re: ASM in core

If core no longer uses it the. Yes absolutely +1 On Thu, 18 Aug 2022 at 05:40, Basil Crow wrote: > Recent weeklies no longer consume ASM. So shall we detach it to a > library plugin? > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group.

Re: ASM in core

Recent weeklies no longer consume ASM. So shall we detach it to a library plugin? -- 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

Re: ASM in core

On Tue, Jan 4, 2022 at 5:09 PM 'Jesse Glick' via Jenkins Developers wrote: > > That basically takes us back to the unfortunate state we were in with > Kohsuke’s series of shaded & repackaged ASM libraries, where we could not > give a clear answer as to what we were actually bundling, and

Re: ASM in core

On Tue, Jan 4, 2022 at 5:22 PM Basil Crow wrote: > So should I look into the shading approach further? That basically takes us back to the unfortunate state we were in with Kohsuke’s series of shaded & repackaged ASM libraries, where we could not give a clear answer as to what we were actually

Re: ASM in core

On Tue, Jan 4, 2022 at 1:05 PM 'Jesse Glick' via Jenkins Developers wrote: > > `access-modifier` is not a big deal since it is used only at compile > time—need not be shipped in core. But as of jenkinsci/plugin-pom#480 plugins get their (compile time!) access-modifier-annotation dependency from

Re: ASM in core

On Tue, Jan 4, 2022 at 3:07 PM Basil Crow wrote: > the only remaining consumers of ASM in core will be Stapler and > access-modifier > `access-modifier` is not a big deal since it is used only at compile time—need not be shipped in core. The usage in Stapler is an obstacle. IIUC until

Re: ASM in core

Once JNR is removed from core in jenkinsci/jenkins#5979 (which is blocked on the merge, release, and widespread adoption of jenkinsci/pam-auth-plugin#20), then the only remaining consumers of ASM in core will be Stapler [1] and access-modifier [2]. It would be nice to eliminate these dependencies

Re: ASM in core

Thanks for investigating further on this Basil! /James On Fri, 11 Jun 2021 at 16:00, Basil Crow wrote: > On Fri, Jun 11, 2021 at 2:19 AM Robert Sandell > wrote: > > > > Some historical context to know where we "old timers" are coming from :) > >

Re: ASM in core

It originally used regex/hand parsing, but some of the requests for features were not super easy to implement using that method. I can look at it again if we want to remove the ASM dependency for sure. On Tue, Jun 15, 2021 at 8:55 AM Jesse Glick wrote: > On Mon, Jun 14, 2021 at 10:47 PM Slide

Re: ASM in core

On Mon, Jun 14, 2021 at 10:47 PM Slide wrote: > ASM is a dependency of the parser used (parboiled). > What is what I gathered. Probably the fairly simple syntax used by this plugin could be handled with a hand-written parser (regexp?) with some effort. But it seems to also be used by some

Re: ASM in core

In the case of system properties https://www.jenkins.io/doc/book/managing/system-properties/ Says: Compatibility We do *NOT* guarantee that system properties will remain unchanged and functional indefinitely. These

Re: ASM in core

On Mon, Jun 14, 2021 at 7:36 PM Jesse Glick wrote: > > JNR may be a similar story. I see all of two usages in core—both disabled > unless you set a system property. Just deleting it all may be easier I had already noticed that as well and thought about opening such a PR to delete all usages of

Re: ASM in core

ASM is a dependency of the parser used (parboiled). People still use token macro a lot even in pipeline even if there are other ways of doing what it does. On Mon, Jun 14, 2021 at 7:36 PM Jesse Glick wrote: > We should also take a step back and see if these problematic deps really > need to

Re: ASM in core

We should also take a step back and see if these problematic deps really need to exist at all. Most uses of ASM should be deleted if at all possible. I was able to remove Digester and thus, I guess, ASM from the Subversion plugin without much difficulty. I do not understand Token Macro well enough

Re: ASM in core

On Fri, Jun 11, 2021 at 2:19 AM Robert Sandell wrote: > > Some historical context to know where we "old timers" are coming from :) > https://kohsuke.org/2012/03/03/potd-package-renamed-asm/ Thanks for providing this context, Robert! I have a tremendous amount of respect for all the old-timers in

Re: ASM in core

On Fri, Jun 11, 2021 at 3:45 AM Ullrich Hafner wrote: > > Wouldn’t it be helpful if we would also suggest which option we prefer? > Otherwise every plugin author needs to rethink the same options again and > again. > > E.g., option 1 did break all my integration tests with the token macro

Re: ASM in core

On June 11, 2021 10:18:30 AM UTC, kuisathaverat wrote: >Robert, Which plugin are you talking about? Which version of the core >is >that plugin required as minimum? there is another topic opened a few >weeks >ago about deprecated plugins, a plugin should bump it core minimum >required >version and

Re: ASM in core

> > In general, when a plugin depends on a library already provided by > core, I have seen three approaches in the short term: > > 1. Exclude the library on the plugin side (e.g. how Token Macro excludes ASM) > 2. Mask the library's classes (e.g. how JaCoCo masks ASM classes) > 3. Shade the

Re: ASM in core

Robert, Which plugin are you talking about? Which version of the core is that plugin required as minimum? there is another topic opened a few weeks ago about deprecated plugins, a plugin should bump it core minimum required version and update its dependencies often, if not it is not possible to

Re: ASM in core

Some historical context to know where we "old timers" are coming from :) https://kohsuke.org/2012/03/03/potd-package-renamed-asm/ There are several times where I've needed to shade asm in plugins because of some transitive dependency. Las time I think it was a dependency on ASM7 that blew up

Re: ASM in core

Hi, I would like to add an issue related to not bump the ASM library, I recently hit an issue with stapler (see https://groups.google.com/g/jenkinsci-dev/c/JppfFwqIrCU) and it is related to compile the plugin for JDK 11 only, new plugins use new libraries and more and more libraries use JDK 11

Re: ASM in core

On Thu, Jun 10, 2021 at 11:28 AM Tim Jacomb wrote: > > It would be good to see a more recent report given we’re on version 9 in core > to see if anything has changed in recent versions Great point, Tim. Core 2.273 shipped with ASM 5.0.3, prior to the upgrade of JNR (and therefore the accidental

Re: ASM in core

On Thu, Jun 10, 2021 at 10:48 AM jn...@cloudbees.com wrote: > JenkinsRule / RestartableJenkinsRule and any other junit test not using > `RealisticJenkinsRule` do not use the hierarchical Jenkins classloader and > are hence completely unrealistic when it comes to classloading. They use the >

Re: ASM in core

t;>> to use the copy provided by core. >>> >>> In general, when a plugin depends on a library already provided by >>> core, I have seen three approaches in the short term: >>> >>> 1. Exclude the library on the plugin side (e.g. how Token Macro exclu

Re: ASM in core

Dear James, On Thu, Jun 10, 2021 at 10:34 AM jn...@cloudbees.com wrote: > > Thus care needs to be taken before any library is updated Of course. Yet such care was not taken when JNR was updated in December 2020. That is why nobody noticed that the JNR update also pulled in a new ASM update, and

Re: ASM in core

words, reverting > the Stapler change will reduce the surface area of the problem, but it > will not eliminate the problem. > > I do not believe this to be correct, the core class will resolve ASM > using the core classes' classloader not the plugins classloader even when > invoked fr

Re: ASM in core

> forward to the PRs. I am not planning on opening any such PRs, and I am not sure why you would think that I am. Please remember that I am a volunteer and am just trying to help where I can. An encouraging and constructive tone would be appreciated. > I do not believe this to be correct, the

Re: ASM in core

il. In other words, reverting the Stapler change will reduce the surface area of the problem, but it will not eliminate the problem. I do not believe this to be correct, the core class will resolve ASM using the core classes' classloader not the plugins classloader even when invoked from the plu

Re: ASM in core

t; > None of these are ideal compared to the larger projects of removing > (or hiding) Guice/JNR (and by extension Guava/ASM) from core, but all > three approaches work in the short term. > > As long as core continues to expose JNR (and therefore unshaded ASM) > in its public API,

Re: ASM in core

of these are ideal compared to the larger projects of removing (or hiding) Guice/JNR (and by extension Guava/ASM) from core, but all three approaches work in the short term. As long as core continues to expose JNR (and therefore unshaded ASM) in its public API, plugins that use ASM (directly

Re: ASM in core

I don't remember seeing formal docs about it, but I believe it was changed for two reasons: 1. Dependency simplifications in general. That's been an ongoing effort by multiple people, particularly in Jenkins Core. 2. ASM needs to be upgraded more often now that Java itself is released more often

ASM in core

Hi all, I have just noticed a few PRs (some merged) to change ASM in core or libraries that core depdns on (stapler). I think we need to revert these and have a bigger think about ASM. ASM historically (and I believe still true) evolved in a non compatible way. In the past I have seen