Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
<snip/>
A basic scenario
================
1. A soon to become Cocoon user, downloads the "start kit"
distribution from our site.
It contains the (OSGi) kernel, the Cocoon service block (containing
the Cocoon core), a Cocoon servlet block,
ok
a (light weight) web server block,
you mean a block that contains e.g. Jetty or Tomcat?
Yes, there is a standard http service api in the OSGi spec, and there
are bundles based on both Jetty and Tomcat that implement that api.
IMO this could only be an option but not a requirement. Cocoon must
be deployable in a J2EE or servlet container.
As we have discussed before we should support both cases. What I
describe is a "start kit" distribution that helps a new user to get up
to speed. Puting a http service block in the "start kit" distro
coresponds to our current bundling of Jetty. All blocks should be
separately downloadable so that the experienced users can mix and match
as they want to.
a block deployer block
Basically the block deployer will be a stand-alone application (Ant
task, Maven plug-in, Eclipse plug-in, ...). Of course somebody could
write a web interface for it which could be a cocoon block.
As you can see in my original message I proposed: a block deployer
block, a block depoyer webapp block. Web interface and functinality
should cleary be kept separately.
<snip/>
called block.xml, no?
(wiring.xml and the Manifest file), a near
Yes, block.xml.
<snip/>
One thing to add: It must be possible that one block depends on
another block that is under development. I want my custom projects
requiring the latest svn version of e.g. the forms block. If the forms
block changes, this change takes effect immediatly on my project
without explicit deployment.
Absolutely!
/Daniel
