You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[JENKINS-8751] ROADMAP: Exploit Inversion of Control (JSR-330) #15612
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.
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.
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.
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.
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.
Activity
jenkins-infra-bot commentedon Feb 11, 2011
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.
jenkins-infra-bot commentedon Feb 11, 2011
Raw content of original comment:
Just noticed Sonatype is working on the same JSR-330 basis at https://github.com/sonatype/hudson-jsr330.
jenkins-infra-bot commentedon Feb 11, 2011
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.
jenkins-infra-bot commentedon Sep 23, 2011
Raw content of original 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: 24b86a2...1b546d9
jenkins-infra-bot commentedon Sep 23, 2011
Raw content of original comment:
Integrated in
jenkins_main_trunk #1149
jenkins-infra-bot commentedon Nov 7, 2012
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.
jenkins-infra-bot commentedon May 25, 2014
Raw content of original comment:
Should this be reopened then?
jenkins-infra-bot commentedon May 25, 2014
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.
jenkins-infra-bot commentedon May 27, 2014
Raw content of original comment:
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.