cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: Releasing Cocoon 2.2, finally!
Date Thu, 06 Mar 2008 15:25:27 GMT
Peter Hunsberger wrote:
> On Thu, Mar 6, 2008 at 7:58 AM, Reinhard Poetz <> wrote:
>>  It's time to release Cocoon 2.2, finally!
> Good news indeed.
>> We have been working on it for years
>>  and I think it's time to ship the *final* release. I want to do this in three
>>  phases:
>>  1) During the first phase I will release our two sub-projects "Cocoon
>>  Configuration" and "Cocoon Servlet-Service-Framework". This time I will create
>>  the Maven 2 release artifacts and "normal" zip/tar release artifacts for
>>  non-Maven users.
> Can you explain exactly what the difference is between these?

The Maven release artifacts are those files deployed to, see 
for example.

A normal release artifact is a zip/tar archive that contains the sources, the 
packaged binaries, the javadocs and the user documention.

>>  I think that I will be able to finish it by the end of next week.
>>  2) The second phase is Cocoon Core and all the blocks that were released as
>>  release candidates.
> Can you explain how this differs from the first two?  I think I know, but..

Cocoon Configuration and Cocoon Servlet-Service-Framework are supposed to run 
independently from Cocoon Core. We use them as the fundament for Cocoon Core 2.2.

>> Additionally I want to release the Cocoon Maven plugin
>>  (milestone 2), the Cocoon integration test framework (milestone 1), our
>>  archetypes and a starter package for non-Maven users.
>>  Again, this time I will create "normal" zip/tar release artifacts, except those
>>  cases where it doesn't make sense (e.g. the Maven plugin, the POM artifacts and
>>  the archetypes).
>>  I think that I will manage to finish this work by the end of March.
> Guess the biggest question is what will the minimal package be to get started?

My idea was a block, a webapp and a minimal Ant script that builds both and runs 
them. That's probably not good enough for an agile development process (-> you 
have to redeploy all the time ...) but gives enough ideas to people who want to 
integrate Cocoon 2.2 into their own web applications.

>>  3) The third phase is releasing our samples. It would be great if somebody else
>>  could help out with this task because I don't know if I will have the necessary
>>  cycles anytime soon. I guess that there is some work left in order to get this
>>  done and there are a couple of things to be discuessed before:
> We'll need to package up our own code to drop into the base but really
> we wouldn't need the samples for any other reason than to get ides on
> the best way to do this....

yes, and since creating seperate packages for all our sample blocks is an aweful 
lot of work, I don't think that this would be a good solution.

>>   . What do we want to ship? A WAR file only, or a WAR file + a pre-configured
>>     Jetty packaged as ZIP, etc?
> Are the above "release" artifacts separate downloads?

yes, that would be my suggestion.

>  I think I'd
> like to see the basic minimal WAR for people who need nothing else

the _blank_ Cocoon is the "starter package" from above. Maybe we should create a 
blank web application that uses Cocoon in "legacy mode" without blocks at all.

> and
> a complete Zip of everything you could possibly want for those who
> don't want to do multiple downloads.

Do you propose some kind of "super download" that contains core, all released 
blocks and the subprojects?

>>   . Do we ship snapshots of our blocks and samples? Or the released blocks and
>>     the snapshots of the samples? Or do we want to release our samples offically?
>>   . Are there any open legal issues? (e.g. we have to make sure that all the
>>     licenses of 3-party libs are added, etc.)
>>   . Or, should we only provide nightly snapshots of our samples? (though we would
>>     still have to check what this means legally for us ...)
>>   . etc.
> Ideally I'd love to see each sample as a separate download  complete
> with some way of tracking version updates, but initially I'd settle
> for a single download.

hmm, maybe that might be viable when we switch to another release mode that 
doesn't ship the whole Cocoon with it's dozens of release artifacts every time. 
If you only release e.g. a single block it isn't so much additional work to 
create a samples release artifact too.

Reinhard Pötz                            Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair

View raw message