Skip to content

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

Closed

Description

@jenkins-infra-bot

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


Originally reported by jieryn, imported from: ROADMAP: Exploit Inversion of Control (JSR-330)
  • assignee: kohsuke
  • status: Resolved
  • priority: Major
  • component(s): core
  • resolution: Fixed
  • resolved: 2011-09-23T22:19:53+00:00
  • votes: 3
  • watchers: 7
  • imported: 2025-11-24
Raw content of original issue

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

Activity

  1. jenkins-infra-bot commented on Feb 11, 2011

    @jenkins-infra-bot
    Author
    ndeloof:
    • Original comment link
    • Raw content of original 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.

    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.

  2. jenkins-infra-bot commented on Feb 11, 2011

    @jenkins-infra-bot
    Author
    ndeloof:

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

  3. jenkins-infra-bot commented on Feb 11, 2011

    @jenkins-infra-bot
    Author
    jieryn:
    • Original comment link
    • Raw content of original 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.

    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.

  4. jenkins-infra-bot commented on Sep 23, 2011

    @jenkins-infra-bot
    Author
    scm_issue_link:

    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: 24b86a2...1b546d9

  5. jenkins-infra-bot commented on Sep 23, 2011

    @jenkins-infra-bot
    Author
    dogfood:

    Integrated in jenkins_main_trunk #1149

  6. jenkins-infra-bot commented on Nov 7, 2012

    @jenkins-infra-bot
    Author
    jglick:
    • Original comment link
    • Raw content of original 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.

    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.

  7. jenkins-infra-bot commented on May 25, 2014

    @jenkins-infra-bot
    Author
    danielbeck:
    • Original comment link
    • Raw content of original comment:

      Should this be reopened then?

    Should this be reopened then?

  8. jenkins-infra-bot commented on May 25, 2014

    @jenkins-infra-bot
    Author
    kohsuke:
    • Original comment link
    • Raw content of original 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.

    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.

  9. jenkins-infra-bot commented on May 27, 2014

    @jenkins-infra-bot
    Author
    jglick:
    • Original comment link
    • Raw content of original 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.

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions