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

ROADMAP: Exploit Inversion of Control (JSR-330)

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None

      Original discussion: https://groups.google.com/d/topic/jenkinsci-dev/_cuKEAUULUE/discussion

      > - Use of IoC. (There are two branches where this is implemented, one
      >  for Guice and the other for Spring.)

          [JENKINS-8751] ROADMAP: Exploit Inversion of Control (JSR-330)

          Spring has the advantage of beeing well known and come with many more integration options,
          Guice is lighter and more focussed on IoC only
          Not so simple to choose

          Using @Inject (JSR-330) we can postpone the choice between Spring & Guice, until we get some use-case that one of them cannot address.

          Nicolas De Loof added a comment - Spring has the advantage of beeing well known and come with many more integration options, Guice is lighter and more focussed on IoC only Not so simple to choose Using @Inject (JSR-330) we can postpone the choice between Spring & Guice, until we get some use-case that one of them cannot address.

          Just noticed Sonatype is working on the same JSR-330 basis at https://github.com/sonatype/hudson-jsr330.

          Nicolas De Loof added a comment - Just noticed Sonatype is working on the same JSR-330 basis at https://github.com/sonatype/hudson-jsr330 .

          jieryn added a comment -

          I'd add that if we exclusively use JSR-330 features and not any specific provided, then Spring would be best since we already have a dependency on it for other aspects of the system.

          jieryn added a comment - I'd add that if we exclusively use JSR-330 features and not any specific provided, then Spring would be best since we already have a dependency on it for other aspects of the system.

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          changelog.html
          http://jenkins-ci.org/commit/jenkins/1b546d9699d46cc0b7a5a3481a2762fbb480e397
          Log:
          [FIXED JENKINS-8751] integrated the Guice branch.

          Classes marked as @Extension are now instantiated by Guice.

          Compare: https://github.com/jenkinsci/jenkins/compare/24b86a2...1b546d9

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html http://jenkins-ci.org/commit/jenkins/1b546d9699d46cc0b7a5a3481a2762fbb480e397 Log: [FIXED JENKINS-8751] integrated the Guice branch. Classes marked as @Extension are now instantiated by Guice. Compare: https://github.com/jenkinsci/jenkins/compare/24b86a2...1b546d9

          dogfood added a comment -

          dogfood added a comment - Integrated in jenkins_main_trunk #1149

          Jesse Glick added a comment -

          Not sure how this can be considered fixed. The acid test for using IoC in Jenkins code would be that Jenkins.getInstance() would be deprecated in favor of @Inject private final Jenkins jenkins, etc.

          Jesse Glick added a comment - Not sure how this can be considered fixed. The acid test for using IoC in Jenkins code would be that Jenkins.getInstance() would be deprecated in favor of @Inject private final Jenkins jenkins , etc.

          Daniel Beck added a comment -

          Should this be reopened then?

          Daniel Beck added a comment - Should this be reopened then?

          I don't think it's a realistic expectation that every object gets dependency injection. I suggest we keep this ticket closed, and if there are actionable specific improvements that can be made, we should track those as separate tickets.

          Kohsuke Kawaguchi added a comment - I don't think it's a realistic expectation that every object gets dependency injection. I suggest we keep this ticket closed, and if there are actionable specific improvements that can be made, we should track those as separate tickets.

          Jesse Glick added a comment -

          I don't think it's a realistic expectation that every object gets dependency injection.

          It would certainly be a realistic expectation in an application designed to use dependency injection. Jenkins is not, and probably cannot ever be compatibly refactored to be one.

          IMO the Guice integration added little benefit and just made everything more complicated.

          Jesse Glick added a comment - I don't think it's a realistic expectation that every object gets dependency injection. It would certainly be a realistic expectation in an application designed to use dependency injection. Jenkins is not, and probably cannot ever be compatibly refactored to be one. IMO the Guice integration added little benefit and just made everything more complicated.

            kohsuke Kohsuke Kawaguchi
            jieryn jieryn
            Votes:
            3 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: