cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: excluding unstable blocks by default
Date Fri, 02 Apr 2004 14:11:19 GMT
Upayavira <uv <at> upaya.co.uk> writes:

> How hard would it be to switch to having:
> 
> build stable
> or
> build unstable
> 
> instead of build webapp?
> 
> That would enable someone to choose right up front, without having to do any
> file editing.

Hmm, that's indeed an interesting approach IMO. I thought about something
similar (creating blocks.properties on the fly) months ago, but I stopped as the
user would no longer have a base for starting with his blocks selection
settings, i.e. no easy way like "copy blocks.properties to
local.blocks.properties".

With the current implementation a simple build stable/unstable would not work.
You must ignore local.blocks.properties for getting this working.

But the above also leads to new idea: First remove blocks.properties from CVS
and the need for local.blocks.properties, both files will not be read in the
init target. The information stable/unstable is in gump.xml and blocks-build.xml
is created from it, so we don't need the indirection using blocks.properties.

Now build stable and build unstable influence the creation of blocks-build.xml.
Sounds not very difficult IMO.

Now I want to complete this picture:
build (minimum) webapp <== just Cocoon core
build stable webapp <== Cocoon core + stable blocks
build unstable webapp <== Cocoon core + stable + unstable blocks
build complete webapp <== Cocoon core + stable + unstable + deprecated blocks

I also would ignore the backwards incompatibility: We can print out on build
time what is chosen, furthermore I think it's very obvious when build webapp
does no longer include your selected blocks, everybody will get this very fast.

And for a custom blocks selection there is additionally
build custom webapp
This target would look for a local.blocks.properties (or
custom.blocks.properties for consistency with the target). If it's not there it
generates it, stops the build and asks the user for doing the selection in this
file. A further call to the target would execute the build completely.

BTW, if you only introduce build stable/unstable, mapping one or the other to
build webapp, then you can not build the war file with the same
behaviour/default selection of stable/unstable blocks.

WDYT?

Joerg


Mime
View raw message