Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-50272

NoClassDefFoundError "hudson/tools/JDKInstaller$FileSystem" at SSHLauncher after Jenkins Update 2.111->2.112

    • Icon: Bug Bug
    • Resolution: Not A Defect
    • Icon: Critical Critical
    • core
    • None

      During restart when upgrading Jenkins (core) from 2.111 => 2.112

      2018-03-20 07:50:39 WARNING [hudson.ExtensionFinder$GuiceFinder$FaultTolerantScope$1 error]   Failed to instantiate Key[type=hudson.plugins.sshslaves.SSHLauncher$DescriptorImpl, an
      notation=[none]]; skipping this component
      com.google.inject.ProvisionException: Unable to provision, see the following errors:
      
      1) Error injecting constructor, java.lang.NoClassDefFoundError: hudson/tools/JDKInstaller$FileSystem
        at hudson.plugins.sshslaves.SSHLauncher$DescriptorImpl.<init>(SSHLauncher.java:1617)
      
      1 error
              at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:52)
              at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:145)
              at hudson.ExtensionFinder$GuiceFinder$FaultTolerantScope$1.get(ExtensionFinder.java:424)
              at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
              at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
              at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1092)
              at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
              at hudson.ExtensionFinder$GuiceFinder._find(ExtensionFinder.java:386)
              at hudson.ExtensionFinder$GuiceFinder.find(ExtensionFinder.java:377)
              at hudson.ClassicPluginStrategy.findComponents(ClassicPluginStrategy.java:482)
              at hudson.ExtensionList.load(ExtensionList.java:366)
              at hudson.ExtensionList.ensureLoaded(ExtensionList.java:304)
              at hudson.ExtensionList.getComponents(ExtensionList.java:169)
              at hudson.DescriptorExtensionList.load(DescriptorExtensionList.java:192)
              at hudson.ExtensionList.ensureLoaded(ExtensionList.java:304)
              at hudson.ExtensionList.iterator(ExtensionList.java:158)
              at org.jenkinsci.plugins.xunit.AliasInitializer.addAliases(AliasInitializer.java:47)
              at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
              at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
              at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
              at java.lang.reflect.Method.invoke(Method.java:498)
              at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:104)
              at hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:175)
              at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
              at jenkins.model.Jenkins$5.runTask(Jenkins.java:1064)
              at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
              at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
              at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
              at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
              at java.lang.Thread.run(Thread.java:748)
      Caused by: java.lang.NoClassDefFoundError: hudson/tools/JDKInstaller$FileSystem
              at java.lang.Class.getDeclaredMethods0(Native Method)
              at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
              at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
              at java.lang.Class.getMethod0(Class.java:3018)
              at java.lang.Class.getMethod(Class.java:1784)
              at hudson.model.Descriptor.<init>(Descriptor.java:289)
              at hudson.plugins.sshslaves.SSHLauncher$DescriptorImpl.<init>(SSHLauncher.java:1617)
              at hudson.plugins.sshslaves.SSHLauncher$DescriptorImpl$$FastClassByGuice$$7821d6d6.newInstance(<generated>)
              at com.google.inject.internal.cglib.reflect.$FastConstructor.newInstance(FastConstructor.java:40)
              at com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:61)
              at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:105)
              at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:85)
              at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:267)
              at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
              at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
              at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
              ... 29 more
      Caused by: java.lang.ClassNotFoundException: hudson.tools.JDKInstaller$FileSystem
              at jenkins.util.AntClassLoader.findClassInComponents(AntClassLoader.java:1374)
              at jenkins.util.AntClassLoader.findClass(AntClassLoader.java:1327)
              at jenkins.util.AntClassLoader.loadClass(AntClassLoader.java:1080)
              at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
              ... 45 more
      
      2018-03-20 07:50:39 WARNING [hudson.ExtensionFinder$GuiceFinder$FaultTolerantScope$1 error]   Failed to instantiate Key[type=hudson.os.windows.ManagedWindowsServiceLauncher$DescriptorImpl, annotation=[none]]; skipping this component
      com.google.inject.ProvisionException: Unable to provision, see the following errors:
      
      1) Error injecting constructor, java.lang.NoClassDefFoundError: hudson/tools/JDKInstaller$FileSystem
        at hudson.os.windows.ManagedWindowsServiceLauncher$DescriptorImpl.<init>(ManagedWindowsServiceLauncher.java:540)
      
      1 error
              at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:52)
              at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:145)
              at hudson.ExtensionFinder$GuiceFinder$FaultTolerantScope$1.get(ExtensionFinder.java:424)
              at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
              at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
              at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1092)
              at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
              at hudson.ExtensionFinder$GuiceFinder._find(ExtensionFinder.java:386)
              at hudson.ExtensionFinder$GuiceFinder.find(ExtensionFinder.java:377)
              at hudson.ClassicPluginStrategy.findComponents(ClassicPluginStrategy.java:482)
              at hudson.ExtensionList.load(ExtensionList.java:366)
              at hudson.ExtensionList.ensureLoaded(ExtensionList.java:304)
              at hudson.ExtensionList.getComponents(ExtensionList.java:169)
              at hudson.DescriptorExtensionList.load(DescriptorExtensionList.java:192)
              at hudson.ExtensionList.ensureLoaded(ExtensionList.java:304)
              at hudson.ExtensionList.iterator(ExtensionList.java:158)
              at org.jenkinsci.plugins.xunit.AliasInitializer.addAliases(AliasInitializer.java:47)
              at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
              at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
              at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
              at java.lang.reflect.Method.invoke(Method.java:498)
              at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:104)
              at hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:175)
              at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
              at jenkins.model.Jenkins$5.runTask(Jenkins.java:1064)
              at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
              at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
              at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
              at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
              at java.lang.Thread.run(Thread.java:748)
      Caused by: java.lang.NoClassDefFoundError: hudson/tools/JDKInstaller$FileSystem
              at java.lang.Class.getDeclaredMethods0(Native Method)
              at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
              at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
              at java.lang.Class.getMethod0(Class.java:3018)
              at java.lang.Class.getMethod(Class.java:1784)
              at hudson.model.Descriptor.<init>(Descriptor.java:289)
              at hudson.os.windows.ManagedWindowsServiceLauncher$DescriptorImpl.<init>(ManagedWindowsServiceLauncher.java:540)
              at hudson.os.windows.ManagedWindowsServiceLauncher$DescriptorImpl$$FastClassByGuice$$39d9fc24.newInstance(<generated>)
              at com.google.inject.internal.cglib.reflect.$FastConstructor.newInstance(FastConstructor.java:40)
              at com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:61)
              at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:105)
              at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:85)
              at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:267)
              at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
              at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
              at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
              ... 29 more
      Caused by: java.lang.ClassNotFoundException: hudson.tools.JDKInstaller$FileSystem
              at jenkins.util.AntClassLoader.findClassInComponents(AntClassLoader.java:1374)
              at jenkins.util.AntClassLoader.findClass(AntClassLoader.java:1327)
              at jenkins.util.AntClassLoader.loadClass(AntClassLoader.java:1080)
              at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
              ... 45 more
      

          [JENKINS-50272] NoClassDefFoundError "hudson/tools/JDKInstaller$FileSystem" at SSHLauncher after Jenkins Update 2.111->2.112

          Reinhold Füreder added a comment - - edited

          Well, the solution was to install the brand-new JDK Tool Plugin, as admittedly at least vaguely mentioned in the change log:

          Install from java.sun.com installation method for JDK tools has been moved to a new JDK Tool Plugin. (issue 22367)

          In my installation I was a bit lucky as this was then done implicitly when updating Jenkins plugins too: due to seemingly new dependency of the only two plugins (cloudbees-folder v6.4, credentials-binding v1.16) that were not up-to-date:

          2018-03-20 08:13:32 INFO [java.util.logging.LogManager$RootLogger log]   Checking 'cloudbees-folder' plugin...
          2018-03-20 08:13:32 INFO [java.util.logging.LogManager$RootLogger log]   Installing update for 'cloudbees-folder:6.3' plugin: 6.4...
          2018-03-20 08:13:32 INFO [hudson.model.UpdateSite$Plugin deploy]   Adding dependent install of jdk-tool for plugin cloudbees-folder
          ...
          2018-03-20 08:13:32 INFO [java.util.logging.LogManager$RootLogger log]   Checking 'credentials-binding' plugin...
          2018-03-20 08:13:32 INFO [java.util.logging.LogManager$RootLogger log]   Installing update for 'credentials-binding:1.15' plugin: 1.16...
          2018-03-20 08:13:32 INFO [hudson.model.UpdateSite$Plugin deploy]   Dependent install of jdk-tool for plugin credentials-binding already added, skipping
          ...
          2018-03-20 08:13:32 INFO [java.util.logging.LogManager$RootLogger log]   ---> Installation of plugins in progress, waiting for completion...
          2018-03-20 08:13:33 INFO [hudson.model.UpdateCenter$DownloadJob run]   Starting the installation of JDK Tool on behalf of SYSTEM
          2018-03-20 08:13:34 INFO [hudson.model.UpdateCenter$UpdateCenterConfiguration download]   Downloading JDK Tool
          2018-03-20 08:13:34 INFO [hudson.model.UpdateCenter$DownloadJob run]   Starting the installation of Folders on behalf of SYSTEM
          2018-03-20 08:13:35 INFO [hudson.model.UpdateCenter$UpdateCenterConfiguration download]   Downloading Folders
          2018-03-20 08:13:36 INFO [hudson.model.UpdateCenter$DownloadJob run]   Starting the installation of Credentials Binding on behalf of SYSTEM
          2018-03-20 08:13:36 INFO [hudson.model.UpdateCenter$UpdateCenterConfiguration download]   Downloading Credentials Binding
          ---> Plugins installed:
                  cloudbees-folder:6.4
                  credentials-binding:1.16
          
          Why did this problem occur?
          • I am always first updating solely Jenkins core (followed by testing the update with some pipelines) and only then (in an explicit second step) update Jenkins plugins (again followed by testing the updates with some pipelines)...
          • So I am not entirely happy due to being surprised by that problem, but I can certainly live with the required fix.

          Reinhold Füreder added a comment - - edited Well, the solution was to install the brand-new JDK Tool Plugin , as admittedly at least vaguely mentioned in the change log: Install from java.sun.com installation method for JDK tools has been moved to a new JDK Tool Plugin. (issue 22367) In my installation I was a bit lucky as this was then done implicitly when updating Jenkins plugins too: due to seemingly new dependency of the only two plugins (cloudbees-folder v6.4, credentials-binding v1.16) that were not up-to-date: 2018-03-20 08:13:32 INFO [java.util.logging.LogManager$RootLogger log] Checking 'cloudbees-folder' plugin... 2018-03-20 08:13:32 INFO [java.util.logging.LogManager$RootLogger log] Installing update for 'cloudbees-folder:6.3' plugin: 6.4... 2018-03-20 08:13:32 INFO [hudson.model.UpdateSite$Plugin deploy] Adding dependent install of jdk-tool for plugin cloudbees-folder ... 2018-03-20 08:13:32 INFO [java.util.logging.LogManager$RootLogger log] Checking 'credentials-binding' plugin... 2018-03-20 08:13:32 INFO [java.util.logging.LogManager$RootLogger log] Installing update for 'credentials-binding:1.15' plugin: 1.16... 2018-03-20 08:13:32 INFO [hudson.model.UpdateSite$Plugin deploy] Dependent install of jdk-tool for plugin credentials-binding already added, skipping ... 2018-03-20 08:13:32 INFO [java.util.logging.LogManager$RootLogger log] ---> Installation of plugins in progress, waiting for completion... 2018-03-20 08:13:33 INFO [hudson.model.UpdateCenter$DownloadJob run] Starting the installation of JDK Tool on behalf of SYSTEM 2018-03-20 08:13:34 INFO [hudson.model.UpdateCenter$UpdateCenterConfiguration download] Downloading JDK Tool 2018-03-20 08:13:34 INFO [hudson.model.UpdateCenter$DownloadJob run] Starting the installation of Folders on behalf of SYSTEM 2018-03-20 08:13:35 INFO [hudson.model.UpdateCenter$UpdateCenterConfiguration download] Downloading Folders 2018-03-20 08:13:36 INFO [hudson.model.UpdateCenter$DownloadJob run] Starting the installation of Credentials Binding on behalf of SYSTEM 2018-03-20 08:13:36 INFO [hudson.model.UpdateCenter$UpdateCenterConfiguration download] Downloading Credentials Binding ---> Plugins installed: cloudbees-folder:6.4 credentials-binding:1.16 Why did this problem occur? I am always first updating solely Jenkins core (followed by testing the update with some pipelines) and only then (in an explicit second step) update Jenkins plugins (again followed by testing the updates with some pipelines)... So I am not entirely happy due to being surprised by that problem, but I can certainly live with the required fix.

          Reinhold Füreder added a comment - - edited

          I dare to resolve with "Won't Fix".

          Is there a good possibility to kind of signal the new need for installing a plugin (due to refactorings) to avoid this error? And of course this problem only hits existing installations...

          Suggestion for a poor man's attempt to avoid this error based on change log (https://jenkins.io/changelog/ for 2.112): Explicitly list all plugins that depend on the this JDK Tool plugin and that newly require the installation of JDK Tool plugin. Oh! Or is the Jenkins core depending on it already?

          Reinhold Füreder added a comment - - edited I dare to resolve with "Won't Fix". Is there a good possibility to kind of signal the new need for installing a plugin (due to refactorings) to avoid this error? And of course this problem only hits existing installations... Suggestion for a poor man's attempt to avoid this error based on change log ( https://jenkins.io/changelog/ for 2.112): Explicitly list all plugins that depend on the this JDK Tool plugin and that newly require the installation of JDK Tool plugin. Oh! Or is the Jenkins core depending on it already?

          Devin Nusbaum added a comment -

          reinholdfuereder The new plugin should be automatically installed on an upgrade. If it was not upgraded, that is a bug and it should be fixed.

          Devin Nusbaum added a comment - reinholdfuereder The new plugin should be automatically installed on an upgrade. If it was not upgraded, that is a bug and it should be fixed.

          dnusbaum Frankly, I had hoped so too (ad automatically installed). However, I am not sure whether or not my Jenkins core upgrade automation process/procedure may be disallowing that?

          1. (Manual) "Manage Jenkins > Prepare for Shutdown"
          2. (Automatic) Via Ansible:
            1. Download the specific version as debian package
            2. Install via Ansible (apt deb)
            3. Update 'jenkins.install.UpgradeWizard.state' and 'jenkins.install.InstallUtil.lastExecVersion' files
            4. Restart Jenkins

          Reinhold Füreder added a comment - dnusbaum Frankly, I had hoped so too (ad automatically installed). However, I am not sure whether or not my Jenkins core upgrade automation process/procedure may be disallowing that? (Manual) "Manage Jenkins > Prepare for Shutdown" (Automatic) Via Ansible: Download the specific version as debian package Install via Ansible (apt deb) Update 'jenkins.install.UpgradeWizard.state' and 'jenkins.install.InstallUtil.lastExecVersion' files Restart Jenkins

          Devin Nusbaum added a comment -

          reinholdfuereder Can you post logs from the time of the upgrade? 

          I would expect to see a line like:

          Upgrading Jenkins. The last running version was $old. This Jenkins is version $new.

          If you do not see such a line, then Jenkins did not detect that an upgrade was happening (possibly related to JENKINS-48365), which explains why the plugin was not installed. That shouldn't be possible when upgrading from 2.111 unless maybe your instance has no jenkins.install.lastExecVersion file?

          Devin Nusbaum added a comment - reinholdfuereder  Can you post logs from the time of the upgrade?  I would expect to see a line like: Upgrading Jenkins. The last running version was $old. This Jenkins is version $new. If you do not see such a line, then Jenkins did not detect that an upgrade was happening (possibly related to JENKINS-48365 ), which explains why the plugin was not installed. That shouldn't be possible when upgrading from 2.111 unless maybe your instance has no jenkins.install.lastExecVersion file?

          Devin Nusbaum added a comment - - edited

          reinholdfuereder Ah, the following step breaks the upgrade detection:

          3. Update 'jenkins.install.UpgradeWizard.state' and 'jenkins.install.InstallUtil.lastExecVersion' files

          Maybe you were manually updating jenkins.install.InstallUtil.lastExecVersion because before JENKINS-48365 was fixed in 2.96 that file was not updated correctly after an upgrade. You should not update it manually any more. Jenkins will upgrade the file itself after starting and detecting that an upgrade occured.

          I am not sure why you are updating jenkins.install.UpgradeWizard.state manually, but that might also break the upgrade logic. What was your reason for manually changing that file?

          I think if you just remove step 3 in your process upgrades should work correctly in the future.

          Devin Nusbaum added a comment - - edited reinholdfuereder Ah, the following step breaks the upgrade detection: 3. Update 'jenkins.install.UpgradeWizard.state' and 'jenkins.install.InstallUtil.lastExecVersion' files Maybe you were manually updating jenkins.install.InstallUtil.lastExecVersion because before JENKINS-48365 was fixed in 2.96 that file was not updated correctly after an upgrade. You should not update it manually any more. Jenkins will upgrade the file itself after starting and detecting that an upgrade occured. I am not sure why you are updating jenkins.install.UpgradeWizard.state manually, but that might also break the upgrade logic. What was your reason for manually changing that file? I think if you just remove step 3 in your process upgrades should work correctly in the future.

          dnusbaum Thanks for your investigations and the hint. According to the SVN history we added that (updating both files) at the end of 2016 to "Skip jenkins setup wizard by creating files with curr version". (I must admit that I cannot remember the exact details anymore, but will try your suggestion...)

          Reinhold Füreder added a comment - dnusbaum Thanks for your investigations and the hint. According to the SVN history we added that (updating both files) at the end of 2016 to "Skip jenkins setup wizard by creating files with curr version". (I must admit that I cannot remember the exact details anymore, but will try your suggestion...)

          Devin Nusbaum added a comment - - edited

          reinholdfuereder I think that the setup wizard should be skipped automatically on upgrades in nearly all cases, but maybe the faulty upgrade detection logic was causing it to show up repeatedly. If you are still seeing the setup wizard on upgrades, then you can try passing -Djenkins.install.runSetupWizard=false to Java when starting Jenkins, which is a better way to disable the setup wizard without changing the initialization sequence. (Note: Don't do this if you are using the same code to create new instances of Jenkins (non-upgrades) unless the machine is offline/inaccessible because they will be completely insecure by default.)

          Devin Nusbaum added a comment - - edited reinholdfuereder I think that the setup wizard should be skipped automatically on upgrades in nearly all cases, but maybe the faulty upgrade detection logic was causing it to show up repeatedly. If you are still seeing the setup wizard on upgrades, then you can try passing -Djenkins.install.runSetupWizard=false to Java when starting Jenkins, which is a better way to disable the setup wizard without changing the initialization sequence. (Note: Don't do this if you are using the same code to create new instances of Jenkins (non-upgrades) unless the machine is offline/inaccessible because they will be completely insecure by default.)

          dnusbaum OK, I have now tried and tested your advice (partially) and thus removed "Update 'jenkins.install.InstallUtil.lastExecVersion' file" (part of step #3; i.e. still updating 'jenkins.install.UpgradeWizard.state' file) => and it works fine:

          1. It nicely logs the Jenkins upgrading (which was missing completely before and is a really good thing to have in the logs; both middle lines are new):
            2018-03-21 11:17:41 INFO [jenkins.InitReactorRunner$1 onAttained]   Started initialization
            2018-03-21 11:17:41 INFO [hudson.PluginManager loadDetachedPlugins]   Upgrading Jenkins. The last running version was 2.111. This Jenkins is version 2.112.
            2018-03-21 11:17:41 INFO [hudson.PluginManager loadDetachedPlugins]   Upgraded Jenkins from version 2.111 to version 2.112. Loaded detached plugins (and dependencies): []
            2018-03-21 11:17:41 INFO [jenkins.InitReactorRunner$1 onAttained]   Listed all plugins
            
          2. Also the 'jenkins.install.InstallUtil.lastExecVersion' file is written correctly by Jenkins
          3. And when not having the new JDK Tool plugin installed and upgrading from version 2.111 to 2.112 it correctly auto-installs it:
            2018-03-21 11:47:34 INFO [jenkins.InitReactorRunner$1 onAttained]   Started initialization
            2018-03-21 11:47:35 INFO [hudson.PluginManager loadDetachedPlugins]   Upgrading Jenkins. The last running version was 2.111. This Jenkins is version 2.112.
            2018-03-21 11:47:35 INFO [hudson.PluginManager loadDetachedPlugins]   Upgraded Jenkins from version 2.111 to version 2.112. Loaded detached plugins (and dependencies): [jdk-tool.hpi]
            2018-03-21 11:47:35 INFO [jenkins.InitReactorRunner$1 onAttained]   Listed all plugins
            

          => Thanks again for your help!

          There are just two minor glitches or things that could be improved:

          1. The JDK Tool plugin is auto-installed "only" in (initial release) version 1.0 – why not version 1.1 that is already available? (In the plugin manager the update to version 1.1 is correctly shown as available, so it is no big problem; not sure if it might be possible that the latest version might be needed for whatever reason – or is the minimum required version of JDK Tool plugin explicitly specified as 1.0?)
          2. Logging of Jenkins version downgrading is missing – which of course should not be a normal/regular thing to do anyhow (I am not sure if I have ever needed/did it, except for testing this issue): however, assuming it is very easy to do, why not log it out, and maybe even with level WARNING (because it is unusual or not recommended)?

          Reinhold Füreder added a comment - dnusbaum OK, I have now tried and tested your advice (partially) and thus removed "Update 'jenkins.install.InstallUtil.lastExecVersion' file" (part of step #3; i.e. still updating 'jenkins.install.UpgradeWizard.state' file ) => and it works fine: It nicely logs the Jenkins upgrading (which was missing completely before and is a really good thing to have in the logs; both middle lines are new): 2018-03-21 11:17:41 INFO [jenkins.InitReactorRunner$1 onAttained] Started initialization 2018-03-21 11:17:41 INFO [hudson.PluginManager loadDetachedPlugins] Upgrading Jenkins. The last running version was 2.111. This Jenkins is version 2.112. 2018-03-21 11:17:41 INFO [hudson.PluginManager loadDetachedPlugins] Upgraded Jenkins from version 2.111 to version 2.112. Loaded detached plugins (and dependencies): [] 2018-03-21 11:17:41 INFO [jenkins.InitReactorRunner$1 onAttained] Listed all plugins Also the 'jenkins.install.InstallUtil.lastExecVersion' file is written correctly by Jenkins And when not having the new JDK Tool plugin installed and upgrading from version 2.111 to 2.112 it correctly auto-installs it: 2018-03-21 11:47:34 INFO [jenkins.InitReactorRunner$1 onAttained] Started initialization 2018-03-21 11:47:35 INFO [hudson.PluginManager loadDetachedPlugins] Upgrading Jenkins. The last running version was 2.111. This Jenkins is version 2.112. 2018-03-21 11:47:35 INFO [hudson.PluginManager loadDetachedPlugins] Upgraded Jenkins from version 2.111 to version 2.112. Loaded detached plugins (and dependencies): [jdk-tool.hpi] 2018-03-21 11:47:35 INFO [jenkins.InitReactorRunner$1 onAttained] Listed all plugins => Thanks again for your help! There are just two minor glitches or things that could be improved: The JDK Tool plugin is auto-installed "only" in (initial release) version 1.0 – why not version 1.1 that is already available? (In the plugin manager the update to version 1.1 is correctly shown as available, so it is no big problem; not sure if it might be possible that the latest version might be needed for whatever reason – or is the minimum required version of JDK Tool plugin explicitly specified as 1.0?) Logging of Jenkins version downgrading is missing – which of course should not be a normal/regular thing to do anyhow (I am not sure if I have ever needed/did it, except for testing this issue): however, assuming it is very easy to do, why not log it out, and maybe even with level WARNING (because it is unusual or not recommended)?

          Devin Nusbaum added a comment -

          Glad to hear that everything is working!

          why not version 1.1 that is already available?

          Plugins like this that have been split from core are explicitly bundled in the war file and listed in split-plugins.txt to enable the automatic installation. jdk-tool:1.0 had to be released before Jenkins 2.112 was released, so it depends on Jenkins 2.111. This means that there is a short time where a 2.111 user could install the plugin and have multiple instances of the same class on the classpath, which is bad, so once Jenkins 2.112 was released, I updated jdk-tool to depend on Jenkins 2.112 and released 1.1, so that 1.0 is no longer available from the update center for 2.111 users. There is no issue with bundling 1.0 or 1.1 in core, but if later releases of jdk-tool have significant changes, such as adding new dependencies, we would probably not want to make those versions be bundled in Jenkins core, so it's easiest to just leave 1.0 as the bundled version, and let people upgrade naturally through the update center.

          Logging of Jenkins version downgrading is missing

          I'm not sure offhand, but feel free to open a new issue requesting that logging be added (or a pull request to https://github.com/jenkinsci/jenkins, I think the right place would be this method).

          Devin Nusbaum added a comment - Glad to hear that everything is working! why not version 1.1 that is already available? Plugins like this that have been split from core are explicitly bundled in the war file and listed in split-plugins.txt to enable the automatic installation. jdk-tool:1.0 had to be released before Jenkins 2.112 was released, so it depends on Jenkins 2.111. This means that there is a short time where a 2.111 user could install the plugin and have multiple instances of the same class on the classpath, which is bad, so once Jenkins 2.112 was released, I updated jdk-tool to depend on Jenkins 2.112 and released 1.1, so that 1.0 is no longer available from the update center for 2.111 users. There is no issue with bundling 1.0 or 1.1 in core, but if later releases of jdk-tool have significant changes, such as adding new dependencies, we would probably not want to make those versions be bundled in Jenkins core, so it's easiest to just leave 1.0 as the bundled version, and let people upgrade naturally through the update center. Logging of Jenkins version downgrading is missing I'm not sure offhand, but feel free to open a new issue requesting that logging be added (or a pull request to https://github.com/jenkinsci/jenkins , I think the right place would be this method ).

            dnusbaum Devin Nusbaum
            reinholdfuereder Reinhold Füreder
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: