Joerg Heinicke wrote: > Carsten Ziegeler <cziegeler <at> apache.org> 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 deployer >> >> >> in the development cycle. See >> >> >> http://marc.theaimsgroup.com/?t=116013240800001&r=1&w=2, >> >> >> http://marc.theaimsgroup.com/?t=116034430600002&r=1&w=2 and >> >> >> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=116035392308084&w=2 >> >> >> 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 -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
