Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Leszek Gawron skrev:
Daniel Fagerstrom wrote:
...
I would prefer removing the trunk/lib and Ant build system ASAP, and
that everybody helps getting the parts they care for working with
the Maven build.
Before taking such drastic moves we should probably have a full
replacement for current build system. Up till now we had quite a nice
solution [1]. If we are to drop it we should resolve following issues:
1. developers/more advanced users often use trunk snapshots even for
production (I have probably never used a released version :)). If so
there has to be a support in our build system to deploy artifacts not
only to apache repository but also to company's/individual's
repository. I am not talking here about simple 'mvn install' which
only copies the file on the same computer to local repo.
The release plugin take care of this:
http://maven.apache.org/guides/mini/guide-releasing.html, IIUC you can
overide where it reads from, I'm not shure about if there if you can
override the release repository without changing the root POM.
The official documentation states the only way to do this is to change
cocoon's POM and that is not a solution I would advise to users.
2. Follow up for 1): jar names should include timestamps/revisions so
one can have multiple production sites working on different cocoon
versions.
Take a look at
http://svn.apache.org/maven-snapshot-repository/org/apache/cocoon/cocoon-core/2.2.0-SNAPSHOT/
It is automatically generated by Continuum.
Jorg have set up this.
That is very nice. Still my own 'mvn install' should do the same.
Imagine a contributor that creates some enhancement and wants to test it
on it's own projects before submitting. He/she cannot use Jorg's
snapshots.
Why not? If the user wants to use snapshots, he just points to the snapshot
repository at Apache. What's missing?
2. cocoon is not only a set of jars. There is also a set of default
resources (web.xml, main sitemap, stylesheets and so on). How do we
ship that so users do not stay out of sync with jar versions?
They will be included in the respectively blocks jar. And put in some
blocks unique package so that the framework can find them. Reinhard
work on this.
To be sure: is it also the case for main sitemap.xmap?
There will be no main sitemap.xmap anymore, however one block can cover the "/"
URIs by mounting it to "/".
3. How are we going to distribute .xconf files? As they are also
artifacts of some kind users shouldn't copy them into own project and
modify but rather xpatch them as it is performed now. I know we have
.xconf inclusion and multiple xconf files. Still there are some
things that inclusion does not solve.
The .xconf files will be parametrized with the parts that users might
be interested in changing, and a fixed .xconf will be included in the
blocks jar.
So how do I add my own cforms convertor? The only way to do it now is
xpatch.
How do I parametrize continuations manager. It's current configuration
is rather incoherent:
<continuations-manager logger="flow.manager" time-to-live="3600000"
session-bound-continuations="false">
<expirations-check type="periodic">
<offset>180000</offset>
<period>180000</period>
</expirations-check>
</continuations-manager>
(BTW type="periodic" is not even parsed by the component :))
We'll probably need to redesign the way some parts of our systems are
configured. I'd love to use Carsten's idea of property files to
parametrize components. After all almost every xml configuration can be
expressed with a set of properties.
Blocks can be parameterized. I'm not sure how this will work together with
Carsten's idea of property files.
I've started to write documentation about block usage and deployment and hope
that this will make things clearer (for me and for us). I will publish it at the
beginning of the next week as I don't want to confuse people with the current
state of the documents.
I am working on lots of small cocoon based project. Because of the
project count I found the [1] technique uniquely useful. I have
created a ant based build system (similar to [2]) and isolated
custom cocoon build into a subproject. This way my cocoon based
projects do not contain any files copied over from cocoon distro.
Everything stays in cocoon-build-system and with one simple
ant -f cocoon.xml cocoon:get
I update cocoon distro for every of my projects. I hope it will be
that simple also with maven.
[1] http://wiki.apache.org/cocoon/YourCocoonBasedProjectAnt16
[2] http://javagen.com/jam/
Maven also has the concept of archetypes, that make it possible to
generate different kinds of project templates. Jorg experimented with
that in the whiteboard.
The problem is archetype is not good in cases when you manage lots of
projects because it's merely a template. If you put web.xml into your
archetype it will surely be outdated in a year. If you just xpatch the
current version than you have no such problem. I resigned from copying
any cocoon resource into my project because that brought a lot of
problems. Gosh it was a nightmare to synchronize cforms resources before
they were put into .jar file. In this case the solution was quite simple
as the resources are easily extendable and they do not have to be
changed. With other cocoon resources it is not that nice.
First, your Cocoon 2.2 projects will be blocks too. You will use the Cocoon
block archetype to create one. Then you will use the Cocoon webapp archetype
that only contains a description which blocks you want to use in your webapp
(war) and where you want to mount them. Additionally you will find there the
usual webapp stuff (web.xml, ...).
The rest will be done by the block deployer plugin and standard Maven plugins
like the webapp plugin. At least that's the plan.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
