Daniel Fagerstrom wrote: > > What do you think about moving block dependecy handling from block.xml > to pom.xml? It means reduced flexibilty as block dependencies becomes > direct instead of indirect as in the current schema. OTH it reduce > complexity and fullfills our current use cases. If we need indirect > dependencies we can add it later. There would be a need to give the > dependencies POM unique ids that can be used in the block protocol and > we also need a way to be able to mark a dependency as "extension", any > idea if this would be possible? > > Hmm, while that would be nice at some point I think that it currently > would be enough to have a block aware variant of the war pluggin. That > fetch and install all needed blocks in the webapp one i developing. > Maybe wiring.xml could even be expressed as a POM for this pluggin? >
2 wonderfull ideas ! Before you wrote that, daniel, i was very frightened by the new 'hot' block framework because of * the new kind of descriptor, * all the new jar introduced (osgi, knopflerfish: even if don't know if there are really related to this, it's part of the cocoon new face) * the fact that blocks are not regular jar (even if i don't know what it means it's frightening for a java developer :-) After 2 years using cocoon i just can't explain clearly how to build an application over cocoon-core and a few blocks staticaly. You should do something with block management for sure, but IMHO hot deployment should not be a priority. It just seems like adding an unecessary new layer of complexity (i know that you think this is simpler :-). Since a few week i'm just about to see the end of the tunnel thanks to maven 2 and its archetypes, and i'm full of hope again because it's simple and clear. My application is now constructed by maven, all the jar, ant, jelly, tools disappear from my repository. It just a lot easier to synchonise my app my a new cocoon snapshot. It took me only a few days to understand the process and even contribute to maven. Just to tell you that i felt very far away from the vertical learning slope of cocoon. I'm quite fed up with cocoon and it's complexity, and a few people in my team already drop it. It's just sad because everybody gave a lot of time on this. Maven 2.0 is the next big thing in java tools. And you took a really good choice here. It would be a pain if users, used to maven (and they will be more and more), had to learn another dependency management system. IMHO, the reason of this complexity is that cocoon has always been thought in terms of flexibility instead of usability and simplicity, constraints instead of conventions. I really think that the kind of refactor that occurs between maven 1 and 2 is a model of what has to be done for cocoon. So please (poor user request) define first a clean static build process with well defined dependencies (concern 99% of users) before thinking of hot deployment stuff. This build process could be defined for cocoon 2.1.9 without redefining the block management nor the jar stucture. It would give new users the possibility to fire a new cocoon project in 30s (how lucky ! it took me several month just to know how to build a minimal cocoon webapp). My 0.02€ Regards.
