cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [New build system] Status of samples
Date Fri, 28 Feb 2003 10:50:18 GMT
Carsten Ziegeler wrote:
> 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 

 > 3) Instead of exclude-block-xxx properties, use the include-block-xxx
 > properties in file (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                               <>
    Pluralitas non est ponenda sine necessitate [William of Ockham]

View raw message