From: "Stefano Mazzocchi" <[EMAIL PROTECTED]> > Samples are 'integration oriented' while blocks are 'separation oriented'.
Yes indeed they are. > Get the 'hello-world' sample directory: this depends on many different > blocks (fop,batik and so on). Refactoring this into pieces and XconfTool > patches is a major pain in the ass. > > Even more: some samples require code to be compiled. In some senses, > each of these sample folder (for example, flow or xmlform) looks like a > microblock on its own.... but making each sample folder as a block is > clearly overwelming and would ruin the concept. Why would making each sample a block ruin the concept? (...am I ignorant? ;-) Clearly there must be some separation between 'sample' blocks and 'component' blocks, but this should be no more than a subdirectory separation IMHO. > But having just *one* sample block is useless since we are back on the > hello-world iper-dependent problem. > > Finally, I think the Cocoon build should also allow you to build your > own cocoon web site. In this case, your stuff should becomes nothing > different from a microblock. (please, don't start using this > terminology, it sucks, it's just to give you the idea) I would definitely love this: just drop-in your block and hit build! > I spent last night looking at how very complex java software is built > (netbeans for example) and it seems that we are unique in such a highly > fragmented yet dependency-intensive behavior. > > So I'm definately stuck. > > Bart Guijt wrote: > > > 2) Have each sample have its own block, which depends on the block(s) > > declaring the components they need. > > IIRC the infrastructure to support this is already there. Usecase: The > > XMLForm sample(s) use the databases block, XMLForm block and the Mail > > block. Having the XMLForm block depend on the Mail block is silly, of > > course. > > So, what do you propose for those samples that depend on many different > blocks? If you refer to the hello-world like samples, I think there are two issues here: 1) Perhaps the samples should be 'rotated' 90 degrees, e.g. having a (collection of) samples per block instead of having a 'subject' of samples (e.g. 'hello world') over many blocks; 2) What is the dependency direction? i.e. are (parts of) the samples built when its dependend blocks are included, or are the blocks built if either it is included directly (-Dinclude...) or another block/sample depends on it (like Ant target dependencies)? Other than that, what is wrong with a sample(block) depending on as many other blocks necessary? This is the perfect way to find out what blocks are needed to implement an application which resembles the sample (e.g., XMLForm). To build Cocoon with a sample, just specify the include parameter at buildtime and Cocoon builds with all dependend blocks included. > > 3) Instead of exclude-block-xxx properties, use the include-block-xxx > > properties in file blocks.properties (or accept both - just like Ant's > > <fileset> include/exclude attributes). > > Let the build process figure out what the dependencies between blocks > > are. Usecase: If I need to test a certain block, I don't want to set > > each exclude-property to true, while hoping not to forget anything. > > Refactoring the project-info.xml file requires a special block ant task, > I'll try to make it more usable than the current (admittedly somewhat > hacky) property-based solution. > > Suggestions on how to do this are welcome. > > > Again, I don't want to interfere with your own ideas, I just thought > > this proposal would do it because it is simple, most necessary > > infrastructure is already there and I'd like to build my JavadocSource > > stuff again ;-) > > Thansk, your suggestions are precious and resonate with my planned line > of action. Thanks for your appreciation. Ciao, Bart Guijt
