cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [2.2] Deployment and the maven plugin
Date Mon, 30 Oct 2006 09:56:35 GMT
Joerg Heinicke wrote:
> Carsten Ziegeler <cziegeler <at>> writes:
>> So the final part is how to avoid the maven deploy plugin? We recently
>> discussed a possible solution which works using some classloader
>> functionality, some new protocols and so on and does not require any
>> extraction of files during deployment or runtime. Cocoon would be able
>> to serve everything directly from the jar files.
>> While this is a very interesting solution, it has some problems: first
>> and most important: we have to develop it. As we are lacking resources,
>> this might take too much time until we have a final version.
> Was this a discussion on the mailing list? Maybe I just haven't read that thread
> yet. Or was this offline at Cocoon GT or similar? Can you give some links or
> summarize it here please? What's needed more than resource:/?
We started the discussion at the GT and then continued/summarized it in
this mailing list.
I greped some pointers from another discussion on this list:

>> >> >> We have some ideas about how to get rid of the need for the
>> >> >> in the development cycle. See
>> >> >>,
>> >> >>
>> >> >>
>> >> >> for that discussion.
>> > >
>> > > That would indeed be very nice. But how does the reloading work
>> then?
>> > > Deploy a special jar into cocoon/libs that somehow points to its
>> > > original source folders?
>> No, we discussed having a configuration file with associations between
>> block name and block path, that overrides the blocks in the classpath.
>> By using that you can point to your block under development.

You need more than the resource procotol as for example you have to scan
through the archive for all *.xml files and so on. And the other problem
is the "mounting" of the COB-INF directory. Although it's doable (at
least currently we think it's doable), it might get a little bit tricky
here and there.

Carsten Ziegeler - Open Source Group, S&N AG

View raw message