> Can you elaborate? If there is some optimization in Jenkins core that would be beneficial, why not just do it now? What I am doing could be applied to the core when immutable configurations are used, e.g. for plugins and Jenkins core defined in Docker images. If we preprocess plugin manifests, it can slightly improve the startup time. Same for more efficient build-time extension indexing that I also keep in mind.
I would not like to do these changes right away in the core because of the following reasons: - Jenkins Docker images do not have big size overhead for HPIs, compared to Jenkinsfile runner which has different packaging flow (without some tweaks, plugins are basically included twice). - Performance improvement would be available only for a subset of users - Performance improvements have relatively low impact for classic Jenkins setups. If we wanted to improve startup time there, we should be looking at lazy job loading, not at plugin manifest indexing - Last but not least, the implementation overhead and quality requirements are much higher for the Jenkins core than for JFR which is still in Beta Based on the reasons above, I would like to have a working implementation in JFR before we discuss including bits of it into the Jenkins core. BR, Oleg On Monday, November 23, 2020 at 4:03:05 PM UTC+1 Jesse Glick wrote: > On Mon, Nov 23, 2020 at 9:00 AM Oleg Nenashev <[email protected]> wrote: > > Jenkins still needs an exploded HPI file to read the plugin manifests. > > Can you elaborate? If there is some optimization in Jenkins core that > would be beneficial, why not just do it now? > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/c5d65dcd-faa3-4cca-9c38-0df28281ed0an%40googlegroups.com.
