-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 18 Jan 2006, Reinhard Poetz wrote:
Date: Wed, 18 Jan 2006 08:15:40 +0100
From: Reinhard Poetz <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: M10N
Giacomo Pati wrote:
Recently I was thinking about how we want our new build system to behave
from a user perspective because I wanted to get the plugins going ASAP.
Now I want to make sure that we all align on the same things.
In general the build system of Cocoon 2.1.x was quite handy for most of
us.
./buils.[sh|bat]
./cocoon.[sh|bat]
Was all one needed to type to get a running system (yes some needed to
adjust the local.[build|block].properties file but with M2 this should be
doable in a similar but more Mavne-like way).
Now, is it the goal of M10N to get as close to this as well? Or are we
going to have different building procedures (mvn goals) depending on
whether it is a component block, application block, webapp block, etc.
M2 offers quite a lot of possibilities how to interact with its
lifecycle/build phases so that building different types of artifacts could
be standardized with our plugins which may be attached into those
lifecycles/build phases.
We can define our own artifact types so that there is possibilities to
supply archetypes for things like application blocks, component blocks,
abstract blocks, whatever and build them in a consistent way (from the
users perspective), but package them as we need/like.
I.e.
=> mvn # build the package depending on the artifact we
# want to produce for a certain module (single modules
# as well as multi module build)
mvn cocoon:run # run it (independent whether this is the root or
# a single module)
WDYT?
First contact with Cocoon
-------------------------
We can provide "ready to use" downloads that basically consist of
- container (Jetty)
- web application with blocks
I think we need to do so. Cocoon is a complex thing and an effort giving
an easy to install and use distribution to get in touch with it will be
a must.
We can also offer different sizes:
- standard: contains the most important samples blocks
(forms, template, auth, flowscript, javaflow)
+ all required blocks
- portal: just the portal samples
+ all required blocks
- full: all our samples
+ all required blocks
Ok.
These downloads are *not* the starting point for new Cocoon projects but only
show the functionality.
I know that.
These download packages can also be used at cocoon.zones.apache.org for our
live demos. I'm sure we can automate the packaging process in some way using
the block deployer Maven plugin.
BTW, I wouldn't even say these downloads are our _releases_ as IMO our
releases are the block jars that we make available at our download pages and
(more important!) via the Maven repositories.
Correct. But I think we need a thing for "first contact".
Start your Cocoon project
-------------------------
As I said above, a Cocoon project is also a block. You create your block
skeleton using the Maven block archetype, add your dependencies, e.g. your
block depends on forms and template, and that's it.
Yes, I see that, too.
It's the same process as adding a Maven plugin to your pom.xml. You browse
the Cocoon website and find a list of all available blocks. Than you add the
required block to block.xml as requirement.
As pointed out in the tutorial, you can use the "cocoon:simple-deploy" and
"jetty6:run" to test-drive your block at development time.
Ok.
See http://cocoon.zones.apache.org/daisy/documentation/g2/796.html
A Cocoon web application
------------------------
The "cocoon:simple-deploy" is only useful at development time as you don't
have the possibility to change e.g. your web.xml and you can't use more than
one block.
Shouldn't it be "you can't use more than _this_ block". This in contrary
to the "full blown sample distribution" where all our samples blocks are
independant (application) blocks which itself depend on
(composition/service) blocks (i.e. like cron, or ajax which itself will
be referenced by many of those independant blocks). Such a "full blown
sample distribution" could well be a separate block in our repository
just for building that distribution (at the ent it could be a war
package).
My plan is doing it the same way like other webapp projects. You provide your
web application in /src/main/webapp which means that you put your web.xml
there at least.
Then you create your block-deploy.xml and you can say there which blocks you
want to deploy, how they are configured and which implementations you want to
use to fulfill their requirements.
Fine. Do you have in mind to support this by a Maven plugin to create
descriptors, based on dependencies defined in the pom, unpack them to
create the webapp structure suitable for war packaging?
See http://cocoon.zones.apache.org/daisy/documentation/g2/797.html
Developing Cocoon (--> for Cocoon developers)
---------------------------------------------
AFAIU there is no difference to developing an "application block" (I even
think that we should restrain from introducing this distinction.).
The difference is made up in the descriptors (i.e. has a sitemap, just
supplies some common components/services).
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDzfsBLNdJvZjjVZARAr8TAJ0XycDgjPrrqjUzZ23q2+mA8+X2wQCePwKV
9R1tvu2PmmqPy0zNW6u9sco=
=CA7U
-----END PGP SIGNATURE-----
