I expect this and that's the reason why I think that a stable 2.2 release will take some time (I think that's not a matter of a few months but much more) and why I like Carsten's proposal.
Grmbl. Bruno and I were just trying to argumentize against each other about both scenarios, and I'm stuck with a few issues that I would like the repository reshuffling see resolve.
Here's some feelings (not facts) I want to share with this discussion:
1) There's a decent amount of (positive!) FUD about the new blocks. All in all, I don't think that the actual coding of the new classloading and block deployment architecture code is much more cumbersome that what Sylvain once did with the TreeProcessor, and Stefano did with the build system. Yes, it will take time, but it's just a matter of finding time, motivation and energy to do the job. We tend to discuss for a long time about such issues, possibly longer than the actual coding actually requires. In the end, it's about getting on with it, and someone (which we will be very grateful for) diving deep into it and resurfacing when it's done. Ditto with Fortress. I'm naively hoping that some F2F time during the GT will help in finding that energy, and getting some commitment from people who need to shift between for-pay and for-free work on a daily basis.
2) My main concern with all this restructuring is however release management, and the user-facing perspective of our community work. We need to arrive to a situation where blocks can be independently released from Cocoon core releases, so that people who feel a faster drive to work on specific features can get on with the job, without being demotivated by long periods of no releases due to one zillion dependencies. So maybe we should move all blocks code into a separate module, and establish an independent release schedule (at the whim of the actual block release manager) for them.
3) This brings us to the eternal discussion about the definition of core and non-core. Maybe, be splitting out block code from the main module, and actively trying to slim down the main one even more, we will end up with a better community sense of what can be considered 'core', and what should be consired a block. We could even consider the TraxTransformer a block on its own, if we restrict the core to the pipeline, caching, sitemap and flow machinery. We could envision a packaged stable build of Cocoon which includes the core and then some core blocks. The rest is developed and released on its own schedule, and can, given the dependency checking in the new blocks paradigm shift (yes, it's more about a shift of perception than actual rearchitecturing) be safely released outside the main release schedule.
This is just a quick braindump of my current feelings about all this. Hopefully it can contribute positively to this recurring discussion. Ending on a filosophical note: in the end, we should be driven by hope, not by fear. If we manage to come up with a stable 2.1.2 release within some weeks, I'm pretty sure our users have plenty of new, stable releases to play with while we get our act together.
</Steven> -- Steven Noels http://outerthought.org/ Outerthought - Open Source Java & XML An Orixo Member Read my weblog at http://blogs.cocoondev.org/stevenn/ stevenn at outerthought.org stevenn at apache.org
