Maybe we are on the same page, but I'm unclear what you mean by
"include". A cocoon release should consist of nothing more than
deploying artifacts to the maven repository. End users should be getting
the release by specifying the version number of the release in the
archetypeVersion. To create the sample site they should do:
mvn archetype:create -DarchetypeGroupId=org.apache.cocoon
-DarchetypeArtifactId=cocoon-archetype-samples -DarchetypeVersion=1.0.0
-DgroupId=com.mycompany -DartifactId=samples
mvn install
mvn jetty:run
IIRC the source can also be placed in the maven repository, so if they
want to see what the source for samples look like we should be able to
provide something that will retrieve them.
Even if we can't do this, there are 2 things I do not want to see. 1)
End users have to download all the source for Cocoon or 2) End users
have to individually download a bunch of zips to get the source for all
the various sample blocks.
Ralph
Joerg Heinicke wrote:
On 08.01.2008 14:45, Grzegorz Kossakowski wrote:
We were not shipping samples because samples should depend on
released artifacts, only. Anyway, I
agree that we need to find a way for distribution of our samples.
However, I wonder how we will treat them? As official released
packages with version number schemes,
etc.?
I would like to go with just creating zip archives containing source
code of all our samples that
depend on released artifacts. We would update such archive from time
to time, as need occurs. I
don't think we need any more formalization. WDYT?
I don't know if it is put in question but IMO we still need an actual
Cocoon 2.2 release which is more than core but also includes as many
blocks as possible (the ones converted and working). Where is the
problem to include all these blocks with their samples?
Joerg
