cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: "Normal" release artifacts
Date Mon, 17 Mar 2008 15:19:49 GMT
On Mar 16, 2008, at 10:42 AM, Reinhard Poetz wrote:

> Vadim Gritsenko wrote:
>> IMHO what's good a downloadable release if ' 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.
> 2.
>   ... [all the other blocks]
> 3.
> 4.
> 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 ' 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.


View raw message