Average library size does not mean anything to me. 1000 libraries (exaggerated) of 100k each is in total way more than 1 library of 1M while the average of the former is 10 times lower.
In the past I've tried once to introduce small parts of a certain framework. It only lead to way more work than I wanted since the things were not aligned. And sure the PDF, excel and whatever could be separated. For the rest, the more core functionality, I do not mind at all that it is one set of jars, and 'bloated' is I think very relative. Classes that are not needed are not loaded so....
For me it is all about ease of use etc and I'm very content with Seam in this regard.
We've gone for a totally modular approach for Seam 3, in fact there is no Seam
coreany more, although some modules may optionally depend on functionality from other modules. To see the direction that we're heading I recommend you take a look at SVN:
That looks better, 30 or more now. It's interesting how much Spring and Seam have in common. I'm wondering if Spring 3 will feature dynamic DI or will it still be static constructor or setter injection only...
Initially, the switch to Java 5 appears to be one of the big topics of Spring 3.0. However, since previous versions of the framework have already largely supported Java 5, other topics are perhaps more significant. The support of the increasingly important REST architecture further extends the new range of web features, first introduced in the previous version 2.5, and extends it to include a new operational context. The Spring Expression Language offers new possibilities for creating more flexible Spring configurations. The potential impact of this approach is also demonstrated by the length of time the introduction of an expression language has been on the wish list of Spring users: The relevant feature request has a single digit number. Conversations are directly supported in Spring. While this approach is technically required in the implementation of many web applications, developers often get by with holding the data within HTTP sessions, or through similar measures. Although conversations have been previously available in Spring Web Flow, their integration into Spring, makes them accessible to a much larger audience, while Spring Web Flow still adds a lot of additional valuable features. Finally, the Spring developers tidied up some areas, like the build management and the project's structure. They even removed some obsolete features, to ensure that in the long run, Spring remains "simple yet powerful" .
So the main items are conversation support (which I'd like to know the details of), REST support which Seam has RESTEasy as of 2.1.2, EL support, and fully modularized via OSGi so no more spring.jar.
So lots of catchup in Spring 3...
Also wondering the extent (if any) OSGi in JBoss 5 AS will play in Seam 3 apps..??