Re: [VOTE] Javier Puerto as cocoon committer
On 28/05/12 09:26, Thorsten Scherler wrote: I propose Javier Puerto as a new Cocoon committer and PMC member. +1 Regards, David Legg
Re: [VOTE] Require Java 1.6 for Cocoon3
On Mon, 2011-09-19 at 23:03 +0200, Nathaniel, Alfred wrote: +1 = Yes, Cocoon3 shall require Java 1.6 -1 = No, Cocoon3 must remain usable with Java 1.5 (with justification for the veto) +1 Regards, David Legg
Re: [C3] New blog post about Cocoon / Wicket integration
Hi Francesco, Thanks for writing your blog post on integrating Wicket with Cocoon3. I found the example you gave very interesting. It has re-kindled my interest in Cocoon again. I remember being very interested in an article Reinhard wrote [2] a while ago on this very subject. I think it is very important to have something that can replace the functionality that CForms (a.k.a. Woody!) used to perform in C1 and C2. Regards, David Legg On Thu, 2011-06-30 at 15:15 +0200, Francesco Chicchiriccò wrote: Hi all, I've written a blog post [1] about the Cocoon / Wicket integration, making a little more complex example out of the cocoon-sample-wicket-webapp. Please let me know what do you think. Cheers. [1] http://chicchiricco.blogspot.com/2011/06/build-rich-xml-enabled-applications.html [2] http://people.apache.org/~reinhard/c3-ref/html/wicket-integration.html
Re: How to test?
Reinhard Pötz wrote: David Legg wrote: I thought I'd give C3 a go but I appear to have a couple of artifacts missing when I run Maven. They are: - com.sun.jersey:jersey-core:jar:1.0.3 com.sun.jersey:jersey-server:jar:1.0.3 Thanks David! I don't know why this can happen because I built the release artifacts on a clean machine with an empty Maven repository and without a Maven proxy. I got it to work as soon as I included the correct jersey maven repository addresses in the pom.xml file. I wrote about it in the Cocoon user mail list. Regards, David Legg.
Re: How to test?
I thought I'd give C3 a go but I appear to have a couple of artifacts missing when I run Maven. They are: - com.sun.jersey:jersey-core:jar:1.0.3 com.sun.jersey:jersey-server:jar:1.0.3 I've tried making sure I'm using the 'cocoon-staging' profile mentioned in the email but to no effect. It is getting late here now but tomorrow I'll try manually installing the missing jar files and try again. The Maven error looks as follows: - D:\projects\cocoon\cocoon3\mysamplemvn jetty:run -P cocoon-staging ... [INFO] Failed to resolve artifact. ... Missing: -- 1) com.sun.jersey:jersey-core:jar:1.0.3 Try downloading the file manually from the project website. Path to dependency: 1) com.mycompany:mysample:jar:1.0-SNAPSHOT 2) com.sun.jersey:jersey-core:jar:1.0.3 ... 2) com.sun.jersey:jersey-server:jar:1.0.3 Try downloading the file manually from the project website. Path to dependency: 1) com.mycompany:mysample:jar:1.0-SNAPSHOT 2) com.sun.jersey:jersey-server:jar:1.0.3 ... -- 2 required artifacts are missing. for artifact: com.mycompany:mysample:jar:1.0-SNAPSHOT from the specified remote repositories: cocoon.staging (http://people.apache.org/builds/cocoon), central (http://repo1.maven.org/maven2) Regards, David Legg
Re: [vote] Release Cocoon 3.0.0-alpha-2
Reinhard Pötz wrote: I've prepared the artifacts for the release of Cocoon 3.0.0-alpha-2. This majority vote stays open for at least 72 hours. Please cast your votes! +1 Regards, David Legg
Re: [VOTE] Release cocoon-xml 2.0.2
Carsten Ziegeler wrote: I've assembled a release candidate for the xml sub project. Please cast your votes. +1 Sorry, I took so long to vote. I was going to check it before voting but never got round to it! Regards, David Legg
Re: [vote] Simone Tripodi as new Cocoon committer
Reinhard Pötz wrote: I propose Simone Tripodi as a new Cocoon committer and PMC member +1 David Legg
Re: [OT] [Job] Cocoon developer required (London)
in the HTML Robby Pelssers wrote: What did you do to make it crash? ;-) I can open the home page without any issues. I've tried it on another XP machine and an Ubuntu system and... Doh! both work fine. I suspect my machine doesn't like the video object in the HTML for some reason. I have performed video editing on it before so maybe I have an errant codec installed somewhere. As you were! ;-) Regards, David Legg
Re:[OT] [Job] Cocoon developer required (London)
Hi Robin, I thought I'd take a peek at your site jacaranda.co.uk and do you know what it crashed my Firefox browser! Thinking it was some peculiarity of Firefox I tried IE7 and do you now what... it crashed that too :-) Regards, David Legg Robin Wyles wrote: Hi everyone, It's been a very long time since I've posted here (apologies, and hopefully more on that soon!)... We're looking for a Cocoon developer to help me out with the support and further development of our Cocoon based applications. We need strong skills in Cocoon, Spring, Linux, and preferably someone based in or near to London, UK. We're looking for someone which we can work with on a regular basis, and possibly even as a full-time position. If you're at all interested drop me an email with a little info about yourself: ro...@jacaranda.co.uk Thanks! Robin
Re: [VOTE] Release Cocoon Serializers Charset and Block
Carsten Ziegeler wrote: please vote on a first release of these two artifacts: Apache Cocoon Serializers Charsets 1.0.0 http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-serializers-charsets/1.0.0/ and Apache Cocoon Serializers Block 1.0.0 http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-serializers-impl/1.0.0/ +1 I look forward to the addition of this block though I wonder what sort of confusion will arise when users start talking about the 'HTMLSerializer'! Do they mean: org.apache.cocoon.serialization.HTMLSerializer http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/serialization/HTMLSerializer.html or maybe: org.apache.cocoon.components.serializers.HTMLSerializer I updated the old HTMLSerializer document page [1] and mentioned that two implementations exist. The same will need doing for the new serializers. [1] http://cocoon.zones.apache.org/daisy/cdocs/g1/g1/g2/g4/Serializer/896.html Regards, David Legg
Re: Cocoon wiki still down
Hi Robby, One of the Apache servers had some problems today. It looks as if it has been fixed now. Thanks for letting us know. David Legg. Robby Pelssers wrote: *http://cocoon.zones.apache.org/daisy/cdocs/1201.html* * * *502 Bad Gateway* /The upstream server is not responding./
Re: Spring Configurator Docs
I have to agree that the current documentation system is a bit of a nightmare. As I see it there are too many hurdles that have to be passed through before documents become visible to the general public. I had a go at updating a few pages using the Daisy system. Editing an existing document is easy enough but I never had the time to learn how to drive the navigation sytem... and I suspect nobody else did either ;-) This is why moving between docs is so difficult. Also it might have seemed like a brilliant idea to extract documentation directly out of the code but that actually adds a further barrier to getting it done as you are then faced with updating the code when all you wanted to do was write about it. The final hurdle is that even after you have edited the page and made it active it still isn't visible on the main Cocoon site until some arcane command line incantations are performed. Bring back the wiki I say! Regards, David Legg
Documentation System [was: Spring Configurator Docs]
Hi Luca, Also it might have seemed like a brilliant idea to extract documentation directly out of the code but that actually adds a further barrier to getting it done as you are then faced with updating the code when all you wanted to do was write about it. One has to choose the lesser of two evils: steeper learning curve vs probable de-synchronization of docs from the actual code... I'd say the former is the less harmful. I *was* going to respond by listing all the pages which currently say No documentation available yet e.g. [1]. But as I started I realized you were right :-) I can see now that automatically lifting information out of the code has, if anything, saved the docs from being completely bare! I still cringe about the number of empty pages. I must continue to put more content in... I believe it is killing the project at the moment. The final hurdle is that even after you have edited the page and made it active it still isn't visible on the main Cocoon site until some arcane command line incantations are performed. I think having a staging docbase is not bad at all, it lets you revise stuff before being published, not to mention the better performance of the published site. I just tried looking at the documentation for this [2] and noticed it has been updated. It looks easier to do now! Ok... you win! Regards, David Legg [1] http://cocoon.apache.org/2.2/core-modules/core/2.2/1043_1_1.html [2] http://cocoon.apache.org/1418_1_1.html
Re: Documentation System [was: Spring Configurator Docs]
Luca, I did some documentation port myself, but I have to admit it is not that easy, since something *may* indeed have changed in the passage... bottom line: you have to know a component's behaviour in both 2.1 and 2.2 before safely porting its doc. You're so right about that. It is a big job. I started updating the HTMLSerializer [1] but then realized there were actually two implementations of it with different sets of parameters. Not only that but a lot of 'folklore' and list wisdom was trapped in the mailing list and on the old wiki over the last few years and that needed to be set free. Regards, David Legg [1] http://cocoon.zones.apache.org/daisy/cdocs/g1/g1/g2/g4/Serializer/896.html
Re: [VOTE] Release cocoon-xml 2.0.0
Hi Carsten, Carsten Ziegeler wrote: I've assembled a first release candidate for the new xml sub project containing useful stuff for dom and sax handling. The module is small and focused and could be used as a utility lib for C3. I've had a look at the release candidate. I'm not sure about the utility of the SAXUtils class. I think using them will tend to obfuscate any code that uses it but it's a minor point. I'm not too happy about the various 'protected' fields like the ones in SAXBuffer.java or DOMBuilder.java etc. It would be all too easy to write code that accidentally abused these fields. I suppose this could be fixed later by making them private. Here's my +1 Regards, David Legg
Why does Cocoon docs keep repeating old updates?
Has anyone else noticed that the Cocoon Docs mailing list sometimes keeps spewing out updates that happened months ago? Does something do this as a result of being rebooted every now and then? I've just received 11 new Cocoon Doc update messages. This happens often enough to make me think there is a configuration error somewhere. Regards, David Legg
Re: [VOTE] Robin Wyles as new Cocoon committer
I propose Robin Wyles as a new Cocoon committer and PMC member. +1 David Legg
Re: [C2.2] Why two sets of HTML serializers?
Good call Reinhard, thanks! Reinhard Pötz wrote: I've perused the developer mail archive and the svn log but not found anything about the background for this second implementation. See http://cocoon.markmail.org/message/z63kh2sx3u4spxo No wonder I didn't find it... 2004 is ancient history ;-) Regards, David Legg
[C2.2] Why two sets of HTML serializers?
I've been examining the HTMLSerializer so that I can document it on Daisy. Initially, I was confused about what config options could be used and then it dawned on me that there are actually two different implementations! The default is to use: o.a.c.serialization.HTMLSerializer but there is another one called: o.a.c.components.serializers.HTMLSerializer I'm assuming that this second version is an attempt to move away from depending on Xalan for outputting HTML. I also note that it makes life easier for users by implementing a 'doctype-default' config setting which takes 'strict', 'loose', 'frameset' or 'compatible' as values. I've perused the developer mail archive and the svn log but not found anything about the background for this second implementation. Could someone just confirm that I'm on the right track. Is the intention to make the second implementation the default at some point? What other advantages does this new version have? Regards, David Legg
Should HTMLSerializer be more strict about strict 4.01 HTML?
In playing around with the HTML serializer I've noticed that the strict 4.01 doctype doesn't actually prevent invalid output. For example the 'align' property in IMG align=right src=someimage.jpg is deprecated (because it is considered presentational) and fails the W3C validator if let through. I'm wondering if maybe the serializer should silently correct this by leaving deprecated properties out. I can't see any better way to fix this except by embedding styles in the output... but that seems horrible. The other alternative of causing an exception seems equally oppressive but maybe it would help in the long run. Any ideas? David Legg
Re: [vote] David Legg as new Cocoon committer
Hi Grek, I would like to propose David Legg as a new Cocoon committer and PMC Member. Thank you very much for your kind words. I've just returned from a two week holiday (with no internet connection) and your message along with the community's response was a lovely surprise. I hope I'm not jumping the gun before voting is complete so I shall wait for the summary. I hope that this nomination will help David will improving our documentation even more. :-) Now we get to the real motive ;-) David Legg
Re: [summary][vote] David Legg as new Cocoon committer
Once again, I'd like to thank the community for accepting me as a Cocoon committer. Finally, it is a good tradition that a new committer introduces himself on this list. I'm an English web developer, married with a child and working in Bracknell, England. I've been lurking around Cocoon for what seems like forever (read 2000). Back then SoC (Separation of Concerns), XML and XSLT were all shiny and new. I started my career back in 1984 writing 8086 assembler for a chess games company (oh yes! non of that 8-bit rubbish for me!). I even remember wondering if I should download Minix or something called Linux from some student upstart called Linus Torvalds ;-) The best thing I learnt from these early days was a healthy respect for designing memory efficient software. Gradually and inevitably I moved over from writing system software and firmware to this new fangled thing called the web. This is where I fell in love with Java, Tomcat and JSP programming. My current interests lie in the semantic web and the world of triplestores, inference engines and RDF and how to do something useful with it all. You can be sure I'll be trying to glue it together with Cocoon. It's a privilege to be a part of this project. David Legg
[jira] Commented: (COCOON-2215) Picture of Cocoon pipeline is missing on live site
[ https://issues.apache.org/jira/browse/COCOON-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607161#action_12607161 ] David Legg commented on COCOON-2215: Actually, having looked more closely at this issue it is not just the picture that is missing. I believe it is simply that the latest Daisy version has not been transferred to the live site. Picture of Cocoon pipeline is missing on live site -- Key: COCOON-2215 URL: https://issues.apache.org/jira/browse/COCOON-2215 Project: Cocoon Issue Type: Improvement Components: - Documentation Affects Versions: 2.2 Reporter: David Legg Priority: Minor The Daisy site shows a picture of a typical Cocoon pipeline in the tutorial but it is completely missing in the live web page (http://cocoon.apache.org/2.2/1290_1_1.html). In Daisy the image is defined as http://cocoon.zones.apache.org/daisy/cdocs/367/version/default/part/ImageData/data/pipeline.gif -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2214) Update C22 block building process through use of Maven archetype:generate command
[ https://issues.apache.org/jira/browse/COCOON-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607119#action_12607119 ] David Legg commented on COCOON-2214: The Maven group have responded. By default if you don't specify the name of the archetype catalog file then the archetype plugin tacks the name on the end of the URL you give. This is excellent news because it simplifies the command required to build a Cocoon block still further and it works with the existing version of the plugin (2.0 alpha-3). I have updated the documentation http://cocoon.zones.apache.org/daisy/cdocs/g2/g2/g2/1159.html on the Daisy site. I'll let you check it over and transfer it to the live site at your leisure. Update C22 block building process through use of Maven archetype:generate command - Key: COCOON-2214 URL: https://issues.apache.org/jira/browse/COCOON-2214 Project: Cocoon Issue Type: Improvement Components: - Build System: Maven, - Documentation Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: David Legg Assignee: Grzegorz Kossakowski Priority: Minor Attachments: archetype-catalog.xml Version 2.0.9 (and maybe earlier) of Maven has deprecated the use of the archetype:create goal in favour of archetype:generate. As of this report the Cocoon Tutorial uses archetype:create in its instructions and this causes a warning to be issued when attempting to build blocks. After discussion on the list it was felt the solution was to start using archetype:generate but this changes the behaviour of Maven such that it interactively asks for values such as the artifactId and groupId etc. Unfortunately, the first question it asks is which archetype you wish to build and by default this list is huge and will continue to grow as more projects use it. Attached to this note is a file which if placed in a suitable location on the Cocoon web site could be used to reduce the archetype list to just those required for Cocoon (Currently 3 items). The Cocoon tutorial would need to be updated to replace the archetype:create command to something like the following: - mvn archetype:generate -DarchetypeCatalog=http://[path to catalog]/archetype-catalog.xml This would generate output similar to the following: - [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. ... [INFO] [archetype:generate] [INFO] Generating project in Interactive mode [INFO] No archetype defined. Using maven-archetype-quickstart (org.apache.maven.archetypes:maven-archetype-quickstart:1.0) Choose archetype: 1: local - cocoon-22-archetype-block-plain (Creates an empty Cocoon block) 2: local - cocoon-22-archetype-block (Creates a minimal Cocoon block) 3: local - cocoon-22-archetype-webapp (Creates a web application Cocoon block) Choose a number: (1/2/3): Choose archetype: This should be much more comprehensible to new users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (COCOON-2214) Update C22 block building process through use of Maven archetype:generate command
[ https://issues.apache.org/jira/browse/COCOON-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607119#action_12607119 ] djl edited comment on COCOON-2214 at 6/22/08 3:41 PM: - The Maven group have responded. By default if you don't specify the name of the archetype catalog file then the archetype plugin tacks the name on the end of the URL you give. This is excellent news because it simplifies the command required to build a Cocoon block still further and it works with the existing version of the plugin (2.0 alpha-3). I have updated the documentation http://cocoon.zones.apache.org/daisy/cdocs/g2/g2/g2/1159.html and http://cocoon.zones.apache.org/daisy/cdocs/g2/g2/g2/1291.html on the Daisy site. I'll let you check it over and transfer it to the live site at your leisure. was (Author: djl): The Maven group have responded. By default if you don't specify the name of the archetype catalog file then the archetype plugin tacks the name on the end of the URL you give. This is excellent news because it simplifies the command required to build a Cocoon block still further and it works with the existing version of the plugin (2.0 alpha-3). I have updated the documentation http://cocoon.zones.apache.org/daisy/cdocs/g2/g2/g2/1159.html on the Daisy site. I'll let you check it over and transfer it to the live site at your leisure. Update C22 block building process through use of Maven archetype:generate command - Key: COCOON-2214 URL: https://issues.apache.org/jira/browse/COCOON-2214 Project: Cocoon Issue Type: Improvement Components: - Build System: Maven, - Documentation Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: David Legg Assignee: Grzegorz Kossakowski Priority: Minor Attachments: archetype-catalog.xml Version 2.0.9 (and maybe earlier) of Maven has deprecated the use of the archetype:create goal in favour of archetype:generate. As of this report the Cocoon Tutorial uses archetype:create in its instructions and this causes a warning to be issued when attempting to build blocks. After discussion on the list it was felt the solution was to start using archetype:generate but this changes the behaviour of Maven such that it interactively asks for values such as the artifactId and groupId etc. Unfortunately, the first question it asks is which archetype you wish to build and by default this list is huge and will continue to grow as more projects use it. Attached to this note is a file which if placed in a suitable location on the Cocoon web site could be used to reduce the archetype list to just those required for Cocoon (Currently 3 items). The Cocoon tutorial would need to be updated to replace the archetype:create command to something like the following: - mvn archetype:generate -DarchetypeCatalog=http://[path to catalog]/archetype-catalog.xml This would generate output similar to the following: - [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. ... [INFO] [archetype:generate] [INFO] Generating project in Interactive mode [INFO] No archetype defined. Using maven-archetype-quickstart (org.apache.maven.archetypes:maven-archetype-quickstart:1.0) Choose archetype: 1: local - cocoon-22-archetype-block-plain (Creates an empty Cocoon block) 2: local - cocoon-22-archetype-block (Creates a minimal Cocoon block) 3: local - cocoon-22-archetype-webapp (Creates a web application Cocoon block) Choose a number: (1/2/3): Choose archetype: This should be much more comprehensible to new users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2215) Picture of Cocoon pipeline is missing on live site
Picture of Cocoon pipeline is missing on live site -- Key: COCOON-2215 URL: https://issues.apache.org/jira/browse/COCOON-2215 Project: Cocoon Issue Type: Improvement Components: - Documentation Affects Versions: 2.2 Reporter: David Legg Priority: Minor The Daisy site shows a picture of a typical Cocoon pipeline in the tutorial but it is completely missing in the live web page (http://cocoon.apache.org/2.2/1290_1_1.html). In Daisy the image is defined as http://cocoon.zones.apache.org/daisy/cdocs/367/version/default/part/ImageData/data/pipeline.gif -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2214) Update C22 block building process through use of Maven archetype:generate command
[ https://issues.apache.org/jira/browse/COCOON-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12606923#action_12606923 ] David Legg commented on COCOON-2214: Thanks for that Grek. I began updating the documentation but then ran into a problem. It seems Maven can't handle remote archetype catalogs yet after all. I naturally assumed that since it handled the file:// protocol it would also handle http:// protocol but it mangles the URL. I've raised a report on the Maven JIRA (http://jira.codehaus.org/browse/ARCHETYPE-124) and we'll see how it goes. One work around is to download the file from the server and then use the file:// protocol. I've tested that and it works. Update C22 block building process through use of Maven archetype:generate command - Key: COCOON-2214 URL: https://issues.apache.org/jira/browse/COCOON-2214 Project: Cocoon Issue Type: Improvement Components: - Build System: Maven, - Documentation Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: David Legg Assignee: Grzegorz Kossakowski Priority: Minor Attachments: archetype-catalog.xml Version 2.0.9 (and maybe earlier) of Maven has deprecated the use of the archetype:create goal in favour of archetype:generate. As of this report the Cocoon Tutorial uses archetype:create in its instructions and this causes a warning to be issued when attempting to build blocks. After discussion on the list it was felt the solution was to start using archetype:generate but this changes the behaviour of Maven such that it interactively asks for values such as the artifactId and groupId etc. Unfortunately, the first question it asks is which archetype you wish to build and by default this list is huge and will continue to grow as more projects use it. Attached to this note is a file which if placed in a suitable location on the Cocoon web site could be used to reduce the archetype list to just those required for Cocoon (Currently 3 items). The Cocoon tutorial would need to be updated to replace the archetype:create command to something like the following: - mvn archetype:generate -DarchetypeCatalog=http://[path to catalog]/archetype-catalog.xml This would generate output similar to the following: - [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. ... [INFO] [archetype:generate] [INFO] Generating project in Interactive mode [INFO] No archetype defined. Using maven-archetype-quickstart (org.apache.maven.archetypes:maven-archetype-quickstart:1.0) Choose archetype: 1: local - cocoon-22-archetype-block-plain (Creates an empty Cocoon block) 2: local - cocoon-22-archetype-block (Creates a minimal Cocoon block) 3: local - cocoon-22-archetype-webapp (Creates a web application Cocoon block) Choose a number: (1/2/3): Choose archetype: This should be much more comprehensible to new users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2214) Update C22 block building process through use of Maven archetype:generate command
[ https://issues.apache.org/jira/browse/COCOON-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Legg updated COCOON-2214: --- Attachment: (was: archetype-catalog.xml) Update C22 block building process through use of Maven archetype:generate command - Key: COCOON-2214 URL: https://issues.apache.org/jira/browse/COCOON-2214 Project: Cocoon Issue Type: Improvement Components: - Build System: Maven, - Documentation Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: David Legg Assignee: Grzegorz Kossakowski Priority: Minor Version 2.0.9 (and maybe earlier) of Maven has deprecated the use of the archetype:create goal in favour of archetype:generate. As of this report the Cocoon Tutorial uses archetype:create in its instructions and this causes a warning to be issued when attempting to build blocks. After discussion on the list it was felt the solution was to start using archetype:generate but this changes the behaviour of Maven such that it interactively asks for values such as the artifactId and groupId etc. Unfortunately, the first question it asks is which archetype you wish to build and by default this list is huge and will continue to grow as more projects use it. Attached to this note is a file which if placed in a suitable location on the Cocoon web site could be used to reduce the archetype list to just those required for Cocoon (Currently 3 items). The Cocoon tutorial would need to be updated to replace the archetype:create command to something like the following: - mvn archetype:generate -DarchetypeCatalog=http://[path to catalog]/archetype-catalog.xml This would generate output similar to the following: - [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. ... [INFO] [archetype:generate] [INFO] Generating project in Interactive mode [INFO] No archetype defined. Using maven-archetype-quickstart (org.apache.maven.archetypes:maven-archetype-quickstart:1.0) Choose archetype: 1: local - cocoon-22-archetype-block-plain (Creates an empty Cocoon block) 2: local - cocoon-22-archetype-block (Creates a minimal Cocoon block) 3: local - cocoon-22-archetype-webapp (Creates a web application Cocoon block) Choose a number: (1/2/3): Choose archetype: This should be much more comprehensible to new users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2214) Update C22 block building process through use of Maven archetype:generate command
[ https://issues.apache.org/jira/browse/COCOON-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Legg updated COCOON-2214: --- Attachment: archetype-catalog.xml I have updated the attached file as suggested. 1. An Apache header has been added. 2. The versions have been set to the latest (non-SNAPSHOT) versions listed in http://repo1.maven.org/maven2/org/apache/cocoon/ 3. The descriptions have been made a little more descriptive. Unfortunately, they no longer display comfortably in a DOS command box but that is a small price to pay. Update C22 block building process through use of Maven archetype:generate command - Key: COCOON-2214 URL: https://issues.apache.org/jira/browse/COCOON-2214 Project: Cocoon Issue Type: Improvement Components: - Build System: Maven, - Documentation Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: David Legg Assignee: Grzegorz Kossakowski Priority: Minor Attachments: archetype-catalog.xml Version 2.0.9 (and maybe earlier) of Maven has deprecated the use of the archetype:create goal in favour of archetype:generate. As of this report the Cocoon Tutorial uses archetype:create in its instructions and this causes a warning to be issued when attempting to build blocks. After discussion on the list it was felt the solution was to start using archetype:generate but this changes the behaviour of Maven such that it interactively asks for values such as the artifactId and groupId etc. Unfortunately, the first question it asks is which archetype you wish to build and by default this list is huge and will continue to grow as more projects use it. Attached to this note is a file which if placed in a suitable location on the Cocoon web site could be used to reduce the archetype list to just those required for Cocoon (Currently 3 items). The Cocoon tutorial would need to be updated to replace the archetype:create command to something like the following: - mvn archetype:generate -DarchetypeCatalog=http://[path to catalog]/archetype-catalog.xml This would generate output similar to the following: - [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. ... [INFO] [archetype:generate] [INFO] Generating project in Interactive mode [INFO] No archetype defined. Using maven-archetype-quickstart (org.apache.maven.archetypes:maven-archetype-quickstart:1.0) Choose archetype: 1: local - cocoon-22-archetype-block-plain (Creates an empty Cocoon block) 2: local - cocoon-22-archetype-block (Creates a minimal Cocoon block) 3: local - cocoon-22-archetype-webapp (Creates a web application Cocoon block) Choose a number: (1/2/3): Choose archetype: This should be much more comprehensible to new users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2214) Update C22 block building process through use of Maven archetype:generate command
Update C22 block building process through use of Maven archetype:generate command - Key: COCOON-2214 URL: https://issues.apache.org/jira/browse/COCOON-2214 Project: Cocoon Issue Type: Improvement Components: - Build System: Maven, - Documentation Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: David Legg Priority: Minor Version 2.0.9 (and maybe earlier) of Maven has deprecated the use of the archetype:create goal in favour of archetype:generate. As of this report the Cocoon Tutorial uses archetype:create in its instructions and this causes a warning to be issued when attempting to build blocks. After discussion on the list it was felt the solution was to start using archetype:generate but this changes the behaviour of Maven such that it interactively asks for values such as the artifactId and groupId etc. Unfortunately, the first question it asks is which archetype you wish to build and by default this list is huge and will continue to grow as more projects use it. Attached to this note is a file which if placed in a suitable location on the Cocoon web site could be used to reduce the archetype list to just those required for Cocoon (Currently 3 items). The Cocoon tutorial would need to be updated to replace the archetype:create command to something like the following: - mvn archetype:generate -DarchetypeCatalog=http://[path to catalog]/archetype-catalog.xml This would generate output similar to the following: - [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. ... [INFO] [archetype:generate] [INFO] Generating project in Interactive mode [INFO] No archetype defined. Using maven-archetype-quickstart (org.apache.maven.archetypes:maven-archetype-quickstart:1.0) Choose archetype: 1: local - cocoon-22-archetype-block-plain (Creates an empty Cocoon block) 2: local - cocoon-22-archetype-block (Creates a minimal Cocoon block) 3: local - cocoon-22-archetype-webapp (Creates a web application Cocoon block) Choose a number: (1/2/3): Choose archetype: This should be much more comprehensible to new users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2214) Update C22 block building process through use of Maven archetype:generate command
[ https://issues.apache.org/jira/browse/COCOON-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Legg updated COCOON-2214: --- Attachment: archetype-catalog.xml A Maven archetype catalog file ready for uploading to the Cocoon web site. Update C22 block building process through use of Maven archetype:generate command - Key: COCOON-2214 URL: https://issues.apache.org/jira/browse/COCOON-2214 Project: Cocoon Issue Type: Improvement Components: - Build System: Maven, - Documentation Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: David Legg Priority: Minor Attachments: archetype-catalog.xml Version 2.0.9 (and maybe earlier) of Maven has deprecated the use of the archetype:create goal in favour of archetype:generate. As of this report the Cocoon Tutorial uses archetype:create in its instructions and this causes a warning to be issued when attempting to build blocks. After discussion on the list it was felt the solution was to start using archetype:generate but this changes the behaviour of Maven such that it interactively asks for values such as the artifactId and groupId etc. Unfortunately, the first question it asks is which archetype you wish to build and by default this list is huge and will continue to grow as more projects use it. Attached to this note is a file which if placed in a suitable location on the Cocoon web site could be used to reduce the archetype list to just those required for Cocoon (Currently 3 items). The Cocoon tutorial would need to be updated to replace the archetype:create command to something like the following: - mvn archetype:generate -DarchetypeCatalog=http://[path to catalog]/archetype-catalog.xml This would generate output similar to the following: - [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. ... [INFO] [archetype:generate] [INFO] Generating project in Interactive mode [INFO] No archetype defined. Using maven-archetype-quickstart (org.apache.maven.archetypes:maven-archetype-quickstart:1.0) Choose archetype: 1: local - cocoon-22-archetype-block-plain (Creates an empty Cocoon block) 2: local - cocoon-22-archetype-block (Creates a minimal Cocoon block) 3: local - cocoon-22-archetype-webapp (Creates a web application Cocoon block) Choose a number: (1/2/3): Choose archetype: This should be much more comprehensible to new users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Editing rights
Hi, I'd like to be given document editing rights on the Cocoon CMS please. I've created the account 'djl' for this purpose. I've followed Cocoon for several years now. I've noticed the desperate need for documentation with the advent of version 2.2 and I'd like to help out. Regards, David Legg
