• Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • core

      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.

          [JENKINS-30685] Hide core dependencies in plugin classpath

          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.

          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 .

          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

          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

          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).

          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 ).

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

              Created:
              Updated: