Hi,
is anybody working on getting the samples working again with
the new build system?
I am, but it's such a pain in the ass :(
What is missing? I can help, if required.
The problem is simple, the solution complex.
Samples are 'integration oriented' while blocks are 'separation oriented'.
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.
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 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: > I hope this doen't interfere your ideas, so if you don't mind I'd > like to propose the following:
Ok, let's see.
> > 1) Refactor the project-info.xml to split in several files contained > > in the blocks themselves. > Just like Eclipse plugin.xml files in their plugins, a plugin is > installed by just dropping it in the plugins dir. Usecase: This will > make it easy for me to maintain my JavadocSource block (or any > (external) block for that matter), now I need to sync each time when > project-info.xml changes ;-)
This is called for, I totally agree. I was going to tackle that problem today, anybody against this?
is anything using that project-info.xml file or is just a left-over from the old build system?
> 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?
> 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.
Anybody has other comments on this?
-- Stefano Mazzocchi <[EMAIL PROTECTED]> Pluralitas non est ponenda sine necessitate [William of Ockham] --------------------------------------------------------------------
