On Mar 16, 2008, at 10:42 AM, Reinhard Poetz wrote:
Vadim Gritsenko wrote:
IMHO what's good a downloadable release if 'cocoon.sh run' does not
work?
I'm not sure if I understand your concerns here correctly. Maybe I
wasn't clear about what release artifacts I want to create. Here's
the list:
1. cocoon-core-2.2.0.zip
cocoon-servlet-service-1.0.0.zip
cocoon-configuration-1.0.0.zip
2. cocoon-fop-1.0.0.zip
cocoon-forms-1.0.0.zip
... [all the other blocks]
3. cocoon-2.2-getting-started-1.0.0.zip
cocoon-2.2-legacy-getting-started-1.0.0.zip
4. cocoon-samples-1.0.0.zip
1. and 2. are the releases of our production ready sources (+ docs,
+javadocs, +binaries). If somebody wants to use Cocoon in one of his
projects and doesn't want to use Maven 2, Ivy or the Maven Ant
tasks, he has to download them and add the libraries to his (web)
application.
To some extend it is even dangerous to add third-party libraries
because this might lead to the inclusion of conflicting versions (or
at least to unintended duplication) just because you add the
libraries of several e.g. Cocoon blocks that were created at
different times.
The second purpose of 1. and 2. is providing a single release
artifact of parts that belong together (docs, apidocs, sources,
binaries). As it was pointed out several times by you and others,
it feels strange to have only Maven 2 release artifacts.
3. and 4. are different. 'cocoon-2.2-getting-started' is a
suggestion how you could organize a Cocoon project that uses blocks
and that uses Ant as build system. We could also have a 'cocon-2.2-
legacy-getting-started' package, that uses Cocoon the old way
without using the SSF infrastructure.
'cocoon-samples' is the package for that the 'cocoon.sh run'
proposal applies, IMO.
One of the points of such release is to make it one stop shop, to
get everything up and running in one quick download.
Is 'cocoon-samples' good enough to be the one-stop-shop that you
intend? However, I would like add a big warning message, that it is
not supposed to be used as starting-point for a new Cocoon project.
If it includes core + all released blocks + all samples + all 3rd
party dependencies -- yes I think that's exactly what I had in mind.
So let me ask again: Do we need third-party libraries in 1. and 2.
or not? (For 3. and 4. it's clear to me because they wouldn't be
useable otherwise.)
It would be good to have required dependencies there as well but given
existence of 4. it is IMHO less critical.
Vadim
