cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Non-Maven Cocoon 2.2 release
Date Wed, 09 Jan 2008 08:49:40 GMT
Ralph Goers wrote:
> No. We could take advantage of http://maven.apache.org/ant-tasks.html to 
> create various ant scripts to do that.  However, since I'm still not 
> sure what this supposed support for non-maven builds really looks like 
> it is hard to have a good answer to the question.

Yes, that's the question du jour. Since I use Maven 2 in all of my Cocoon 
projects, it's not easy for me to give an answer.

Looking at other projects, e.g. Spring might help us. Spring provides two 
different downloads: One contains all Spring libraries, Javadocs and general 
documentation, the second additionally includes all libraries Spring depends on. 
   Note that this releases don't contain any samples (at least the last time I 
looked into it.)

The situation for Cocoon is similar but not the same. We've been working hard to 
  break up the monolith and make blocks more independant. A Cocoon block is more 
like a Spring sub project (e.g. Spring webflow). In practise this means that you 
can add those blocks to your Cocoon app that you need. In difference to 2.1 you 
can make this decision at deployment time and not at build time.

Those independant blocks also have the advantage that establish different 
release cycles for each: If we want to release e.g. the template block, we only 
have to release this one without having to care for all the other stuff.

The first question we have to answer is, whether we want to pass this advantage 
to non-Maven users too. If yes, each block also has to become a seperatly 
downloadable release unit which could contain the block library itself, 
Javadocs, general documentation and even the related samples block.

As an alternative we can create one huge download that contains the most recent 
versions of Cocoon core 2.2, the latest versions of all releaseable blocks and a 
preconfigured Jetty instance that is able to run Cocoon. The downside of this 
approach is that this will create a really huge file (+50 megabytes) which will 
not be very appealing for a beginner to start with.

                                      - o -

My proposal is that we create seperate download units for Cocoon core and all 
releaseable blocks. That's a bit of work intially but thanks to Maven we already 
  have all necessary parts. The work will "only" consist of writing a script 
that pulls together all those parts (jar, sources, javadocs, general docs), zip 
it, create checksums and sign it. The final result is a Maven free zip, the 2 
checksums and the PGP singatures of all those files. This could become part of 
the usual release process.

In addition I propose that we create a samples download (jetty + preconfigured 
webapp) and a "getting-started" download which is derived from the output of our 
Maven 2 archetypes. These two artefacts will always be created when Cocoon core 
is released.

If we follow this proposal I would appreciate any help very much. The work 
mainly consist of writing the scripts (I'd prefer Groovy or shell scripts).
On my personal todo list this comes right after setting up integration tests for 
trunk (working on this right now) and writing an initial integration tests for 
the servlet service framework. When all three things are done I'm ready for the 
final release.

-- 
Reinhard Pötz                            Managing Director, {Indoqa} GmbH
                           http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair        reinhard@apache.org
_________________________________________________________________________

Mime
View raw message