Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 76807 invoked from network); 22 Jun 2007 16:14:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 22 Jun 2007 16:14:49 -0000 Received: (qmail 11125 invoked by uid 500); 22 Jun 2007 16:14:51 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 11043 invoked by uid 500); 22 Jun 2007 16:14:51 -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 11017 invoked by uid 99); 22 Jun 2007 16:14:51 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jun 2007 09:14:51 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of grek@tuffmail.com designates 216.86.168.178 as permitted sender) Received: from [216.86.168.178] (HELO mxout-03.mxes.net) (216.86.168.178) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jun 2007 09:14:46 -0700 Received: from [192.168.1.2] (unknown [87.206.142.101]) by smtp.mxes.net (Postfix) with ESMTP id 8D2C85197E for ; Fri, 22 Jun 2007 12:14:24 -0400 (EDT) Message-ID: <467BF54D.7070204@tuffmail.com> Date: Fri, 22 Jun 2007 18:14:05 +0200 From: Grzegorz Kossakowski User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Cocoon's dev mailing list Subject: Separate projects on JIRA - final proposal Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hello, Reinhard asked[1] me to provide a final list of Cocoon modules that would get their own JIRA projects. Here is the list of projects with proposed JIRA identifiers in brackets: - Cocoon Core (COCOONCORE) includes following artifacts: * org.apache.cocoon:cocoon-pipeline-api * org.apache.cocoon:cocoon-util * org.apache.cocoon:cocoon-xml-api * org.apache.cocoon:cocoon-pipeline-impl * org.apache.cocoon:cocoon-xml-impl * org.apache.cocoon:cocoon-pipeline-components * org.apache.cocoon:cocoon-sitemap-api * org.apache.cocoon:cocoon-thread-api * org.apache.cocoon:cocoon-sitemap-impl * org.apache.cocoon:cocoon-sitemap-components * org.apache.cocoon:cocoon-xml-resolver * org.apache.cocoon:cocoon-store-impl * org.apache.cocoon:cocoon-thread-impl * org.apache.cocoon:cocoon-core * org.apache.cocoon:cocoon-core-main-sample - Servlet service framework (SERVLETSERVICE) * org.apache.cocoon:cocoon-servlet-service-components * org.apache.cocoon:cocoon-servlet-service-impl * org.apache.cocoon:cocoon-servlet-service-sample - Template (TEMPLATE) * org.apache.cocoon:cocoon-template-impl * org.apache.cocoon:cocoon-template-sample - Flowscript (FLOWSCRIPT) * org.apache.cocoon:cocoon-flowscript-impl - Database (DATABASE) * org.apache.cocoon:cocoon-databases-mocks * org.apache.cocoon:cocoon-databases-hsqldb-server * org.apache.cocoon:cocoon-databases-hsqldb-client * org.apache.cocoon:cocoon-databases-impl - Forms (FORMS) * org.apache.cocoon:cocoon-forms-impl * org.apache.cocoon:cocoon-forms-sample - M2 Plugins and archetypes (COCOONM2) * org.apache.cocoon:cocoon-maven-plugin * org.apache.cocoon:cocoon-rcl-spring-reloader * org.apache.cocoon:cocoon-rcl-webapp-wrapper * org.apache.cocoon:cocoon-22-archetype-block * org.apache.cocoon:cocoon-22-archetype-block-plain * org.apache.cocoon:cocoon-22-archetype-webapp The main idea is to split up current big COCOON JIRA project into smaller projects focused on one area. Artifacts that are not listed above would stay in COCOON project, at least for now. I don't want to create new separate projects for every artifact/block because big number of project in JIRA would not improve maintenance, quite contrary I would say. After taking this first step towards separation we should just wait and see if further divisions are needed. Each artifact belonging to JIRA project would become its component. That means we still have to have shared version number in JIRA's projects (e.g. in COCOONCORE where cocoon-core is 2.0.0 and sitemap-impl is 1.0.0) but I think its compromise between situation we have today and a situation where we have about fifty different JIRA projects that no one wants to force her way through. If we agree on the proposal I would take care of labour work, like asking JIRA for projects creation, moving issues, adjusting poms etc., myself during next weekend. What do you think? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/