Upayavira wrote:
Alexander,
There are a whole host of reasons why we only distribute a source version at present. When we get on with implemening cocoon blocks, all will change. For the time being, a source distribution is what we've got. (Reason for source distribution: it is the only simple way to allow a user to switch on and off different blocks and other bits within Cocoon). It is not possible at present to create a 'production build', as everyone will disagree as to what should go in 'their' production system.
I certainly agree that the CLI could be made easier to use. For example, I belive that at present, compiling Cocoon with the Authentication framework present, breaks the CLI. That should not happen.
unfortunately this is really an adventure game if you are no Cocoon contributor: e.g., I just tried to follow your suggestion and removed the authentication block; there is a note about a dependency with the session-fw block, and so I removed both of them.
started compilation.
--> error
why?
because there is also the portal block, and this one is depending on authentication, I belive, but this dependency is *not* noted...
the last days I spent at least 4-5 hours only trying to compile reduced cocoon versions...
so you have to know one thing: in my experience, there are no cocoon users I know that do anything else then compile with the default settings, except explicit Cocoon contributors, who know, what they do. because it is very complex to understand the dependencies and to get whats happening. and because (see above) it is an extremly time consuming undertaking.
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.
so what you did not answer (as I have to notice, that you do not want to share binary versions, and I still do not know why, because there is the possibility (as it always was) to provide binary as well as source distributions for those who want to configure all stuff by themselve) is the following:
This is the current situation (with some history):
1) For 2.0, we issued binaries, and those binaries included everything
2) For 2.1, we started having 'blocks', and people complained that they didn't want everything
3) Stefano rewrote the build process so that it could include/exclude blocks as desired.
4) It was proposed to offer only a source build, as this allows users to configure Cocoon to their needs, something that at the moment would be hard to do on a prebuilt system.
4) Stefano proposed 'real blocks' (read more on the wiki), which will allow for runtime deployment of precompiled 'blocks', which can contain components, but also sitemap snippets and other files, and his proposals have been generally accepted as a good idea
5) We have started a 2.2 repository, in which we will hopefully soon start coding real blocks.
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.
However, I think there's a value in putting descriptions of the blocks into the blocks.properties file itself. I'm going to propose this now.
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.
I think my advice would be to switch off _everything_ and work from there.
yes, I hope too!The CLI should work by unpacking the source archive then doing: build webapp cocoon cli -x cli.xconf
and off it goes.
Over time I'll see what I can do to get it there.
btw. I will answer the other email soon, I just want to test, whether CLI will work with cocoon compiled with authentication excluded.
Great.
Upayavira
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
