cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <coc...@leverageweb.com>
Subject Re: excluding unstable blocks by default
Date Fri, 02 Apr 2004 17:00:27 GMT
Quick comment on a busy day: I'd rather see us take this opportunity to 
allow/create build profiles.  The core cocoon-provided ones (core, all-stable, 
all-current, all (includes deprecated), "publishing", "dbapps"...) would be 
created out of gump.xml, but the user could then keep multiple options laying 
around simultaneously: client1.(build|blocks).propertes, or live, stage, etc. 
We'd create convenience task aliases for the stock ones as you mention below, 
and build custom would default to the local.properties, but you could also swap 
in a specific profile with -Dbuild.profile=client1 etc.

I proposed the ant side of how this would work a few weeks ago in the "How can I 
help" thread.

WDYT?

Geoff

Joerg Heinicke wrote:
> 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