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 blocks.properties 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.
/Daniel
