Mark Lowe wrote:
I'd thought about the plugin idea for managing the build, as I've a maven script thats pretty much ready to be ported out into a plugin.
Reinhard what's your view on this as you seem to have a different vision? How possible is it to have installable blocks? For example I've had a few problems using a forms block built with 2.1.7-dev, with 2.1.6.
Some part which have been in the samples in forms 2.1.6 have been integrated into the forms block jar in 2.1.7-dev.
Looking at it there doesn't seem to be a huge reason why the blocks couldn't be installable, i guess compatability testing against release versions would be needed. But I cant get passed thinking that its all supposed to be java.
One thing you might take into consideration is the single cocoon.xconf file which may need to be patched depending on the blocks you'd like to deploy (some blocks do have components that need to be described into cocoon.xconf). This is one reason why Cocoon is build from the sources using the proposed build scripts and properties files (block.properties, build.properties).
I might not know what I'm talking about but I don't see the comparision between httpd server and a framework as the same thing. The users are different as well as the technologies.
Folks developing java webapps, expect to have jar files they need to stick in WEB-INF/lib deploy to a container such as tomcat and run the thing.
Cocoon apps are not webapps in the common sense. Cocoon itself can host many independent apps just like a servlet container (or a web server as I was comparing it in my previous post) thus I treat it as a infrastructure and not just a framework. Do you look at Tomcat/Jetty as a framwork?
When I'm doing sys admin stuff i like using vi, running configure scripts and makefiles. But i wouldn't code java using vi.
Same here but instead of running ./configure we run Maven.
Giacomo
I've been going through the svn logs. Are there's any posts in the archieves where I can brush up on what the road map is?
Mark
On Tue, 22 Feb 2005 21:30:18 +0100, Giacomo Pati <[EMAIL PROTECTED]> wrote:
Mark Lowe wrote:
What are the exact reasons you don't like a source distribution?
If I were working on my own then there's not a huge problem, but this isn't the case. There are several agencies involved and the usual political difficulties when changing things like build files and versions. Someone walking into this to do a request fix. but has no previous knowledge of the application gets bogged down, having to understand that cocoon needs building, the build scripts have grown in complication to the point of being unmaintainable.
Being able to have a cocoon based project, define the dependencies in the project.xml (or even an ant build file) build your source code and webapp resources into a war, would be a huge step in the right direction. Its the little things that count.Someone on the original thread mentioned the classic ./configure;make with ./build.sh;:/cocoon.sh , isn't that the point?
Cocoon has grown beyond the 'it's a framework' status IMHO. It is an infratructure similar to the Apache HTTPD where you need a well defined deployment strategy/facility. If you take it as that even Maven users will find their way through it as we do for nearly two years now with success (from customers as well as from our developers POV).
One problem is that there isn't one golden way doing project/webapps with Cocoon. I'm sure if we start a "write down how you do project management/development with Cocoon in a wiki page" contest we suddenly will have dozends of ways to do it as most of us have developed their own way of doing it as the needs are different from group to group. Most of the people here use Ant others use Maven. Just this allows for different variations on doing it.
We use a "home grown" Maven plugin developed with the help and visions of other people here that allows us to have short development cycles (just save your changes and reload your browser), the ability to build a Cocoon suited to the needs for the app in development by just executing a Maven goal, and a way to create a deployment infrastructure project where our Cocoon apps can be deployed into a well built Cocoon by just executing Maven. The war deployment way has never worked for us as we don't have (and don't want) the single app for one Cocoonn instance similar as we don't do a sigle webapp for a single HTTPD instance.
If once the "real blocks" a reality things might change again but until than we are quite happy with it.
Giacomo
Mark
On Tue, 22 Feb 2005 11:34:05 +0100, Torsten Curdt <[EMAIL PROTECTED]> wrote:
and without requiring to compile the framework itself.
We know this - we are working on getting rid of the compilation step with 2.2 again.
I'll shutup then.
Just wondering...
Which part of calling "./build.sh" is the big problem again? :-P
..but seriously - from a user's point of view: What are the exact reasons you don't like a source distribution?
cheers -- Torsten
-- Otego AG Tel: +41 (0)1 240 00 55 Giacomo Pati, CTO Mobile:+41 (0)79 262 21 04 Apache Software Foundation Member Mailto:[EMAIL PROTECTED] Hohlstrasse 216 Mailto:[EMAIL PROTECTED] CH-8004 Zuerich http://www.otego.com
-- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
smime.p7s
Description: S/MIME Cryptographic Signature
