cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@upaya.co.uk>
Subject Re: Compilation of Cocoon / Binary Distribution / Different Configurations,
Date Fri, 07 Nov 2003 13:39:56 GMT
Alexander Schatten wrote:

> Thank you again for feedback; some comments though:
>
> Upayavira wrote:
>
>>
>> Dependencies between blocks are a relatively new thing - at the 
>> moment we've just dealt with it with comments in the 
>> blocks.properties file, which is not ideal, but better than not 
>> telling anyone at all.
>
>
> yes, but unfortunately they are far from complete: since the last 
> email I already had to restart the build twice because of not marked 
> dependencies... this is really extremly awkward.

I agree it is awkward. If we can come up with a better way of 
'annotating' the blocks.properties file, then I'm sure no-one will complain.

>> You probably perceive a resistance to helping to improve stuff like 
>> the build process, or to making binaries available. This, I believe, 
>> is because developers would rather concentrate on implementing real 
>> blocks, rather than putting effort into the current build process, 
>> which was _always_ seen as a temporary measure.
>
> yes, I think you have established that, and I understand it.

Ok.

> However, I have the impression, that the Cocoon developers, which are 
> is very obviously a group of excellent developers, sometimes oversees 
> the fact, that Cocoon is not longer a hacker tool, but there are 
> thousands of "normal" users outside; and when you announce a new 
> release, certain basic attributes should exists.
>
> One is, that the build and installation is transparent even to 
> non-Cocoon-contributors;

Cocoon isn't a simple thing to use. I think we have to accept that. And 
we do have a super block system in the pipeline. In the meantime, if we 
can come up with relatively simple changes to our existing setup, then, 
as I say, I think they'll be accepted.

> I might not be the brightest of all Cocoon users, but you might assume 
> that I am at least the "average dummy user", and I report the problems 
> and issues, because I love the project; many others simply dump the 
> idea to use Cocoon.

And I for one appreciate it!

>>> cant you provide a set of 3-5 blocks.properties files at least, so 
>>> that every user can choose from a set of working properties the best 
>>> suited for the problem?
>>
>> I've watched this, again, and again, and again. No two people can 
>> agree on what they need and what they don't. It is simply not 
>> possible to identify a few tailored blocks.properties, as there are 
>> just so many relevant combinations.
>
> Sorry, to point this out again: this is the usual "guru-problem": not 
> agreeing about a solution, because no suggested solution offers 100% 
> quality (only 80% at best), and the result is an eternal discussion 
> with a "no-solution" that has the quality of 20% (as of now). And 95% 
> of Cocoon installations use the "full program" as in the current 
> properties file.  This was not intended, I believe.

That's how it was with 2.0. If some people can work out how to cut down 
within 2.1, then that's good, IMO.

> At this point I have to say:
>
> *please* -- for the sake of the normal user -- take a decision, and 
> put 3-5 properties files into the release!! They can at least be a 
> guidance for the unskilled ones. and the expert can configure as he 
> does it right now.

What I propose (at least for now) is to improve the contents of the 
blocks.properties file so that an unskilled user can work out what they 
need to do.

E.g. If all you use is the basic Cocoon facilities (FileGenerator, 
XSLTTransformer, HTMLSerializer) then you can disable ALL blocks.

Use with CLI
Note: currently the CLI will not work with these blocks included: XXX, 
XXX, XXX

What do you think? Maybe you can suggest some other notes that would 
help within the blocks.properties file.

Regards, Upayavira



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message