CS -> Spring
I'm going to be starting the effort of moving CloudStack to be Spring managed as this is an absolute must for me (and my day job). I wanted to share some of the high level points and the scope as I see it today. Moving to Spring should not impact much code (except swapping annotations in a lot of places) as the CS code base is already written in a IoC/DI style (kudos to past developers who put that in place). Here's some of the ground rules I've use with Spring in the past and will be applying to this effort. 1. "If you import org.springframework you've done something wrong." - You should have no code dependency on Spring itself (including annotations!). The only place code dependency makes sense is in bootstrap/initialization code and extending container features like custom namespace handlers and what not. If there is any compile time dependency on spring it should be a separate spring specific module so that other modules have Spring dependencies as runtime and not compile. 2. JSR250 and JSR330 should be used for annotations. So specifically this means using the standard @Inject, @PostConstruct, @PreDestroy annotations. 3. Autowiring by type can/should be used. If there is no unique dependencies, named dependencies can be specified with the standard @Resource annotation, or @Qualifier (following JSR330) should be used. 4. Component scanning should not be used - This means no auto discovery of beans using the @Named (@Bean for the spring specific annotation) annotation. This is typically a controversial point. A lot of people like component scanning as you can avoid registering beans in XML (and everybody hates XML). The problem with component scanning is that for large projects with a lot of developers it tends to be too much magic and confuses most developers when debugging. At runtime a component gets injected and they have no clue where it came from or what it is. So still using XML to register beans is very helpful for people to understand the system. Additionally its annoying when one want to not register a bean and than means removing it from the classpath (typically, I'm sure their are other hooks) 5. Spring is not the center of the world! - Just because we use Spring IoC doesn't mean that every other spring framework (Spring-WS, Spring Securiy, Spring Integration, etc) is somehow the best choice for the project. Spring based frameworks need to be evaluated on their own merits and not only on the fact that it's name starts with "Spring". The scope of changes will mostly be around the ComponentLocator. The ComponentLocator currently does instantiation, lifecycle, configuration injecting, AOP, and probably some other stuff. So all of these feature already exist in Spring in some fashion. So I'll be dissecting the ComponentLocator and removing functionality that Spring will do. I'm still toying with what to do with the Manager and Adapter interfaces as these primarily just define lifecycle methods. Spring will apply lifecycle to all beans (using the normal @PostConstruct, @PreDestroy) so those interface methods don't provide much value. The configure() method can also be done in a more generic fashion also. So Adapter and Manager may just become marker interfaces. Moving to Spring also starts laying the foundation for a simpler component and plugin model. With Spring we can easily get to the point where somebody builds a plug-in as a jar and puts it on the classpath and Spring finds it and registers it as a plugin. I have plenty of thoughts around this, but I'll leave that for later. Darren
RE: CS -> Spring
Darren, This is not going into 4.0 release right? Also between maven and spring framework which one are you planning to do first? The other thread regarding build system seems to be coming to a consensus when the 4.0 release date is pushed back. --Alex > -Original Message- > From: Darren Shepherd [mailto:dar...@godaddy.com] > Sent: Saturday, August 18, 2012 10:16 AM > To: cloudstack-dev@incubator.apache.org > Subject: CS -> Spring > > I'm going to be starting the effort of moving CloudStack to be Spring > managed as this is an absolute must for me (and my day job). I wanted to > share some of the high level points and the scope as I see it today. > > Moving to Spring should not impact much code (except swapping > annotations in a lot of places) as the CS code base is already written in a > IoC/DI style (kudos to past developers who put that in place). > Here's some of the ground rules I've use with Spring in the past and will be > applying to this effort. > > 1. "If you import org.springframework you've done something wrong." - You > should have no code dependency on Spring itself (including annotations!). > The only place code dependency makes sense is in bootstrap/initialization > code and extending container features like custom namespace handlers and > what not. If there is any compile time dependency on spring it should be a > separate spring specific module so that other modules have Spring > dependencies as runtime and not > compile. > > 2. JSR250 and JSR330 should be used for annotations. So specifically this > means using the standard @Inject, @PostConstruct, @PreDestroy > annotations. > > 3. Autowiring by type can/should be used. If there is no unique > dependencies, named dependencies can be specified with the standard > @Resource annotation, or @Qualifier (following JSR330) should be used. > > 4. Component scanning should not be used - This means no auto discovery of > beans using the @Named (@Bean for the spring specific annotation) > annotation. This is typically a controversial point. A lot of people like > component scanning as you can avoid registering beans in XML (and > everybody hates XML). The problem with component scanning is that for > large projects with a lot of developers it tends to be too much magic and > confuses most developers when debugging. At runtime a component gets > injected and they have no clue where it came from or what it is. > So still using XML to register beans is very helpful for people to understand > the system. Additionally its annoying when one want to not register a bean > and than means removing it from the classpath (typically, I'm sure their are > other hooks) > > 5. Spring is not the center of the world! - Just because we use Spring IoC > doesn't mean that every other spring framework (Spring-WS, Spring Securiy, > Spring Integration, etc) is somehow the best choice for the project. Spring > based frameworks need to be evaluated on their own merits and not only on > the fact that it's name starts with "Spring". > > > The scope of changes will mostly be around the ComponentLocator. The > ComponentLocator currently does instantiation, lifecycle, configuration > injecting, AOP, and probably some other stuff. So all of these feature > already exist in Spring in some fashion. So I'll be dissecting the > ComponentLocator and removing functionality that Spring will do. I'm still > toying with what to do with the Manager and Adapter interfaces as these > primarily just define lifecycle methods. Spring will apply lifecycle to all > beans > (using the normal @PostConstruct, @PreDestroy) so those interface > methods don't provide much value. The configure() method can also be > done in a more generic fashion also. So Adapter and Manager may just > become marker interfaces. > > Moving to Spring also starts laying the foundation for a simpler component > and plugin model. With Spring we can easily get to the point where > somebody builds a plug-in as a jar and puts it on the classpath and Spring > finds it and registers it as a plugin. I have plenty of thoughts around > this, but > I'll leave that for later. > > Darren > > >
RE: [DISCUSS] Please choose: The build system to use for 4.0
All, So I have maven fully functional. I sent an email regarding this but being that it wasn't on this thread so it probably went un-noticed. So below is basically a copy of that. If you want to get an idea of what maven would look like for CS, what I've done is on the "maven" branch at https://github.com/ibuildthecloud/incubator-cloudstack.git I had to setup a custom repo to put all the non-oss libraries that don't exist in the central maven repo. To build just do "mvn -s m2-settings.xml" That settings file will create a local repo (not use ~/.m2/repository) because I was testing that all dependencies are coming from where I expected and not polluted by other maven stuff I do. Its a multi module project so you can do things like "mvn -s m2-settings -am -pl server" to just build the server portion (or core, or one of the tons of plugins). I also tested that the build works with maven 2 and maven 3 and that the Eclipse M2E plugin works with it too. I would love it if a maven god could review what I've done. If we're all good with maven I'll gladly take this to full completion and start submitting patches. Post 4.0 we can always improve (and I'm sure we will), but I feel I know what's the bare minimum need to get this out the door and I can do that (plus whatever nice to haves I can squeek in). Regarding the dev environment setup. We can do this with whatever little amount of impact we want. Once you have the maven pom's you just install Eclipse M2E (thats an eclipse foundation project) and then say "Import Existing Maven Projects" and then magic ensues. The M2E plugin works pretty darn well. It also has the great benefit that you can stop checking in .classpath and .project files in the your version control because the pom.xml has all the metadata Eclipse M2E needs to create a project. So my preferred approach would be to checkin the pom's and then delete the .classpath and .project files from git and have developers re-import their projects into eclipse. If people don't like that I can use some magic with the mvn depenendency:copy-dependencies to recreate the same structure as whats in deps today to make the eclipse projects still work. But I would grudgingly do that work as I would rather we just move forward with a standard maven layout. Gotta learn sometime and I don't think its all that difficult. Regarding the ant tasks, I want to keep backwards compatibilty so that the main ant tasks still work but just internally call maven and not javac/jar directly. So I vote we just let me do this and I'll get 'er done. Darren > Original Message > Subject: RE: [DISCUSS] Please choose: The build system to use for 4.0 > From: Ewan Mellor > Date: Fri, August 17, 2012 2:22 pm > To: "cloudstack-dev@incubator.apache.org" > > > > Well, all our packages are going to be public, of course. That shouldn't be > a problem! > > Ewan. > > > -Original Message- > > From: Marcus Sorensen [mailto:shadow...@gmail.com] > > Sent: 17 August 2012 14:19 > > To: cloudstack-dev@incubator.apache.org > > Subject: Re: [DISCUSS] Please choose: The build system to use for 4.0 > > > > I'm totally fine with a switch, my only concern was around when it's done. > > Aside from just implementing the build bits in the git repo (sounds like > > there > > are resources for this), I picture there being a bit of work on every > > developer's part to switch their dev environments. This might be as simple > > as > > a few package installs, but on at least one occasion when I was building > > something via Maven I had to spend the better part of an afternoon going > > back and forth with the network/systems guys because Maven needed to > > download some components and the applicable systems by default are > > internal-access only. It's things like that where I worry about switching > > build > > systems when people are under a crunch to complete 4.0. > > > > On Fri, Aug 17, 2012 at 2:04 PM, Ewan Mellor > > wrote: > > > OK, so we've got offers of effort on Maven from Darren, Hugo, plus review > > help from Olivier and Alex. Maven gets +1 from me, Alex, and Brett too. > > > > > > On the Ant side we've got +1 from Chip ("based on timeline"), Wido, > > Marcus, and Mice. David has his deps-ctrl branch, but no-one has offered to > > finish the job. > > > > > > We have consensus that the release is going to slip by at least 3 weeks > > > (2 at > > the front and one at the end), which gives us four weeks total to get the > > build system done and debugged (i.e. between now and final release > > candidate on Sep 14). > > > > > > With that extra time, does that change anyone's opinion? It would be nice > > to get consensus on this issue, otherwise we're going to have to put it to a > > vote. > > > > > > Thanks, > > > > > > Ewan. > > > > > > > > >> -Original Message- > > >> From: akaras...@gmail.com [mailto:akaras...@gmail.com] On Behalf Of > > >> Alex Karasulu > > >> Sent: 17 August 2012 03
RE: CS -> Spring
Alex, This is definitely post-4.0. I'm just throwing the info out there of what I'm thinking of doing just to see if there are any major objections. Regarding maven, I responded on the main thread for this just now, so refer to that. Basically I've been waiting for a decision. I hadn't been following the mailing list most of the week and therefore wasn't too sure what was up with that. Darren > Original Message > Subject: RE: CS -> Spring > From: Alex Huang > Date: Sat, August 18, 2012 12:46 pm > To: "cloudstack-dev@incubator.apache.org" > > > > Darren, > > > > This is not going into 4.0 release right? > > > > Also between maven and spring framework which one are you planning to do > first? The other thread regarding build system seems to be coming to a > consensus when the 4.0 release date is pushed back. > > > > --Alex > > > > > -Original Message- > > > From: Darren Shepherd [mailto:dar...@godaddy.com] > > > Sent: Saturday, August 18, 2012 10:16 AM > > > To: cloudstack-dev@incubator.apache.org > > > Subject: CS -> Spring > > > > > > I'm going to be starting the effort of moving CloudStack to be Spring > > > managed as this is an absolute must for me (and my day job). I wanted to > > > share some of the high level points and the scope as I see it today. > > > > > > Moving to Spring should not impact much code (except swapping > > > annotations in a lot of places) as the CS code base is already written in a > > > IoC/DI style (kudos to past developers who put that in place). > > > Here's some of the ground rules I've use with Spring in the past and will be > > > applying to this effort. > > > > > > 1. "If you import org.springframework you've done something wrong." - You > > > should have no code dependency on Spring itself (including annotations!). > > > The only place code dependency makes sense is in bootstrap/initialization > > > code and extending container features like custom namespace handlers and > > > what not. If there is any compile time dependency on spring it should be a > > > separate spring specific module so that other modules have Spring > > > dependencies as runtime and not > > > compile. > > > > > > 2. JSR250 and JSR330 should be used for annotations. So specifically this > > > means using the standard @Inject, @PostConstruct, @PreDestroy > > > annotations. > > > > > > 3. Autowiring by type can/should be used. If there is no unique > > > dependencies, named dependencies can be specified with the standard > > > @Resource annotation, or @Qualifier (following JSR330) should be used. > > > > > > 4. Component scanning should not be used - This means no auto discovery of > > > beans using the @Named (@Bean for the spring specific annotation) > > > annotation. This is typically a controversial point. A lot of people like > > > component scanning as you can avoid registering beans in XML (and > > > everybody hates XML). The problem with component scanning is that for > > > large projects with a lot of developers it tends to be too much magic and > > > confuses most developers when debugging. At runtime a component gets > > > injected and they have no clue where it came from or what it is. > > > So still using XML to register beans is very helpful for people to > > understand > > > the system. Additionally its annoying when one want to not register a bean > > > and than means removing it from the classpath (typically, I'm sure their are > > > other hooks) > > > > > > 5. Spring is not the center of the world! - Just because we use Spring IoC > > > doesn't mean that every other spring framework (Spring-WS, Spring Securiy, > > > Spring Integration, etc) is somehow the best choice for the project. Spring > > > based frameworks need to be evaluated on their own merits and not only on > > > the fact that it's name starts with "Spring". > > > > > > > > > The scope of changes will mostly be around the ComponentLocator. The > > > ComponentLocator currently does instantiation, lifecycle, configuration > > > injecting, AOP, and probably some other stuff. So all of these feature > > > already exist in Spring in some fashion. So I'll be dissecting the > > > ComponentLocator and removing functionality that Spring will do. I'm still > > > toying with what to do with the Manager and Adapter interfaces as these > > > primarily just define lifecycle methods. Spring will apply lifecycle to > > all beans > > > (using the normal @PostConstruct, @PreDestroy) so those interface > > > methods don't provide much value. The configure() method can also be > > > done in a more generic fashion also. So Adapter and Manager may just > > > become marker interfaces. > > > > > > Moving to Spring also starts laying the foundation for a simpler component > > > and plugin model. With Spring we can easily get to the point where > > > somebody builds a plug-in as a jar and puts it o
Re: [DOCS] Cloudbridge needs new documentation
Hi Jessica et al, I migrated the S3 wiki page to the new wiki, the S3 doc is now at: https://cwiki.apache.org/confluence/display/CLOUDSTACK/S3+API+in+CloudStack I put a redirect on the old page, I don't know if someone can actually lock the edit. Next, I will work on migrating the pdf info into publican (hopefully tomorrow), using the content from CP and cross checking with what was in the old cloudbridge guide. -sebastien On Aug 16, 2012, at 6:49 AM, Jessica Tomechak wrote: > Sebastien/Alex/et al: Thanks very much for noticing these questions. Please > see: > > > http://bugs.cloudstack.org/browse/CS-15604 > > > The EC2 content from CP, as well as the rest of the Installation Guide, > still needs to be moved to publican, as this bug states. We need to create > an Apache CloudStack version of this Citrix guide: > > > > http://support.citrix.com/article/CTX133611 > > > > First step: if the CloudStack team can determine right now which parts of > the Citrix guide won’t apply, we can avoid even porting those sections to > the Apache repo. Productivity win. Would someone like to volunteer to > compile such a list and add it as a comment to the bug CS-15604? > > > And would someone in the email exchange below be volunteering to convert > the old cloudbridge content to publican-friendly docbook XML? > > > Also: Love the [DOCS] subject line tag. > > > Jessica T. > CloudStack Tech Pubs > > -Original Message- >> From: Alex Huang [mailto:alex.hu...@citrix.com] >> Sent: Tuesday, August 14, 2012 3:02 PM >> To: cloudstack-dev@incubator.apache.org >> Cc: Ewan Mellor >> Subject: RE: [DOCS] Cloudbridge needs new documentation >> >> The point is still valid though. Even though there's information, there >> needs to be official doc. I think we should file this as a bug for the 4.0 >> release. Ewan? >> >> --Alex >> >>> -Original Message- >>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] >>> Sent: Tuesday, August 14, 2012 2:39 PM >>> To: CloudStack DeveloperList >>> Subject: Re: [DOCS] Cloudbridge needs new documentation >>> >>> S3 information is documented here: >>> http://wiki.cloudstack.org/display/RelOps/S3+API+in+CloudStack >>> >>> >>> >>> On 8/14/12 1:57 PM, "Prachi Damle" wrote: >>> The slides cover pretty much everything that is documented in the CP install guide for enabling EC2. The CP install guide covers all the APIs that are supported via EC2 Soap. So whatever CP install guide mentions can be used for 4.0 docs as well. I am not sure about S3 documentation. Thanks, Prachi -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Tuesday, August 14, 2012 1:20 PM To: cloudstack-dev@incubator.apache.org Subject: [DOCS] Cloudbridge needs new documentation Hi everyone, I have been looking at what used to be cloudbridge and is now an integral part of CS. The old documentation for cloudbridge is at: http://docs.cloudstack.org/@api/deki/files/165/CloudBridgeGuide.pdf It does not seem to have been moved to /docs in publican format. The "new" documentation is quite different and will be close (or equal) to the cloudplatform docs at: http://support.citrix.com/servlet/KbServlet/download/31038-102-684646 /C lou dPlatform3.0.3_3.0.4InstallGuide.pdf For cloudbridge from p.153 to p.163 which includes a listing of the supported ec2 commands. Neither of these have information about S3. I put some slides up about how I believe things need to be configured to get EC2 working: http://www.slideshare.net/sebastiengoasguen/cloudstack-ec2- >>> configuratio n What do you all think should be in the docs or not ? Has anyone been looking at this ? Can we take what's in the CP doc and move it straight to publican ? Also what about S3 ? I don't think there is any documentation about it yet, and it may not be production ready yet. Thoughts, -Sebastien -Sebastien Goasguen Cloud Computing Evangelist, Citrix EMEA >> >> -Sebastien Goasguen Cloud Computing Evangelist, Citrix EMEA
Re: CS -> Spring
Darren, I'll start some coding on architecture refactoring work at "javelin" branch, and I'll use Spring too. Should we share the same branch? I've pushed the branch to the ASF repo already Kelven On 8/18/12 6:59 PM, "Darren Shepherd" wrote: >Alex, > >This is definitely post-4.0. I'm just throwing the info out there of >what I'm thinking of doing just to see if there are any major >objections. > >Regarding maven, I responded on the main thread for this just now, so >refer to that. Basically I've been waiting for a decision. I hadn't >been following the mailing list most of the week and therefore wasn't >too sure what was up with that. > >Darren > > > > >> Original Message >> Subject: RE: CS -> Spring >> From: Alex Huang >> Date: Sat, August 18, 2012 12:46 pm >> To: "cloudstack-dev@incubator.apache.org" >> >> >> >> Darren, >> >> >> >> This is not going into 4.0 release right? >> >> >> >> Also between maven and spring framework which one are you planning to >>do first? The other thread regarding build system seems to be coming to >>a consensus when the 4.0 release date is pushed back. >> >> >> >> --Alex >> >> >> >> > -Original Message- >> >> > From: Darren Shepherd [mailto:dar...@godaddy.com] >> >> > Sent: Saturday, August 18, 2012 10:16 AM >> >> > To: cloudstack-dev@incubator.apache.org >> >> > Subject: CS -> Spring >> >> > >> >> > I'm going to be starting the effort of moving CloudStack to be Spring >> >> > managed as this is an absolute must for me (and my day job). I >>wanted to >> >> > share some of the high level points and the scope as I see it today. >> >> > >> >> > Moving to Spring should not impact much code (except swapping >> >> > annotations in a lot of places) as the CS code base is already >>written in a >> >> > IoC/DI style (kudos to past developers who put that in place). >> >> > Here's some of the ground rules I've use with Spring in the past and >>will be >> >> > applying to this effort. >> >> > >> >> > 1. "If you import org.springframework you've done something wrong." - >>You >> >> > should have no code dependency on Spring itself (including >>annotations!). >> >> > The only place code dependency makes sense is in >>bootstrap/initialization >> >> > code and extending container features like custom namespace handlers >>and >> >> > what not. If there is any compile time dependency on spring it >>should be a >> >> > separate spring specific module so that other modules have Spring >> >> > dependencies as runtime and not >> >> > compile. >> >> > >> >> > 2. JSR250 and JSR330 should be used for annotations. So specifically >>this >> >> > means using the standard @Inject, @PostConstruct, @PreDestroy >> >> > annotations. >> >> > >> >> > 3. Autowiring by type can/should be used. If there is no unique >> >> > dependencies, named dependencies can be specified with the standard >> >> > @Resource annotation, or @Qualifier (following JSR330) should be used. >> >> > >> >> > 4. Component scanning should not be used - This means no auto >>discovery of >> >> > beans using the @Named (@Bean for the spring specific annotation) >> >> > annotation. This is typically a controversial point. A lot of >>people like >> >> > component scanning as you can avoid registering beans in XML (and >> >> > everybody hates XML). The problem with component scanning is that for >> >> > large projects with a lot of developers it tends to be too much magic >>and >> >> > confuses most developers when debugging. At runtime a component gets >> >> > injected and they have no clue where it came from or what it is. >> >> > So still using XML to register beans is very helpful for people to >>understand >> >> > the system. Additionally its annoying when one want to not register >>a bean >> >> > and than means removing it from the classpath (typically, I'm sure >>their are >> >> > other hooks) >> >> > >> >> > 5. Spring is not the center of the world! - Just because we use >>Spring IoC >> >> > doesn't mean that every other spring framework (Spring-WS, Spring >>Securiy, >> >> > Spring Integration, etc) is somehow the best choice for the project. >>Spring >> >> > based frameworks need to be evaluated on their own merits and not >>only on >> >> > the fact that it's name starts with "Spring". >> >> > >> >> > >> >> > The scope of changes will mostly be around the ComponentLocator. The >> >> > ComponentLocator currently does instantiation, lifecycle, >>configuration >> >> > injecting, AOP, and probably some other stuff. So all of these >>feature >> >> > already exist in Spring in some fashion. So I'll be dissecting the >> >> > ComponentLocator and removing functionality that Spring will do. I'm >>still >> >> > toying with what to do with the Manager and Adapter interfaces as >>these >> >> > primarily just define lifecycle methods. Spring will apply lifecycle >>to all beans >> >> > (using the normal @PostConstruc
RE: CS -> Spring
Kelven, That makes sense. I'm not a committer so I'll probably be working off my github account, but I'll base my branch off of javelin. Darren > Original Message > Subject: Re: CS -> Spring > From: Kelven Yang > Date: Sat, August 18, 2012 7:31 pm > To: "cloudstack-dev@incubator.apache.org" > > > > Darren, > > I'll start some coding on architecture refactoring work at "javelin" > branch, and I'll use Spring too. Should we share the same branch? I've > pushed the branch to the ASF repo already > > Kelven > > > On 8/18/12 6:59 PM, "Darren Shepherd" wrote: > > >Alex, > > > >This is definitely post-4.0. I'm just throwing the info out there of > >what I'm thinking of doing just to see if there are any major > >objections. > > > >Regarding maven, I responded on the main thread for this just now, so > >refer to that. Basically I've been waiting for a decision. I hadn't > >been following the mailing list most of the week and therefore wasn't > >too sure what was up with that. > > > >Darren > > > > > > > > > >> Original Message > >> Subject: RE: CS -> Spring > >> From: Alex Huang > >> Date: Sat, August 18, 2012 12:46 pm > >> To: "cloudstack-dev@incubator.apache.org" > >> > >> > >> > >> Darren, > >> > >> > >> > >> This is not going into 4.0 release right? > >> > >> > >> > >> Also between maven and spring framework which one are you planning to > >>do first? The other thread regarding build system seems to be coming to > >>a consensus when the 4.0 release date is pushed back. > >> > >> > >> > >> --Alex > >> > >> > >> > >> > -Original Message- > >> > >> > From: Darren Shepherd [mailto:dar...@godaddy.com] > >> > >> > Sent: Saturday, August 18, 2012 10:16 AM > >> > >> > To: cloudstack-dev@incubator.apache.org > >> > >> > Subject: CS -> Spring > >> > >> > > >> > >> > I'm going to be starting the effort of moving CloudStack to be Spring > >> > >> > managed as this is an absolute must for me (and my day job). I > >>wanted to > >> > >> > share some of the high level points and the scope as I see it today. > >> > >> > > >> > >> > Moving to Spring should not impact much code (except swapping > >> > >> > annotations in a lot of places) as the CS code base is already > >>written in a > >> > >> > IoC/DI style (kudos to past developers who put that in place). > >> > >> > Here's some of the ground rules I've use with Spring in the past and > >>will be > >> > >> > applying to this effort. > >> > >> > > >> > >> > 1. "If you import org.springframework you've done something wrong." - > >>You > >> > >> > should have no code dependency on Spring itself (including > >>annotations!). > >> > >> > The only place code dependency makes sense is in > >>bootstrap/initialization > >> > >> > code and extending container features like custom namespace handlers > >>and > >> > >> > what not. If there is any compile time dependency on spring it > >>should be a > >> > >> > separate spring specific module so that other modules have Spring > >> > >> > dependencies as runtime and not > >> > >> > compile. > >> > >> > > >> > >> > 2. JSR250 and JSR330 should be used for annotations. So specifically > >>this > >> > >> > means using the standard @Inject, @PostConstruct, @PreDestroy > >> > >> > annotations. > >> > >> > > >> > >> > 3. Autowiring by type can/should be used. If there is no unique > >> > >> > dependencies, named dependencies can be specified with the standard > >> > >> > @Resource annotation, or @Qualifier (following JSR330) should be used. > >> > >> > > >> > >> > 4. Component scanning should not be used - This means no auto > >>discovery of > >> > >> > beans using the @Named (@Bean for the spring specific annotation) > >> > >> > annotation. This is typically a controversial point. A lot of > >>people like > >> > >> > component scanning as you can avoid registering beans in XML (and > >> > >> > everybody hates XML). The problem with component scanning is that for > >> > >> > large projects with a lot of developers it tends to be too much magic > >>and > >> > >> > confuses most developers when debugging. At runtime a component gets > >> > >> > injected and they have no clue where it came from or what it is. > >> > >> > So still using XML to register beans is very helpful for people to > >>understand > >> > >> > the system. Additionally its annoying when one want to not register > >>a bean > >> > >> > and than means removing it from the classpath (typically, I'm sure > >>their are > >> > >> > other hooks) > >> > >> > > >> > >> > 5. Spring is not the center of the world! - Just because we use > >>Spring IoC > >> > >> > doesn't mean that every other spring framework (Spring-WS, Spring > >>Securiy, > >> > >> > Spring Integration, etc) is somehow the best choice for the project. > >>Spring > >> > >> > based frameworks need to be evaluated on their own merits and not > >>only on > >> > >> > the fact that it's