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 <alex.hu...@citrix.com> > Date: Sat, August 18, 2012 12:46 pm > To: "cloudstack-dev@incubator.apache.org" > <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 <scope>runtime</scope> and not > > > <scope>compile</scope>. > > > > > > 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 > > > > > > > > >
