Java EE 6 and Spring 3 became very similar - at least the resulting architecture and even design will differ only in details (see also Juergen Hoeller comment). I don't expect differences in development lifecycle either - e.g. Glassfish deployment (changing a JPA entity or a Session Bean) takes only a few hundred milliseconds - but you could achieve the same easily with Spring as well (there is no reason, why not).

Spring also comes with own server. Spring has (since October 7th, 2008) similar maintenance policies to opensource servers with commercial support. If you would like to have patches for an older Spring-version - you will have to buy commercial support from SpringSource / VMWare. For serious projects you will have to sign two maintenance and support contracts - one with your application server vendor and the another one with SpringSource. That is very hard to justify having Java EE 5 / 6 in place. In mid term I only see this two options:

1. Deploying Spring on the "proprietary" tc Server
2. Deploying Java EE 6 applications without Spring (you could build them with Spring support, but deployment to production will be the issue)

All the migration projects will also have to make this decision, whether they will stick with Java EE, or migrate straight to Spring. This decision has nothing to do with technology - and a lot with business / strategy / politics. You could of course build Spring from source and deliver a binary by yourself. Delivering an uncertified, un-indemnified "custom" Spring-build would be impossible for "mission critical" and very hard for most commercial projects. The future of Enterprise Java is very clear - full stack Spring or full stack Java EE - but no mix any more.

From http://www.adam-bien.com