This is an interesting discussion for me, because I was an architect at ATG back when DAS and Nucleus were invented; now I'm working at Allurent and using Spring DI quite happily as a useful tool which offers much of what Nucleus had to offer, at the much more appropriate price (for basic programming infrastructure) of zero. I would not want to develop any large-scale server application without either Nucleus or Spring.
I didn't write Nucleus -- I contributed the odd enhancement or bug fix to it -- but I'm very familiar with the thinking that took place around its creation and afterwards. The comments in this thread are eerily similar to the many internal debates we had about Nucleus' separability from the rest of the platform and the wisdom of releasing part (or even all) of DAS as open source.
I think it's fair to say that Nucleus and Spring share a core of common goals. Nucleus was designed consciously as a dependency-injection framework, although that particular piece of jargon did not exist at the time -- we referred to Nucleus as a "lightweight component system". This was not a sideways jibe at EJBs, which didn't exist yet either. For that matter, neither did J2EE. Servlets themselves were barely in existence. The "ATG vs J2EE" issues that hounded the platform came into being later as a direct consequence of ATG being on the scene so early, and developing a strategy for standards coexistence so late.
Each system has its unique strengths that I appreciate. Nucleus' configuration layers and runtime inspection/modification tools are very powerful -- the runtime admin in particular, which is comparable to a JMX UI for lightweight components. On the other hand Spring (at least, the DI part of it) has a simpler and cleaner API, AOP, more general hooks to bean initialization code, and has the capability to define arbitrary scopes (though it will be nice to have shrink-wrapped request and session scopes). I note that someone, if so inclined, could add configuration layers to Spring merely by performing some XML preprocessing (which is sort of how they were added to Nucleus itself, which did not originally support them).
It's always interesting to speculate on what might have happened, but we'll never have the luxury of knowing. ATG did not make Nucleus available to developers at large, partly because management believed it to be part of a proprietary advantage to the Dynamo platform -- and indeed, Dynamo exploits the lightweight component concept in a comprehensive way that still requires a fair bit of work to achieve in J2EE using multiple open source packages. But tven if they had opened it up, there would have been room for Spring, HiveMind, and so on to improve on the earlier ideas, and 10 years is a long lifetime for a first cut at an idea to survive. It is interesting that Spring developers appear not to have known much about Nucleus, and yet they developed something strikingly similar in approach. To me that is a validation of the aims of Nucleus, if not its actual substance.
Anyway, I think Nucleus and Spring DI are both good and useful things. In the current ecology of the server-side Java world, if you're a developer looking for DI and lightweight components, Spring is currently the best thing out there. Dynamo costs much more, but is the right fit for a project that can exploit the broader scope of what's found in ATG beyond Nucleus, repositories and DAS.
... . . . joe