Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 40954 invoked from network); 17 Apr 2007 11:53:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Apr 2007 11:53:46 -0000 Received: (qmail 75070 invoked by uid 500); 17 Apr 2007 11:53:51 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 75012 invoked by uid 500); 17 Apr 2007 11:53:50 -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 75001 invoked by uid 99); 17 Apr 2007 11:53:50 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Apr 2007 04:53:50 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [216.86.168.178] (HELO mxout-03.mxes.net) (216.86.168.178) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Apr 2007 04:53:42 -0700 Received: from [192.168.1.4] (unknown [87.206.142.101]) by smtp.mxes.net (Postfix) with ESMTP id 2F2FC5197C for ; Tue, 17 Apr 2007 07:53:21 -0400 (EDT) Message-ID: <4624B516.5060101@apache.org> Date: Tue, 17 Apr 2007 13:52:54 +0200 From: Grzegorz Kossakowski User-Agent: Thunderbird 1.5.0.10 (X11/20060911) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Archetypes, blocks, webapps ... References: <4623CBC1.2030309@apache.org> <4BB0A0EA-94A2-4B2A-9387-A2D792B4A8E1@luminas.co.uk> In-Reply-To: <4BB0A0EA-94A2-4B2A-9387-A2D792B4A8E1@luminas.co.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Andrew Savory napisaƂ(a): > Hi, > > On 16 Apr 2007, at 20:17, Grzegorz Kossakowski wrote: > >> Apparently, it's different, webapp is used to... assembly a webapp, >> run a webapp etc. However, in C2.2 every Cocoon webapp consists of set >> of blocks. Webapp gives you infrastructure to assembly your blocks >> into WAR file, it also gives you infrastructure to run (with help of >> jetty) your application. > > Right ... in which case, wouldn't it make sense to have an archetype for > 'simple' applications, that effectively calls the webapp and block > archetypes? It seems like there's currently a *lot* of work to do even > for creating a simple publishing site, with no custom code. I don't think it's "a *lot*" of work. All you have to do is to type two commands: mvn archetype:create -DarchetypeGroupId=org.apache.cocoon -DarchetypeArtifactId=cocoon-22-archetype-webapp -DarchetypeVersion=1.0.0-M2 -DgroupId=com.mycompany -DartifactId=myCocoonWebapp mvn archetype:create -DarchetypeGroupId=org.apache.cocoon -DarchetypeArtifactId=cocoon-22-archetype-block -DarchetypeVersion=1.0.0-M5 -DgroupId=com.mycompany -DartifactId=myBlock1 and add information about dependency to the myCocoonWebapp/pom.xml file (three lines of XML). Then you are done and can start coding your application. Is it that much compared to the situation in C2.1 where there were no archetypes and you had to provide skeleton for your sitemap by hand? >> >> That's right. Thinking about it further, I wonder if we could provide >> more meaningful message that webapp is empty so it cannot do any thing >> useful and one has to create block and start hacking there? > > That would be very good. I've created issue for it: https://issues.apache.org/jira/browse/COCOON-2045 > > But blocks still seem kinda heavyweight to me, if all I want is XML, > XSLT, sitemap .... I cannot follow you here. Compared to the C2.1, additional steps you need to perform is creating webapp and adding dependency to your block in webapp's pom. Creating block is actually similar to creating directory with empty sitemap in C2.1. Do I miss something that involves more effort? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/