cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Using trunk
Date Sat, 25 Feb 2006 08:53:20 GMT
Carsten Ziegeler wrote:
> Daniel Fagerstrom wrote:
>> People, there seem to be some myths about that the trunk is unstable and 
>> that it doesn't work anymore. And that I and other people have 
>> unstabilized it beyond recognitions with the work on the blocks 
>> architecture.
>> I cannot speak for Carsten's work the last week on switching to Spring 
>> (besides that it broke my ongoing work :/), but before that the trunk 
>> worked.
> And it still does - at least the start page is still comming up :) And I
> hope to get feedback, so we can fix any possible issues quickly.
Great, hopefully I will find some time to look at it soon.

> I'm
> also cleaning up trunk a little bit and try to remove the
> BootstrapEnvironment to make the setup of the trunk even more easier
>> Now, it would of course be much more convenient if you could use Cocoon 
>> without the need to copy a few files. To get to that point someone need 
>> to write a Maven plug-in that perform the work that I outlined above. It 
>> shouldn't be rocket science IMO.
> And I think this is exactly where the perception if a none working trunk
> comes from. You can't just simply invoke a build script and start
> Cocoon. You have to copy several folders to see something - this is not
> a big deal, but a) you have to know it (I think our readmes are not
> mentioning this) and b) it has the perception of a "hack". So it would
> be great to have a maven plugin for this very soon.
> I guess if someone could come up with a decent description of the plugin
>  someone will very quickly come up with an implementation. So if someone
> could provide a short description about which files/resources/folders
> have to be copied where, this should be done very quickly.
I described what files need to be copied in the first mail in the 
thread, it is as simple as that.

1. Add the block you want to depend on to the pom.xml in cocoon-webapp.
2. Copy the content of src/main/resources/WEB-INF in the blocks to the 
src/main/webapp/WEB-INF of cocoon-webapp.
3. Copy the contents of src/main/resources/samples in the sample blocks 
to src/main/webapp/samples/blocks/<block-name> of cocoon-webapp.

The tricky part is how to identify which dependencies that are blocks 
and sample blocks.

Another question is how to control which blocks that are included in the 
webapp (like in the Ant build). IMO we shouldn't care 
about this now and just add a fixed set of important blocks. We will get 
all the flexibility we need with the block deployer.

ATM it would do with any quick and dirty temporary solution. We could 
just copy the needed files in SVN, use SVN externals or use an Ant 
script called from the Maven antrun plugin, that does the copying.

>> The work on blocks and OSGi that I and others are involved in outside 
>> the classical Cocoon but within the trunk, will make Cocoon better, 
>> leaner, sexier and easier to work with than most of you could even 
>> imagine ;) But it isn't ready for prime time just yet. Stay tuned and 
>> get prepared to be astonished ;)
> Now, if you and others are working on it, do I understand this correctly
> that this work is not done directly here in our repository?
It is done in the repository and is part of the cocoon-blocks-fw and 
cocoon-block-deployer modules. For the OSGi work there is not much code 
yet, and will actually be much code when it is finished either :) I'll 
hopefully find time to write the code and some posts about it soon.


View raw message