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

Hide core dependencies in plugin classpath

    XMLWordPrintable

Details

    Description

      1.X is stuck with old dependencies we can't upgrade, as they are automatically set in plugin classpath and most plugins do assume those specific versions are available.

      For 2.0 we should only expose to plugin core classes but not implementation dependencies (groovy, guava, spring) and get plugin explicitly define dependencies they rely on.

      Security is a special case, as we highly depend and expose Acegi Security, but as this project is dead (rebranded as spring-security) we could just adopt it's package namespace and consider it part of jenkins-core, then delegate to spring-security, or any other security framework we select for core.

      Attachments

        Issue Links

          depends on

          Task - A task that needs to be done. JENKINS-29068 Split Groovy out of core

          • Major - Major loss of function.
          • Open
          is related to

          Improvement - An improvement or enhancement to an existing feature or task. JENKINS-36779 Upgrade Guava or properly isolate core Guava dependency from plugins

          • Major - Major loss of function.
          • Closed
          relates to

          New Feature - A new feature of the product, which has yet to be developed. JENKINS-41827 JenkinsRule mode to use realistic class loading

          • Critical - Crashes, loss of data, severe memory leak.
          • Resolved

          Task - A task that needs to be done. JENKINS-49555 Split most of Spring Framework out of core

          • Major - Major loss of function.
          • Resolved

          New Feature - A new feature of the product, which has yet to be developed. JENKINS-28942 Allow plugins to declare that they do not use certain implied dependencies

          • Major - Major loss of function.
          • Open

          Activity

            Ascending order - Click to sort in descending order
            jglick Jesse Glick added a comment -

            For binary compatibility, just as a plugin declaring a dependency on an older core gets an implicit dependency on any plugins subsequently split out, so too would it get an implicit dependency on any libraries subsequently made into plugins. Indeed there is little difference from the perspective of the plugin with the (possible) dependency whether that dependency happened to be defined in org.jenkins-ci.main:jenkins-core, some jenkins-module, or some random WEB-INF/lib/*.jar.

            jglick Jesse Glick added a comment - For binary compatibility, just as a plugin declaring a dependency on an older core gets an implicit dependency on any plugins subsequently split out, so too would it get an implicit dependency on any libraries subsequently made into plugins. Indeed there is little difference from the perspective of the plugin with the (possible) dependency whether that dependency happened to be defined in org.jenkins-ci.main:jenkins-core , some jenkins-module , or some random WEB-INF/lib/*.jar .
            teilo James Nord added a comment -

            the maven hpi lifeclye would need to fixed appropriatly so that transative deps from core are not added to the classpath causing - huh the "code compiles without warnings" type WTFs.  Also ref JENKINS-41827

            teilo James Nord added a comment - the maven hpi lifeclye would need to fixed appropriatly so that transative deps from core are not added to the classpath causing - huh the "code compiles without warnings" type WTFs.  Also ref  JENKINS-41827
            jglick Jesse Glick added a comment -

            the maven hpi lifeclye would need to fixed appropriatly so that transative deps from core are not added to the classpath

            I am not sure that is practical. Maven does not really work that way. Would rather need to change how the core dependency is declared (for example making it optional).

            jglick Jesse Glick added a comment - the maven hpi lifeclye would need to fixed appropriatly so that transative deps from core are not added to the classpath I am not sure that is practical. Maven does not really work that way. Would rather need to change how the core dependency is declared (for example making it optional ).

            People

              Unassigned Unassigned
              ndeloof Nicolas De Loof
              Votes:
              9 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

                Created:
                Updated: