cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: Dependencies
Date Tue, 22 Feb 2005 22:50:11 GMT


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 <giacomo@otego.com> 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 <tcurdt@apache.org> 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:giacomo@apache.org
>>Hohlstrasse 216                           Mailto:Giacomo.Pati@otego.com
>>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

Mime
View raw message