Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 19912 invoked from network); 16 May 2006 10:25:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 16 May 2006 10:25:17 -0000 Received: (qmail 75376 invoked by uid 500); 16 May 2006 10:25:09 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 75293 invoked by uid 500); 16 May 2006 10:25:09 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 75282 invoked by uid 99); 16 May 2006 10:25:09 -0000 X-ASF-Spam-Status: No, hits=-10.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [209.237.227.194] (HELO [127.0.0.1]) (209.237.227.194) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 May 2006 03:25:09 -0700 Message-ID: <4469A8BD.305@apache.org> Date: Tue, 16 May 2006 12:26:05 +0200 From: Carsten Ziegeler User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: What does a Cocoon 2.2 release consist of? References: <44683A68.5060706@dslextreme.com> <4469995E.5040403@apache.org> <44699C51.6070901@apache.org> <44699DCE.7060206@apache.org> In-Reply-To: <44699DCE.7060206@apache.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Reinhard Poetz wrote: > Carsten Ziegeler wrote: > >> As important as what the release should consist of is what the release >> should not contain. Imho we should remove all OSGi related stuff from >> the release to not confuse users. > > I think this causes a lot of work without a benefit. As you said some time ago, > user don't look into the internals of jars, they just want to use them. :) - As long as this is hidden in a jar, I'm fine. But what about configuration files like wiring.xml lying in the root directory? And I don't want to ship OSGi related jars (I know with maven we don't technically ship them). Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/