Re: Site Updates
Reinhard P??tz wrote: Simone Tripodi wrote: Hi Reinhard, I just modified the skin and updated the new site version - I took time because of the maven build but everything worked fine. I did the svn up on the server side, it updated the pages but the don't appear updated on the browser. Is there anything I missed or the pages are just cached? Thanks in advance, see you! There is some sync mechanism that copies /www/* of people.apache.org every hour. See info at: http://apache.org/dev/#web http://apache.org/dev/project-site.html -David
[jira] Commented: (COCOON-2273) Download page does not have link to KEYS file; hashes/sigs must point to main ASF site
[ https://issues.apache.org/jira/browse/COCOON-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12793412#action_12793412 ] David Crossley commented on COCOON-2273: Would someone please attend to this. I am concerned that there has been no action, but cannot help as i cannot handle Maven. Download page does not have link to KEYS file; hashes/sigs must point to main ASF site -- Key: COCOON-2273 URL: https://issues.apache.org/jira/browse/COCOON-2273 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Reporter: Sebb Priority: Critical The download page http://cocoon.apache.org/1284_1_1.html has links to sigs and hashes. However these links point to the mirrors, but they should point to the main Apache server, i.e instead of http://www.apache.org/dyn/closer.cgi/cocoon/2.2/cocoon-2.2.0.zip.asc the link should be http://www.apache.org/dist/cocoon/2.2/cocoon-2.2.0.zip.asc Also, the download page must have a link to the KEYS file, i.e. http://www.apache.org/dist/cocoon/KEYS (otherwise the pgp - .asc - links aren't much use) The .md5.asc and .sha1.asc files are redundant and should be deleted from the dist/ directory tree. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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
Re: closeLoudly()
Jos Snellings wrote: I attached the patch. Is this the proper way to submit? Thanks, and please excuse me my ignorance. It is the first time. (first times can be traumatic, so far I am feeling well). Thanks for your help. As Simone suggested below, the issue tracker is way better for many reasons. Ideally then also follow up here by mentioning the issue number. http://issues.apache.org/jira/browse/COCOON3 http://issues.apache.org/jira/browse/COCOON Jos Snellings wrote: Thank you, Simone. I will do that. Simone Tripodi wrote: Hi Jos, nice to meet you :) Usually suggestions of this kind have to be submitted by the issue tracker: http://issues.apache.org/jira/browse/COCOON3 Make your own patch through the command line: svn diff -x -u Main.java arg-fix.patch giving your patch file meaningful name. Goof job! Simo
assistance with Apache Forrest
I did some research to find the ASF projects that manage their websites with Apache Forrest, and am sending similar email to each project's dev mail list. For Cocoon, it is only the cocoon/2.1/ site that is handled by Forrest: http://wiki.apache.org/cocoon/CocoonWebsiteUpdate --- oOo --- The purposes of this email are to remind people about some of the useful facilities of Forrest, and also alert them to discussion about the status and future directions of Forrest, and to appeal for people to assist Forrest. --- oOo --- These are useful facilities to assist with developing and managing a Forrest solution for your project's website. How to deploy documentation with the Forrestbot svn workstage This explains how the Forrest project manages our own documentation. http://forrest.apache.org/howto-forrestbot-svn.html Generate an ASF mirrors page using interactive web form http://forrest.apache.org/docs/dev/howto/howto-asf-mirror.html ForrestBar - Firefox toolbar to ease navigation and search of Forrest resources http://forrest.apache.org/tools/forrestbar.html How to do development with Apache Forrest http://forrest.apache.org/howto-dev.html Frequently Asked Questions http://forrest.apache.org/faq.html The Anakia output plugin This was developed to assist the old Incubator website to stop using Forrest and export all content to an Anakia xdoc format. From there it could used by an Anakia-based build system, or be further transformed. http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.Anakia/ As usual, if you need further assistance with anything then please ask on the Forrest mail lists. --- oOo --- There is discussion currently underway on the Forrest dev mail list about the current status and future direction of Forrest. http://thread.gmane.org/gmane.text.xml.forrest.devel/27325 If anyone can assist Forrest, in any capacity, then please do. -David
Re: editing rights Cocoon documentation for user account robbypelssers
Robby Pelssers wrote: My ICLA has just been sent to secret...@apache.org. Happy to contribute, Robby Thanks, i see that it is now recorded in SVN. -David
Re: editing rights Cocoon documentation for user account robbypelssers
Vadim Gritsenko wrote: Robby Pelssers wrote: Can you grant editing rights to useraccount ?robbypelssers? for the cocoon documentation? Done Thanks for helping Cocoon, Robby. Would you please also send in a Contributor License Agreement http://apache.org/licenses/#clas -David
Re: XPathXMLFileModule differences
On Thu, Aug 27, 2009 Ralph Goers wrote: It has been quite a while since I last worked on Cocoon, but since I wrote XPathXMLFileModule I suppose I am best qualified to answer the question. XPathXMLFileModule is a replacement for XMLFileModule but it is not completely compatible - which is why it is a new module and not just an upgraded version of the old one. The differences were itemized in https://issues.apache.org/jira/browse/COCOON-1574 (see my comment on Dec 27, 2007) Thanks for your answer Ralph, and for your work. I am just Cc forrest-dev list. -David
Re: Cocoon 3 monitoring is now GSoC '09 project
Dariusz ??uksza wrote: Hi cocoon dev community, After official GSoC announcement[1] I'm and Reinhard (as my mentor) are in the program. I already introduce my self[2] on a dev list. I'll be implementing new monitoring feature for C3 (based on Spring JMX) as a I mention before. So if you have any questions for me or rather suggestion on documenting that I could read in a community bonding period please fell free to mail me or contact via IRC I'm on freenode IRC network on channel #cocoon under [LocK] nick name ;) Hmmm, part of the idea of GSoC is to get people involved in the development community. That means this dev mail list, not IRC. Using chat does not enable the community to conduct oversight, nor be properly involved because it restricts activity to time-zone based cliques. Also there is no record of activity in the mail archives. -David I'm looking forward to hearing from you ;) [1] http://socghop.appspot.com/org/home/google/gsoc2009/asf [2] http://tiny.cc/tbbEf -- Best regards Blog: http://luksza.org LinkedIn: http://www.linkedin.com/in/dariuszluksza
Re: [cocoon3] Stax Pipelines
Reinhard P?tz wrote: I've had Stax pipelines on my radar for a rather long time because I think that Stax can simplify the writing of transformers a lot. I proposed this idea to Alexander Schatten, an assistant professor at the Vienna University of Technology and he then proposed it to his students. This is a fantastic moment for open source. Thanks to all involved. More of this style of collaboration please. -David
Re: Where is Cocoon 3 going to?
Grzegorz Kossakowski wrote: Steven Dolg pisze: I second this ask. Bombing us with patches that are not discussed here is what we all want to avoid. The number of patches from Simone hardly qualifies for being called bombing. Actually the issue mentioned has exactly one patch. Furthermore I doubt every single change needs to be discussed here before it is made. Something as straightforward as cache the XSLT to avoid parsing it every single time the pipeline is executed is IMO one of those things that should be obvious to everyone. The idea is obvious, the implementation details as we can see are not so obvious. Especially since - as Sylvain pointed out - this feature has been available in Cocoon for ages. Yep, but if the sequence of events had been a little bit different then the patch wouldn't have to be rewritten. The idea is not to write detailed plan that is almost comparable with final implementation but simple saying I'm going to implement this and this, using this and this. If someone wants to comment. Go ahead. A few sentences, right? I too was concerned when i saw new patches to re-implement something that Cocoon has already spent years developing. A little bit of discussion is a good thing. It enables the rest of the community to feel that they are still in touch with the direction of the project. -David Not everyone is fond of reading long emails that sketch a vague picture. A clear description of the problem, a suggested solution and a patch that provides a working implementation is IMO sometimes preferable. Everyone is able to have a look at the jira issues and the posted patch(es) and comment on them just like Sylvain did. After studying recent issues on COCOON3 I have to admit that level of discussions has increased which makes me happy. There are several reasons why things should be discussed here. One of them is that one can grasp what has happened during his offline period. As for now let's move on more specific things. I'd like to hear your opinion on functional sitemap, Steven! -- Grzegorz
Re: DTD validation
On Thu, Sep 04, 2008 at 02:07:19PM -0500, Lars Huttar wrote: [But we cannot read it.] Lars, please use plain text, not html. -David
Re: Please add me to jira admins
Thorsten Scherler wrote: please add me to the jira group that can link to issues and manage them. Done. -David
Re: Jira karma
Jasha Joachimsthal wrote: could someone please give me more karma in Jira so I can assign issues to myself en resolve them? Done. I can bulk assign issues if you want :-) Also added Luca, Steven, David, Andreas. -David
Re: [vote] Release of cocoon-template-impl-1.0.0 and cocoon-forms-impl-1.0.0
Grzegorz Kossakowski wrote: You can find the staged files for all modules (sources, binaries, javadocs, checksums, gpg signatures) at - http://people.apache.org/builds/cocoon/ (Maven 2 repo) - http://people.apache.org/~gkossakowski/cocoon-staging/ (Standard release artifacts) SVN tags of all these artifacts can be found at http://svn.apache.org/repos/asf/cocoon/tags/. This majority vote stays open for 72 hours. Which is past. Reinhard's recent vote almost failed too. This is worrying. Please cast your votes. Here is my +1 After testing them throughly with rather big application that heavily relies on both Forms and Templates blocks. No problems were found. Here is my +1 I didn't do any testing. I did verify your PGP signatures and md5 sums for the *.tar.gz artefacts. I looked at some of our source license headers, and at licenses of dependencies to see if they require attribution. No need, so our minimal NOTICE.txt are fine. -David
Re: [vote] Release of servlet-service-impl-1.1.0, spring-configurator-2.0.0, jnet-1.0.0, block-deployment-1.0.0, cocoon-maven-plugin-1.0.0-M3
David Crossley wrote: Reinhard P?tz wrote: Currently the proposed artifacts can only be tested either with latest trunk or Corona. Actual testing is beyond me. You can find the staged files for all modules (sources, binaries, javadocs, checksums, gpg signatures) at I verified all checksums for *.tar.gz and random ones for jars. My gpg is broken at the moment, so not done. Fixed it. Now i have verified that the signatures are okay. -David Unpacked, and manually looked at license file and file headers. Not tried RAT. Did my other usual checks. +1 from me. -David
Re: [vote] Release of servlet-service-impl-1.1.0, spring-configurator-2.0.0, jnet-1.0.0, block-deployment-1.0.0, cocoon-maven-plugin-1.0.0-M3
Reinhard P?tz wrote: Currently the proposed artifacts can only be tested either with latest trunk or Corona. Actual testing is beyond me. You can find the staged files for all modules (sources, binaries, javadocs, checksums, gpg signatures) at I verified all checksums for *.tar.gz and random ones for jars. My gpg is broken at the moment, so not done. Unpacked, and manually looked at license file and file headers. Not tried RAT. Did my other usual checks. +1 from me. -David
people.a.o m2-snapshot-repository
Reinhard P?tz wrote: Grzegorz Kossakowski wrote: I believe that this dependency was stored on our snapshots repository, but now it seems to be empty, see: http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/javaflow/ More interesting thing is that, it seems to be empty for any other artifact. Does anybody know what happened there? According to a mail from today on the [EMAIL PROTECTED], all snapshots older than 30 days were deleted in order to increase the free disk space. It concerns far more than that. Some projects are not following ASF legal procedures, and are using the snapshot repository instead of doing proper release procedures. See that thread on the infrastructure@ list. -David
Re: [vote] Java 1.5 as minimal requirement for trunk
Grzegorz Kossakowski wrote: Please cast your votes: +1 -David
Re: [Vote] Jasha Joachimsthal as new Cocoon committer
Andrew Savory wrote: It's my pleasure to propose Jasha Joachimsthal as a new committer on the Apache Cocoon project. +1 from me. -David
Re: [vote] David Legg as new Cocoon committer
Grzegorz Kossakowski wrote: I would like to propose David Legg as a new Cocoon committer and PMC Member. +1 -David
[summary] [vote] Luca Morandini as new Cocoon committer
David Crossley wrote: I would like to propose Luca Morandini as a new Cocoon committer and PMC member. During the time period there were no negative votes, and more than 3 positive votes. So Luca, welcome as a new Apache Cocoon committer. Here are the next steps. There is no rush. You can provide the answers here or use the private AT cocoon.a.o address if you prefer. We are generally following the procedure at: http://www.apache.org/dev/#pmc http://www.apache.org/dev/pmc.html#newcommitter You need to send a Contributor License Agreement to the ASF. Normally you would send just an Individual CLA. If you also make contributions done in work time or using work resources then see the additional Corporate CLA. It is up to you if you need that additional CLA, as the Individual CLA declares that you are legally entitled. Ask us if you have any issues. http://www.apache.org/licenses/#clas You need to choose a preferred ASF user name and alternatives. See the existing names http://www.apache.org/~jim/committers.html When we see the ASF volunteer secretary record the receipt of the CLA in an svn commit, we can proceed to ask Infrastructure to set up your account. The developer section of the website describes the roles and provides other resources. Especially important are the ones for new committers. http://www.apache.org/foundation/how-it-works.html http://www.apache.org/dev/ -David
Re: [vote] Andreas Hartmann as new Cocoon committer
David Crossley wrote: I propose Andreas Hartmann as a new Cocoon committer and PMC member. During the time period there were no negative votes, and more than 3 positive votes. Since you are already an ASF committer via Lenya, we just need to add you to the svn authorization list for cocoon. One of us will do that soon. If you want to join the Apache Cocoon PMC, just say so and one of us will commence the procedure to add you. -David
[summary] [vote] Thorsten Scherler as new Cocoon committer
David Crossley wrote: I propose Thorsten Scherler as a new Cocoon committer and PMC member. During the time period there were no negative votes, and more than 3 positive votes. Since you are already an ASF committer via Lenya and Forrest, we just need to add you to the svn authorization list for cocoon. One of us will do that soon. If you want to join the Apache Cocoon PMC, just say so and one of us will commence the procedure to add you. -David
[summary] [vote] Andreas Hartmann as new Cocoon committer
Adding [summary] to the Subject line. -David David Crossley wrote: David Crossley wrote: I propose Andreas Hartmann as a new Cocoon committer and PMC member. During the time period there were no negative votes, and more than 3 positive votes. Since you are already an ASF committer via Lenya, we just need to add you to the svn authorization list for cocoon. One of us will do that soon. If you want to join the Apache Cocoon PMC, just say so and one of us will commence the procedure to add you. -David
Re: [proposal] Corona: A Cocoon subproject
Reinhard P?tz wrote: David Crossley wrote: This would generally be a good topic to raise on the ASF legal-discuss mail list. If it was framed in terms of establishing a well-defined procedure, then it would get better response. What does it mean to establish a procedure? Could you help me with that? A guideline or FAQ that can go at http://apache.org/legal/ Start with some words to define the issue and how to resolve it. Ensuing discussion should then finanlise it. The issue arises for new projects at the Incubator and for existing projects with their sub-projects. Probably need to research discussion on general @ incubator too. I am busy at the moment, but will try next week if you have not got to it. -David
[vote] Andreas Hartmann as new Cocoon committer
I propose Andreas Hartmann as a new Cocoon committer and PMC member. Andreas already has commit access to Cocoon by virtue of being a committer at Apache Lenya. This will formalise his status at Cocoon and enable him to be a PMC member. Andreas has been participating at the Cocoon dev and users mail lists since late 2001. He has recently been participating in dev discussions and providing comments to issues and some patches. http://cocoon.markmail.org/search/?q=hartmann Voting ends one week from today, i.e. midnight UTC on Monday 2008-08-04 So please cast your votes. -David
[vote] Thorsten Scherler as new Cocoon committer
I propose Thorsten Scherler as a new Cocoon committer and PMC member. Thorsten already has commit access to Cocoon by virtue of being a committer at Apache Lenya and Apache Forrest. This will formalise his status at Cocoon and enable him to be a PMC member. Thorsten has been participating at the Cocoon dev and users mail lists since late 2002. He has recently been making some docs edits and participating in dev discussions and making suggestions for improvements and providing some patches. http://cocoon.markmail.org/search/?q=scherler Voting ends one week from today, i.e. midnight UTC on Monday 2008-08-04 So please cast your votes. -David
Re: [vote] Andreas Hartmann as new Cocoon committer
David Crossley wrote: I propose Andreas Hartmann as a new Cocoon committer and PMC member. +1 from me. -David
Re: [vote] Thorsten Scherler as new Cocoon committer
David Crossley wrote: I propose Thorsten Scherler as a new Cocoon committer and PMC member. +1 from me. -David
Re: [vote] Luca Morandini as new Cocoon committer
Luca Morandini wrote: Vadim Gritsenko wrote: +1. I wonder how he managed to avoid becoming a committer for so long! ;-) Actually, I refused once... but this time David was more clever and didn't ask me first. :-) LOL It was not deliberate. I had completely forgotten. I checked my old mail archives. That was back in late 2002 before we had a private Cocoon mailing list, then i asked you in Feb 2003. It was bad timing and you asked us to wait a while. Then i suppose that we forgot. Sorry. Got you now. -David
Re: [proposal] Corona: A Cocoon subproject
Reinhard P?tz wrote: David Crossley wrote: Reinhard P?tz wrote: Finally this brings me to my last question: Do we want or do we have to change the name Corona? For the legal part of this question, who can I ask to get a final yes or no? The Apache Incubator docs should have some guidelines about this topic, since this issue often arises there. The Incubator general mail list would have lots of examples of people struggling with this issue, and hence guidance from ASF members. A quick search found these docs: http://incubator.apache.org/guides/releasemanagement.html#naming See any project's Status report http://incubator.apache.org/projects/ The first item on their Incubation work items is to be sure that the name is okay. e.g. http://incubator.apache.org/projects/sanselan.html The instruction says: Make sure that the requested project name does not already exist and check www.nameprotect.com to be sure that the name is not already trademarked for an existing software product. Does the ASF have an account? I don't know. This would generally be a good topic to raise on the ASF legal-discuss mail list. If it was framed in terms of establishing a well-defined procedure, then it would get better response. A quick search for corona software java shows some high profile software products. Ok, this means that we have to find a better name. First we should define the mission of this subproject. We will need a one-sentence description anyway. Then the appropriate name should fall out. Corona has two main goals: 1. Become the best platform for RESTful services and RESTful web applications based on the concept of pipelines. 2. Provide a generic pipeline Java API with SAX and STaX based default implementations. I lean towards Fibre or Silk. However because it might not be the pipeline API that Cocoon uses, then perhaps some other type of fibre. For example, Kapok - a fine fibrous cotton-like substance found surrounding the seeds of a tropical tree. (Australian Oxford English Dictionary). The term Java Kapok is used, but from my quick search not in the software industry. http://en.wikipedia.org/wiki/Ceiba_pentandra So my proposals are: Apache Cocoon Kapok Apache Cocoon Fibre I tend towards Apache (Cocoon) Silk because it is short and easily pronounceable (in contrast to Fibre) and doesn't sound like Klingon (Kapok). The USA spelling might be better: Fiber. I don't know if we should add Cocoon to the name and have no strong opinion. I thought that we needed to, as it is a sub-project of Apache Cocoon. One of us should clarify that on the legal-discuss list. -David
Re: Import my key into the KEYS file
Grzegorz Kossakowski wrote: David Crossley pisze: Jeroen Reijn wrote: Thanks Carsten! I'll give it a try. If found this message, but it was a but inclear, but after reading it 3 times.. I get it. I'll give it a go. Once I commit it into SVN will it also appear on the /dist/ or is SVN the only place it has to go in? That KEYS file is a separate one to that at the /dist/ directory. Most of the files there are in SVN at https://svn.apache.org/repos/asf/cocoon/site/mirrors/ but not the KEYS file. It should be, and be kept synchonised with the other one. David, could elaborate on this KEYS issue? Here is the output of svn st: [EMAIL PROTECTED] /www/www.apache.org/dist/cocoon]$ svn st ? bricks-cms ? 2.2 ? subprojects ? KEYS ? events/gt2004 It is clear that KEYS is not maintained by SVN. Should this be changed? Yes, as said above. Thanks for helping with such stuff. When faced with issues like this, i often look at how other projects have done it. Primarily i follow Apache HTTP Server, being the original project, and therefore most likely doing the proper stuff. So see: http://svn.apache.org/repos/asf/httpd/site/trunk/dist/ Also APR because lots of old ASF hands there. So see: http://svn.apache.org/repos/asf/apr/site/trunk/dist Apache Forrest will also give some clues, as when i set it up as a top-level project i reviewed many other existing practices. There are also notes about KEYS and such in the Guide for new committers and Release signing http://apache.org/dev/ Also Henk's guide says to put your own key at people.apache.org:~/.pgpkey As for now I'm going to just replace this file with newer version I'm going to commit right now. That is fine as a temporary measure, and will bring that static file up-to-date. -David
Re: [vote] Steven Dolg as committer
Reinhard P?tz wrote: it's a great honor for me to propose Steven Dolg as a committer. +1 from me. -David
[vote] Luca Morandini as new Cocoon committer
I would like to propose Luca Morandini as a new Cocoon committer and PMC member. Luca participates at the Cocoon dev and users mail lists since 2001, being more active again recently. http://cocoon.markmail.org/search/?q=morandini shows that there are many contributions to the lists and to code and docs. He also uses Cocoon as part of the Fins and Geoid projects. Voting ends one week from today, i.e. midnight UTC on Monday 2008-08-04 So please cast your votes. -David
Re: [vote] Luca Morandini as new Cocoon committer
David Crossley wrote: I would like to propose Luca Morandini as a new Cocoon committer and PMC member. +1 from me. -David
Re: [proposal] Corona: A Cocoon subproject
Reinhard P?tz wrote: Dear Cocoon PMC, as I said in a separate thread recently, it's time for Corona to move out of the whiteboard of Cocoon in order to increase its visibility and to allow releases. Corona has reached a state where it is already useful but there is a lot of room for others to enhance and improve it. So far Corona has been developed by Steven and me (+ some additions by Carsten recently) which doesn't qualify for being a diverse community. By my standards, all the people who have helped to discuss it are part of the community. In order to change this I want to propose Corona to become a subproject of Cocoon under the oversight of the Cocoon PMC. For that purpose I think that it would be a good idea to follow the procedure of the Incubator and nominate at least 2 additional PMC members who help us to grow the community and do all the legal checks when Corona is released (I'd love to see a alpha-1 release this summer.) Therefore I kindly want to ask two other Cocoon PMC members to become mentors for Corona and help to get it going. I don't see the need. Cocoon PMC are the mentors and have oversight. Anyone, including non-PMC, can speak up at any time. I also propose that Corona is being moved to https://svn.apache.org/repos/asf/cocoon/corona. The initial set of committers should consist of Carsten, Steven and me - every Cocoon committer can get write access by simply asking for it on this list. I would prefer that all Cocoon committers have default commit ability. Additionally I'd also like to see a separate Jira project for Corona. Are there any objections if ask infra in behalf of the Cocoon PMC to create one for us? That can happen independently, as soon as the name is decided. Would it be COCOON-SOMETHING ? Finally this brings me to my last question: Do we want or do we have to change the name Corona? For the legal part of this question, who can I ask to get a final yes or no? The Apache Incubator docs should have some guidelines about this topic, since this issue often arises there. The Incubator general mail list would have lots of examples of people struggling with this issue, and hence guidance from ASF members. A quick search found these docs: http://incubator.apache.org/guides/releasemanagement.html#naming See any project's Status report http://incubator.apache.org/projects/ The first item on their Incubation work items is to be sure that the name is okay. e.g. http://incubator.apache.org/projects/sanselan.html The instruction says: Make sure that the requested project name does not already exist and check www.nameprotect.com to be sure that the name is not already trademarked for an existing software product. A quick search for corona software java shows some high profile software products. First we should define the mission of this subproject. We will need a one-sentence description anyway. Then the appropriate name should fall out. I lean towards Fibre or Silk. However because it might not be the pipeline API that Cocoon uses, then perhaps some other type of fibre. For example, Kapok - a fine fibrous cotton-like substance found surrounding the seeds of a tropical tree. (Australian Oxford English Dictionary). The term Java Kapok is used, but from my quick search not in the software industry. http://en.wikipedia.org/wiki/Ceiba_pentandra So my proposals are: Apache Cocoon Kapok Apache Cocoon Fibre We should consider another possibility. If it does not have any hope of being the/a pipeline API for Cocoon, then perhaps it should go completely to Apache Incubator to become its own project. I would prefer that it stay here. -David
Re: Import my key into the KEYS file
Jeroen Reijn wrote: Thanks Carsten! I'll give it a try. If found this message, but it was a but inclear, but after reading it 3 times.. I get it. I'll give it a go. Once I commit it into SVN will it also appear on the /dist/ or is SVN the only place it has to go in? That KEYS file is a separate one to that at the /dist/ directory. Most of the files there are in SVN at https://svn.apache.org/repos/asf/cocoon/site/mirrors/ but not the KEYS file. It should be, and be kept synchonised with the other one. Probably need to then do: ssh people.apache.org cd /x1/www/www.apache.org/dist/cocoon svn up When verifying, consider the rsync delay: http://apache.org/dev/project-site.html -David Reinhard P?tz wrote: Jeroen Reijn wrote: Hi all, I uploaded the Cocoon 2.1.11 jars a couple of weeks ago into the m1 synch repository using the script from SVN. It turned out that when I ran the script it did not create .asc files. As a complete newbie to this kind of thing, I got a nice email from the repository team that told me I had to create these specific files. I read through the FAQ and release signing[1] documentation, but the thing that I'm stuck at is how to import my public pgp key to the cocoon KEYS file. Jeroen, https://svn.eu.apache.org/repos/asf/cocoon/trunk/commons/KEYS contains instructions how this can be done: Developers: pgp -kxa your name and append it to this file. (pgpk -ll your name pgpk -xa your name) this file. (gpg --list-sigs your name gpg --armor --export your name) this file. HTH
Re: Problem to integrate a website in cocoon
doog4064 wrote: I'm using the 2.1.11 version of cocoon Please discuss such issues on the users mail list, rather than this dev list. -David Kamal-6 wrote: What version of Cocoon are you using? hi evrybody, I'm a beginner in cocoon, I've been spending days finding out how does apache cocoon works, but all the docs i've found didn't help me to answer my questions. I just get a web site developped on cocoon, so i've installed the server but I can not find where i have to copy the directory or what i have to do, to make it work. I really have problems to figure out how this all thing work. So, if someone could explain to me what are the manipulations to do to run my website, please help me. Thank you so much. -- View this message in context: http://www.nabble.com/Problem-to-integrate-a-website-in-cocoon-tp18281481p18311503.html Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: [vote][result] Release Cocoon 2.2-final
Reinhard Poetz wrote: Reinhard Poetz wrote: The proposed modules have been accepted by 7 +1 votes and no negative one. I'm going move the artifacts into the Apache Maven M2 sync repository and also move the non-Maven artifacts to the Cocoon distribution area. Should we also put the Maven-built artifacts at the /dist/ as well? It would mean that people can get the Cocoon-2.2 jars from many alternative locations and closer mirrors. IIUC, Apache Jackrabbit does that, for example. I reckon that that would get us closer to ASF ideal release procedures too. When everything is available from the mirrors, I will send out the annoucement messages and update our website accordingly. (Probably not until next week ...) The artifacts are synched with the central Maven repository (http://repo1.maven.org/maven2). The announcement mail and the publishing of the non-Maven artifacts will follow next week. Thanks for all of your effort with the releases. -David
Re: Layered software designs
Reinhard Poetz wrote: A simple scenario could be: Pipeline API + java.net.URL + XML-SAX components A more advanced scenario could consist of Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine Is sourceresolve where the Apache XML Commons Resolver is hooked up? I would be concerned if our base offering enabled mis-use of net resources, e.g. processing an xml file which declares a DTD, causes an extra network trip if we don't have the xml entity resolver. -David
Re: Layered software designs
Reinhard Poetz wrote:
David Crossley wrote:
Reinhard Poetz wrote:
A simple scenario could be:
Pipeline API + java.net.URL + XML-SAX components
A more advanced scenario could consist of
Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine
Is sourceresolve where the Apache XML Commons Resolver
is hooked up?
no, I was talking about the Excalibur Sourceresolve component.
Yes, i know. However that might involve the Catalog Entity Resolver too.
This configuration used to be done in Cocoon, then we
moved it to Excalibur so that it would be more widely used.
I would be concerned if our base offering enabled
mis-use of net resources, e.g. processing an xml file
which declares a DTD, causes an extra network trip if
we don't have the xml entity resolver.
Resolving XML entities is important and we will definitly offer solutions
for it in the future too.
Corona, Steven's and my proposal of a Cocoon reimplementation, is about
doing things differently so that Cocoon becomes easily embeddable and
reuseable from within as many environments as possible. We think that a
layered design is the key to achive this goal. When you put all layers
together, the result (= a web application framework) should be nearly[1] as
powerful as that what we have today.
For that purpose Steven and I have also started to reimplement existing
concepts instead of doing everything from the scratch. First, we believe
that many of the existing concepts are good as they are and second, this
makes it easier for others to chime in because if you see Corona as a black
box, it should (more or less) provide the same results as 2.x.
HTH
Yes it does.
-David
[1] The only exceptions are things that we want to remove, e.g. sub
sitemaps etc. - see the Micro-Cocoon discussion:
http://marc.info/?l=xml-cocoon-devm=119903256406947w=2
--
Reinhard P?tzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Unable to check-out trunk
Carsten Ziegeler wrote: I'm trying to update my checkout. I got several svn: Unrecognized line ending style at various files. Retrying seems to solve the problem, however now I get the error at the root. Svn is not giving any other information than the text from above. Any ideas? We had a similar issue a couple of days ago. Mysterious. Re: [continuum] BUILD ERROR: Apache Cocoon [build root] I did 'svn up' just now and all okay - got reinhard's recent changes. I reviewed my commits today for some svn:eol-style issues and all seems okay. Can you give some filenames where it fails? We will see if they correspond to my commits. Trouble is that i am going away very soon for long weekend. -David
Re: Test release artifacts - Legal requirements check [take2]
Reinhard Poetz wrote: Vadim Gritsenko wrote: Do we really have to include each license into single LICENSE.txt file? I think I missed this development... There were so many discussions on several Apache lists that I can't point you to the thread :-/ Anyway, I was following the proposed structure as being suggested at http://wiki.apache.org/legal/3party/notice It has always been required, and it gets re-iterated in many license discussions. At both Cocoon and Forrest we have had trouble doing it, having so many supporting libraries. So we put the licenses beside each jar as text files with the same filename. At Forrest i have done a further compromise (until we move to Ivy which hope can help automate this license management). We put the license beside the jar as a text file, and mention the pathname in LICENSE.txt file. See more in a legal-discuss@ link, mentioned by me earlier in this thread. -David
Re: [continuum] BUILD ERROR: Apache Cocoon [build root]
On Tue, Mar 18, 2008 at 11:55:20PM +0100, Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: No, you probably were just lucky. I removed directory with offending file (rm -rf cocoon/blocks/cocoon-lucene/cocoon-lucene-sample/src/main/resources/COB-INF) and - since issue is already fixed in svn - update went fine. If only somebody could do the same on continuum box... FYI: I've forced Continuum to do a fresh checkout so this should hopefully fix Continuum. We'll see once my command is taken from queue. Thanks Vadim for a help! The continuum build is working again. That was very strange. Yes, i set the missing line-ending style in r554235 recently. Just as it should be for all text files. I did some investigation and other blocks have *.jx with the same 'svn:eol-style native' property. Those are okay, so why an error with this change. Vadim said the issue was with create-index2.jx file. I don't see a problem with it. However create-index.jx does have a miss-spelled property name. It has been that way for ages without a problem. I will fix it, and hope that Continuum does not choke. -David
Re: Test release artifacts - Legal requirements check
Reinhard Poetz wrote: David Crossley wrote: I see that the META-INF/NOTICE.txt etc. files in each of cocoon-components and impl directory, would correspond with those from the sources. However where does top-level NOTICE.txt file come from? Should it be generated as a combination of the other two? The files in the sub-directories could potentially be different. The problem is that the release artifacts are sometimes collections of several more focused artifacts, at least in the Maven 2 world they get distributed in smaller units. I guess that the correct solution is that each of those collection release artifacts has to contain a hand-crafted NOTICE.txt file. The license should because of the ASF policy always be the same. I gather from listening to legal-discuss@ list that the licenses of supporting products need to be appended to the main LICENSE file. This has been added to the draft legal pages. http://wiki.apache.org/legal/3party/notice This is another wrinkle that we have not yet fully addressed at Forrest. A comment from Roy made me realise why that is needed. The LICENSE and NOTICE files are intended to be shown to the user in an About... style pop-up box. http://markmail.org/message/evydcvctn6c6of27 -David
Re: Test release artifacts - Legal requirements check
Carsten Ziegeler wrote: Reinhard Poetz wrote: David Crossley wrote: I saw that some committers have been using lowercase filenames e.g. notice.txt, so the release-builder needs to handle that. Is there some requirement that the file names of notice.txt and license.txt have to be either lower or upper case? Or is it up to us? The uppercase might just be tradition, but also what people expect to see. See http://www.apache.org/dev/apply-license.html#license-file-name so we should name them NOTICE and LICENSE. We should use the same name throughout all modules. Ah thanks. Also from that page: Can the LICENSE and NOTICE files be called LICENSE.txt and NOTICE.txt? This is permitted. However the preference is that the files be called LICENSE and NOTICE. The .txt filename extension helps with svn clients. I am going to add explicit handling to the ASF committers configuration so we can use NOTICE and LICENSE. http://www.apache.org/dev/version-control.html#https-svn-config Would all committers please update their configuration. -David
Re: Micro-Cocoon ... Corona
Grzegorz Kossakowski wrote: Reinhard Poetz pisze: Grzegorz Kossakowski wrote: Agreed. What about officially announcing our effort at main site with simple manifesto? I have a feeling that we agree on fundamental goals so writing such a document shouldn't be a problem, right? I plan to write a blog entry about it so that the information gets spread to a wider audiance. For a public announcement it's too early, especially so close before we release 2.2. Thanks Reinhard and Sylvain for reminding me rules and best-practices to be applied in such situations. The main thing is that we can only promote to users, stuff that we have released. I agree that it's better to spread by using blogosphere and personal contacts. My main intention was to bring here old committers and people trying to do more or less the same[1]. Grek also was seeking to clarify the goals of such efforts. We could have a developers' area of the website, or use the Cocoon Wiki, or just a README in the source. Label it as intended for developers. -David
Re: Test release artifacts - Legal requirements check
Reinhard Poetz wrote: Reinhard Poetz wrote: This time I will create the Maven 2 release artifacts and normal zip/tar release artifacts for non-Maven users. I created release artifacts for the Servlet-Service framework using the old RC1 release form October last year and published them to http://people.apache.org/~reinhard/cocoon-staging/ssf/. Could others please have a look and check if those release artifacts meet all legal requirements? I see that the META-INF/NOTICE.txt etc. files in each of cocoon-components and impl directory, would correspond with those from the sources. However where does top-level NOTICE.txt file come from? Should it be generated as a combination of the other two? The files in the sub-directories could potentially be different. I expected a top-level cocoon-servlet-service directory to be created. Should it? -David
Re: Test release artifacts - Legal requirements check
I saw that some committers have been using lowercase filenames e.g. notice.txt, so the release-builder needs to handle that. -David
Re: Normal release artifacts
Vadim Gritsenko wrote: Reinhard Poetz wrote: Reinhard Poetz wrote: I have started to write some Ant scripts to produce non-Maven release artifacts. This will of course help everybody who doesn't want to use Maven or Ivy for dependency management but will also bundle all the information that belongs together (src, binaries, docs, javadocs, licensing information). Most of the work has been finished but now I got stuck with the question if we should ship third-party libs or not. E.g. for the Spring configurator this would be everything listed at http://cocoon.apache.org/subprojects/configuration/1.0/spring-configurator/1.0/dependencies.html . The advantages are that the user gets everything that she needs but the disadvantages are that we would have to add all license files of all 3rd-party libs (AFAIK there is no automatic mechanism for that) and the download size would increase. And I think that in 2008 you shouldn't manage your library dependency graph manually anymore in your projects (Maven, Ivy, the Maven Ant tasks are of great help and at least the last one is very easy to use.) Finally, if we decide to ship 3rd party libs, one technical question: Am I right that there is no automatic mechanism for Ant or Maven that pulls together all license information of all 3rd-party libs? That would be good. At Forrest, we have similar issues not yet solved. And, if we decide to not ship 3rd party libs, am I right that we don't have to add license files of them? (Otherwise all artifacts on the central Maven repository would be legally broken ...) Any comments? Perhaps legal-discuss@ list can help. Anyone? If I don't hear anything I will *not* include any third-party stuff (the only exception will be the getting-started stuff). Users will have to download all libraries themselves. IMHO what's good a downloadable release if 'cocoon.sh run' does not work? One of the points of such release is to make it one stop shop, to get everything up and running in one quick download. May be it's just me. Shrug. What does the getting-started stuff include? Perhaps we include the bare minimum and list exactly the other supporting products that they need to go further. Any supporting products that we do bundle, need their source too. -David
Re: Micro-Cocoon ... Corona
Reinhard Poetz wrote: Of course we are! We only have to work out the details of how we do it. The main question is, if we have to go through ASF IP clearance or not. Since it's rather a proposal than a finished project (~700 lines of code), I think it's enough if Steven sends in an CLA and attaches the code to a Jira issue. In the meantime (until Steven's CLA is recorded) we could prepare a snapshot package of Corona that we make privatly available to the Cocoon PMC. Is this a viable procedure? I consider that it is. It is your creative work, so it is just contributed under your Individual CLAs. You and Steven declare that you have the rights to contribute it. For your benefit, you might need the Corporate CLA if your ability to contribute is not clear with respect to your employment agreement. Probably okay in your case. -David
Re: Maintenance Release 2.1.12
Carsten Ziegeler wrote: I had the thought of doing 2 or 3 maintenance releases of 2.1.x (if there are changes) per year. Following this spirit I would like to cut a 2.1.12 sometime during April. +1 -David
Re: Releasing Cocoon 2.2, finally!
Reinhard Poetz wrote: It's time to release Cocoon 2.2, finally! We have been working on it for years and I think it's time to ship the *final* release. I want to do this in three phases: +1 to your release plan. 1) During the first phase I will release our two sub-projects Cocoon Configuration and Cocoon Servlet-Service-Framework. This time I will create the Maven 2 release artifacts and normal zip/tar release artifacts for non-Maven users. I think that I will be able to finish it by the end of next week. Sorry that i am late. Just back from holidays. I will do a license header check of those bits. -David
[jira] Closed: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer
[ https://issues.apache.org/jira/browse/COCOON-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Crossley closed COCOON-1928. -- Resolution: Won't Fix Please see FOR-1071 where we enabled such configuration using xml entities in the main forrest sitemap. Add the ability to pass the doctype in parameter for Serializer --- Key: COCOON-1928 URL: https://issues.apache.org/jira/browse/COCOON-1928 Project: Cocoon Issue Type: New Feature Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Cyriaque Dupoirieux Priority: Minor Attachments: AbstractTextSerializer.diff I need - with forrest - to get the doctype-system and doctype-public in a parameter like following : map:serializer logger=sitemap.serializer.xhtml mime-type=text/html name=xhtml pool-grow=2 pool-max=64 pool-min=2 src=org.apache.cocoon.serialization.XMLSerializer parameter name=doctype-public value=-//W3C//DTD XHTML 1.0 Transitional//EN / parameter name=doctype-system value=http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; / encodingUTF-8/encoding indentyes/indent omit-xml-declarationno/omit-xml-declaration /map:serializer here is a patch which apply to the AbstractTextSerializer. in case the doctype is also found in the childs, child have priority. Regards, -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r611525 - /cocoon/trunk/blocks/cocoon-imageop/cocoon-imageop-impl/src/changes/changes.xml
Grzegorz Kossakowski wrote: Joerg Heinicke pisze: joerg wrote: Modified: cocoon/trunk/blocks/cocoon-imageop/cocoon-imageop-impl/src/changes/changes.xml Could it be we switched from status.xml to changes.xml? :) Yes, I believe so. I haven't touch any status.xml since I'm committer and nobody complained to date. :) There are still 100 status.xml in trunk. Before I clean them up I want to know if that's correct. File changes.xml is supported by Maven reporting plug-in[1]. I don't know anything about a tool supporting status.xml in trunk so you can be almost sure we have switched. [1] http://maven.apache.org/plugins/maven-changes-plugin/ The status.xml files were used when Forrest generated the Cocoon docs for both 2.1 and trunk. They should still be used for all 2.1 changes. When trunk docs were moved to using Maven, some people kept adding to */status.xml as there was no replacement for generating changes. Now the 2.2 status.xml files need to be migrated. -David
Re: Where is the mirror.html?
Grzegorz Kossakowski wrote: Reinhard Poetz pisze: Grzegorz Kossakowski wrote: Reinhard Poetz pisze: Apparently, it does not work any more. Do you know who has set up this cron job? Sorry, no idea. I'll ask infra folks, then. Grek, i have a cronjob that does 'svn update' the Cocoon site every 12 hours: 08 5,17 * * * sh /x1/home/crossley/bin/cocoon-site-update.sh Remember also that there is an rsync delay described at: http://apache.org/dev/#web = http://apache.org/dev/project-site.html so 12.5 hours should be the maximum wait. I already responded today with the above to your ASF Infrastructure request. I was away for a long weekend. Whoever is now generating the Cocoon docs with Maven should take over this cronjob and i will stop mine. Make sure that it still does 'svn up' for our top-level, so that it catches any 2.1 changes too. The process description doc http://wiki.apache.org/cocoon/CocoonWebsiteUpdate should be updated with respect to the top-level docs (now not generated with Forrest) and for 2.2 docs. -David
Re: [ANN] Apache Cocoon 2.1.11 Released
Carsten Ziegeler wrote: Ralph Goers wrote: Thanks Carsten. I don't get the last paragraph though. Why would we provide more information about 2.1.10 when the announcement is for 2.1.11? The changes.html link has almost nothing under 2.1.11 so I assume the reference to 2.1.10 is correct? No, that's a typo - the announcement is hand prepared and I oversaw the version number at the bottom. For the changes.html I have no idea how to update them. If someone could have a look at it, would be great! I have run out of time and going away for long weekend. I managed to get the docs generation working again, but no time to deploy. http://wiki.apache.org/cocoon/CocoonReleaseHowTo = http://wiki.apache.org/cocoon/CocoonWebsiteUpdate -David
Re: [ANN] Apache Cocoon 2.1.11 Released
Carsten Ziegeler wrote: Apache Cocoon 2.1.11 Released - Thanks for that effort Carsten. However, i think that you might have missed the main announce AT apache.org list. -David
Re: Where is the mirror.html?
Carsten Ziegeler wrote: Hi, where has our mirror.html aka the download page gone? I want to add our latest release. Yeah i wondered that too. When testing the 2.1.11 release i went there to find the instructions about verify checksums and signatures. Because the mirror.html is missing, the CGI generates a default download page. http://cocoon.apache.org/mirror.cgi Yuk, that now doesn't even list our downloads. My guess is that the mirror.html template got clobbered when the Cocoon top-level site was moved to the new docs generation stuff. -David It would also be great to directly have a download link on our top page at cocoon.apache.org. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: broken 2.1 docs - something changed in Daisy?
I found the problem. The connection between Forrest and Daisy on the ASF Zones server is very slow. The Cocoon-2.1 docs job takes so long to complete, that it gets clobbered by another cron job. It seems to be a network issue that Forrest developers should report to ASF Infrastructure. First we should make double-sure that it is not a problem with our Forrest-Daisy plugin. You can see how slow it is by the doc generation times in the forrestbot report below. The job runs at 0:04 and 12:04 daily, so to see it running: ssh forrest.zones.apache.org tail -f $CONFIG/forrestbot-trunk/logs/cocoon-docs.log http://forrest.apache.org/zone.html -David David Crossley wrote: See http://forrest.zones.apache.org/ In the Cocoon 2.1 Docs follow the brokenlinks doc. Something about Daisy document ID 655, whatever that is. By the way, other Cocoon docs sections are old and we need to remove them from our Forrest zone. -David On Thu, Jan 03, 2008 at 01:05:52PM +, [EMAIL PROTECTED] wrote: Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 03 January 01:05 PM Using Forrest 0.9-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2008-01-03 12:22:32 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.9-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: fetch-plugins-descriptors: [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml [get] local file date : Tue Apr 10 05:50:24 GMT+00:00 2007 [get] . [get] last modified = Wed Apr 11 02:07:04 GMT+00:00 2007 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml [get] local file date : Sat Sep 01 21:45:45 GMT+00:00 2007 [get] Not modified - so not downloaded [echo] Plugin list loaded from http://forrest.apache.org/plugins/plugins.xml. [echo] Plugin list loaded from http://forrest.apache.org/plugins/whiteboard-plugins.xml. init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] -- Installing plugin: org.apache.forrest.plugin.output.pdf -- check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir. Trying to update it... init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: [echo] Trying to find the description of org.apache.forrest.plugin.output.pdf in the different descriptor files [echo] Using the descriptor file /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml... [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-local-unversioned-plugin: get-local: [echo] Trying to locally get org.apache.forrest.plugin.output.pdf [echo] Looking in local /export/opt/forrest-trunk/plugins [echo] Found ! init-build-compiler: echo-init: init: compile: jar: local-deploy: [echo] Locally deploying org.apache.forrest.plugin.output.pdf build: [echo] Plugin
Re: [Vote] Cocoon Release 2.1.11
David Crossley wrote: Would someone please look at why a recent change in Daisy seemed to break the automated building of 2.1 docs. I am away now for our weekend. http://article.gmane.org/gmane.text.xml.cocoon.devel/76511 Perhaps browse the docs@ list in the period prior to the first forrestbot report. I found the problem. The connection between Forrest and Daisy on the ASF Zones server is very slow. The Cocoon-2.1 docs job takes so long to complete, that it gets clobbered by another cron job. See the above link for more info. -David
Re: svn commit: r609282 [1/2] - in /cocoon/trunk: blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resources/COB-INF/modules/ blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resou
Ralph Goers wrote: I didn't know about the plugin, but yes I knew I should have put the issue number in the commit. I just forgot to do it. Do: svn propedit svn:log --revprop -r609282 https://svn.apache.org/repos/asf/cocoon/trunk -David Joerg Heinicke wrote: On 06.01.2008 04:35, [EMAIL PROTECTED] wrote: Author: rgoers Date: Sun Jan 6 01:35:48 2008 New Revision: 609282 URL: http://svn.apache.org/viewvc?rev=609282view=rev Log: Created XPathXMLFileModule to fix problems with XMLFileModule. Added getAttributeValue to JXPathHelper and changed all references to getAttribute to use it instead. Moved registration of VariableResolver to BridgeElementParser from SitemapElementParser to make it available to all Avalon components (i.e. input modules). Hi Ralph, I don't know if it just slipped through in this commit: If you add the issue number to the commit message, the SVN plugin for Jira can link the revision to the issue and adds nice links as it happened for your commit to 2.1 branch: https://issues.apache.org/jira/browse/COCOON-1574?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel Joerg
Re: broken 2.1 docs - something changed in Daisy?
Argh, forgot to Cc forrest dev. -David David Crossley wrote: I found the problem. The connection between Forrest and Daisy on the ASF Zones server is very slow. The Cocoon-2.1 docs job takes so long to complete, that it gets clobbered by another cron job. It seems to be a network issue that Forrest developers should report to ASF Infrastructure. First we should make double-sure that it is not a problem with our Forrest-Daisy plugin. You can see how slow it is by the doc generation times in the forrestbot report below. The job runs at 0:04 and 12:04 daily, so to see it running: ssh forrest.zones.apache.org tail -f $CONFIG/forrestbot-trunk/logs/cocoon-docs.log http://forrest.apache.org/zone.html -David David Crossley wrote: See http://forrest.zones.apache.org/ In the Cocoon 2.1 Docs follow the brokenlinks doc. Something about Daisy document ID 655, whatever that is. By the way, other Cocoon docs sections are old and we need to remove them from our Forrest zone. -David On Thu, Jan 03, 2008 at 01:05:52PM +, [EMAIL PROTECTED] wrote: Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 03 January 01:05 PM Using Forrest 0.9-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2008-01-03 12:22:32 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.9-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: fetch-plugins-descriptors: [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml [get] local file date : Tue Apr 10 05:50:24 GMT+00:00 2007 [get] . [get] last modified = Wed Apr 11 02:07:04 GMT+00:00 2007 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml [get] local file date : Sat Sep 01 21:45:45 GMT+00:00 2007 [get] Not modified - so not downloaded [echo] Plugin list loaded from http://forrest.apache.org/plugins/plugins.xml. [echo] Plugin list loaded from http://forrest.apache.org/plugins/whiteboard-plugins.xml. init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] -- Installing plugin: org.apache.forrest.plugin.output.pdf -- check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir. Trying to update it... init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: [echo] Trying to find the description of org.apache.forrest.plugin.output.pdf in the different descriptor files [echo] Using the descriptor file /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml... [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-local-unversioned-plugin: get-local: [echo] Trying to locally get org.apache.forrest.plugin.output.pdf [echo] Looking in local /export/opt/forrest-trunk/plugins [echo
Re: [Vote] Cocoon Release 2.1.11
Would someone please look at why a recent change in Daisy seemed to break the automated building of 2.1 docs. I am away now for our weekend. http://article.gmane.org/gmane.text.xml.cocoon.devel/76511 Perhaps browse the docs@ list in the period prior to the first forrestbot report. -David
broken 2.1 docs - something changed in Daisy?
See http://forrest.zones.apache.org/ In the Cocoon 2.1 Docs follow the brokenlinks doc. Something about Daisy document ID 655, whatever that is. By the way, other Cocoon docs sections are old and we need to remove them from our Forrest zone. -David On Thu, Jan 03, 2008 at 01:05:52PM +, [EMAIL PROTECTED] wrote: Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 03 January 01:05 PM Using Forrest 0.9-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2008-01-03 12:22:32 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.9-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: fetch-plugins-descriptors: [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml [get] local file date : Tue Apr 10 05:50:24 GMT+00:00 2007 [get] . [get] last modified = Wed Apr 11 02:07:04 GMT+00:00 2007 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml [get] local file date : Sat Sep 01 21:45:45 GMT+00:00 2007 [get] Not modified - so not downloaded [echo] Plugin list loaded from http://forrest.apache.org/plugins/plugins.xml. [echo] Plugin list loaded from http://forrest.apache.org/plugins/whiteboard-plugins.xml. init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] -- Installing plugin: org.apache.forrest.plugin.output.pdf -- check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir. Trying to update it... init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: [echo] Trying to find the description of org.apache.forrest.plugin.output.pdf in the different descriptor files [echo] Using the descriptor file /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml... [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-local-unversioned-plugin: get-local: [echo] Trying to locally get org.apache.forrest.plugin.output.pdf [echo] Looking in local /export/opt/forrest-trunk/plugins [echo] Found ! init-build-compiler: echo-init: init: compile: jar: local-deploy: [echo] Locally deploying org.apache.forrest.plugin.output.pdf build: [echo] Plugin org.apache.forrest.plugin.output.pdf deployed ! Ready to configure fetch-remote-unversioned-plugin-version-forrest: fetch-remote-unversioned-plugin-unversion-forrest: has-been-downloaded: downloaded-message: uptodate-message: not-found-message: [echo] Fetch-plugin Ok, installing ! unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 file to
Re: [Vote] Cocoon Release 2.1.11
Carsten Ziegeler wrote: Hi, i've put up the 2.1.11 release at: http://people.apache.org/~cziegeler/releases/cocoon/ please check, verify and cast your votes. I used the tar.gz and verified the md5sum and pgp signature, and investigated some other things. md5: f103d7c90fcd1e0f027f88f7fd0a44a0 +1 from me. p.s. We have the wrong name for the Apache License in the README.txt and some of the stuff that is in CREDITS.txt should instead be in NOTICE.txt, but i reckon that can pass this time. -David
Thanks Ralph [Was: 2.1.11 release]
Ralph Goers wrote: I committed the changes to 2.1.x. I'll try to get trunk done on 1/1/08 Thanks for that extra effort Ralph, in the midst of your preparations. Your ASF friends wish you well. -David
Re: How to update docs for 2.1?
Grzegorz Kossakowski wrote: David Crossley pisze: No it is not. That is how the cocoon website is still managed. The ASF Infrastructure asks that all websites be stored in SVN. I would say that's crucial sentence that helps to understand whole setup. Now the rest makes sense. Good idea. We need to make that more clear at CocoonWebsiteUpdate wiki. It is already emphatic at http://apache.org/dev/#web http://apache.org/dev/project-site.html#edit -David Yes, that is correct. Edit the source for 2.1 docs via Daisy. Behind-the-scenes on forrest.zones.a.o, Forrest (calling the forrestbot from cron) is generating the final docs by extracting the content from Daisy and applying the website theme. However a human committer needs to commit the changes from time-to-time. I think that the wiki page describes all this. If you can point to any confusing areas, then i will try to fix it. It's all clear now, it was confusing why one have to commit anything if we store docs in Daisy and Forestbot generates pages automatically. I tweaked the paragraphs below the one that you refer to, to emphasise that committers should let forrestbot do the work and use the quick fix method of committing the final docs to cocoon/site/site/2.1/ SVN. Thanks! -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: How to update docs for 2.1?
hepabolu wrote: Grzegorz Kossakowski said the following on 4/7/07 10:12: Thanks David and Joerg. I'm really confused, wiki page is talking most of the time about checking out /site from svn and updating docs there. Right. This is ancient. Please remove that text from the wiki page. No it is not. That is how the cocoon website is still managed. The ASF Infrastructure asks that all websites be stored in SVN. For ours, ssh people.apache.org svn info /www/cocoon.apache.org/ which shows that it is our cocoon/site SVN, as described by that wiki page. However, there is a statement: Since 2.1.8, the documentation (apart from the top-level website pages described above) is written using Daisy at [WWW] http://cocoon.zones.apache.org/, and Daisy-generated pages are processed by Forrest (using forrest trunk) to generate the static pages (still in experimental phase). Does this means we really use Daisy and docs from legacydocs to generate 2.1 documentation or not? What should I edit? Yes, that is correct. Edit the source for 2.1 docs via Daisy. Behind-the-scenes on forrest.zones.a.o, Forrest (calling the forrestbot from cron) is generating the final docs by extracting the content from Daisy and applying the website theme. However a human committer needs to commit the changes from time-to-time. I think that the wiki page describes all this. If you can point to any confusing areas, then i will try to fix it. I tweaked the paragraphs below the one that you refer to, to emphasise that committers should let forrestbot do the work and use the quick fix method of committing the final docs to cocoon/site/site/2.1/ SVN. -David
Re: Discussion about Maven
Grzegorz Kossakowski wrote: Vadim Gritsenko pisze: Grzegorz Kossakowski wrote: I wanted to know what are our rules. Do we: - want to have such a internal releases I'd avoid using word release for this as it has some legal implications and we would get chewed up for using it :) Ah, I'm young committer so forgive me that I omit legal implications and use inappropriate words. I'm really hard working to improve my English. :-) I agree it should not be called release. Many people use the term incorrectly. See http://apache.org/dev/#releases http://apache.org/dev/release.html#what Yes I think you can do such builds and place them on your private space at people.apache.org or on cocoon zones, and call it nightly or build or some such, but not a milestone *release*. And it is a good idea to do such builds as long as it helps to further development of Cocoon. +1 IMHO, for milestone *release*, I'd bundle all necessary unreleased dependencies and upload to www.apache.org/dist. I'm not sure if there are any legal gotchas with this approach, but it worked for us in the past, for 2.1 milestones. The only stuff that can go at w.a.o/dist/ is that which is intended to be released to the public beyond our dev group. Anything put there must be approved by this PMC. It will not work with Maven and it can't be called release I think. My personal opinion is that release (after changing wording) should be something that we can officially ship using our infrastructure. Part of our infrastructure is Maven now but in order to upload to its central server we can't have snapshot dependencies as pointed out earlier. The only solution I can think of is that we stay longer in nighly build mode and we can switch to milestone mode as soon as all of our dependencies are released ones. I think that it will work well only if we successfully push projects we depend on to follow release early, release often practice so we will not bed forced to stay in nighly build phase too long. I'm not so much experienced with Open Source to have a strong opinion on this. Do you think that we effectively push other project? The only effective way is to go and help those other projects: testing, feedback, etc. -David
Re: How to update docs for 2.1?
Joerg Heinicke wrote: Grzegorz Kossakowski wrote: I have some pending fixes for C2.1 documentation in my local checkout of site. Do you know how to publish this changes? You can use the quick-fix method by unpacking and committing last night's generated docs. http://wiki.apache.org/cocoon/CocoonWebsiteUpdate -David Isn't 2.1 documentation also generated from Daisy? That means you have to integrate your changes there. I'd guess here: http://cocoon.zones.apache.org/daisy/legacydocs/654.html. Joerg
Re: [vote] Jeroen Reijn as a new Cocoon committer
Andrew Savory wrote: Please cast your votes. +1 -David
Re: [vote] Felix Knecht as a new Cocoon committer
Reinhard Poetz wrote: Please cast your votes! +1 -David
Re: Sending CLA
Grzegorz Kossakowski wrote: Ok, I was not patient enough and found fax machine. It wonders me how long I'll have to wait now... The receipt of your CLA was recorded by the ASF secretary today. -David
Re: [vote] Grzegorz Kossakowski as a new Cocoon committer
Daniel Fagerstrom wrote: Please cast your votes. +1 -David
Re: viewing intermediate XML with profiler (was Re: Running Cocoon in debugger)
Lars, would you please send that last message again as plain-text. It was html-formatted. -David
Re: Docs for 2.1.10
The content is in Daisy, and the Forrestbot on our zone retrieves it from there and generates the docs. This process is then followed to get them on to c.a.o/2.1 http://wiki.apache.org/cocoon/CocoonWebsiteUpdate Take the quick route of unpacking the tar.gz and commit to the cocoon/site SVN. The top-level docs for c.a.o are also explained there. Sorry i cannot help more, going away. -David
Re: [Vote] Release 2.1.10
Carsten Ziegeler wrote: So here are the md5's: MD5 (cocoon-2.1.10rc-src.tar.gz) = d073b36274ab359b59bbb760e083a934 -0 ... meaning that i don't want to stop the release, however i am concerned that we are not following the new licensing which all releases after early November are asked to follow. A while ago i said that although i had done all the work to replace the license headers in the source files, there is still the task of adding whatever third-party attributions into the NOTICE.txt and declaring the licenses in LICENSE.txt -David
Re: Code freeze for trunk?
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Is the code freeze for trunk over now? I'd like to commit some
refactoring of the pipelines.
I'd say yes. Carsten and you confirmed that the artifacts are working. If
David doesn't withdraw his -1, it will take some time to fix things.
I think that that is incorrect. Cocoon doesn't have guidelines yet,
but the general Apache guidelines say that a release is majority
consensus.
-David
This
shouldn't stop actual work. So go ahead!
--
Reinhard P?tz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [vote] Releasing from trunk (cocoon-core-2.2.0-M2 and others)
The md5sum does not match for cocoon-core-2.2.0-M2-sources.jar I haven't tested the rest. -David
Re: [vote] Releasing from trunk (cocoon-core-2.2.0-M2 and others)
Reinhard Poetz wrote: David Crossley wrote: The md5sum does not match for cocoon-core-2.2.0-M2-sources.jar I haven't tested the rest. linux:~/$ wget http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-core/2.2.0-M2/cocoon-core-2.2.0-M2-sources.jar linux:~/$ md5sum --binary cocoon-core-2.2.0-M2-sources.jar 6b81eacaa0003a9c5f7ca725b193c5a6 *cocoon-core-2.2.0-M2-sources.jar linux:~/$ wget http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-core/2.2.0-M2/cocoon-core-2.2.0-M2-sources.jar.md5 linux:~/$ cat cocoon-core-2.2.0-M2-sources.jar.md5 6b81eacaa0003a9c5f7ca725b193c5a6 Are you sure that you compared the same files? Hmmm, i am having a bad day. I even tried separate download three times and still couldn't get a match. Anyway, all is well now. Sorry for the noise. -David
Re: [vote] Releasing from trunk (cocoon-core-2.2.0-M2 and others)
Reinhard Poetz wrote: David Crossley wrote: Reinhard Poetz wrote: Please cast your votes, whether we want to publish these artifacts to the official Maven repository and make the release official. The vote is open for 72 hours. -1 I tried to raise these issues when Reinhard proposed the release plan. The procedure is not being followed. We need to vote on sources, not binaries. We also need to publish those sources as the release. for e.g. cocoon-core you find sources, binaries and javadocs in http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-core/2.2.0-M2/ Hmmm, sorry, i see them now. Not sure what i was looking at then. I am happy about the sources aspect now, so +1 from me. We also need to know which SVN revision corresponds to the release. These can be found in http://svn.apache.org/repos/asf/cocoon/tags/ See the last paragraph of http://www.apache.org/dev/release.html#what After reading it again, I'm not sure of what a release really is. From my understanding everything is a release, whether it is something you call, alpha, beta, GA or whatever. I am not just being a stickler for procedure, rather that the PMC has responsibilities. What are you missing exactly? The non-missing sources. :-) Perhaps follow the release procedure that Carsten already has been using, of course with the additional maven bits. Again, what are you missing? Except the JIRA updates I think everything is done to vote on the artifacts, isn't it? Why is there an -M2 in the artefact names? If it is a release and not a milestone then it should be named 2.2.0. For me both things are releases http://www.apache.org/dev/release.html#what Releases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list. If the general public is being instructed to download a package, then that package has been released. Each PMC must obey the ASF requirements on approving any release. How you label the package is a secondary issue, described below. [...] but if I'm wrong with my interpreation I have not problem in saying that the milestones are no releases in the sense of the above text. I thought that the milestone naming was something leading up to a release, and intended for developers. So at what point do we drop the -M* appendage? -David
Re: [vote] Releasing from trunk (cocoon-core-2.2.0-M2 and others)
Reinhard Poetz wrote: Please cast your votes, whether we want to publish these artifacts to the official Maven repository and make the release official. The vote is open for 72 hours. -1 I tried to raise these issues when Reinhard proposed the release plan. The procedure is not being followed. We need to vote on sources, not binaries. We also need to publish those sources as the release. We also need to know which SVN revision corresponds to the release. See the last paragraph of http://www.apache.org/dev/release.html#what I am not just being a stickler for procedure, rather that the PMC has responsibilities. Perhaps follow the release procedure that Carsten already has been using, of course with the additional maven bits. Why is there an -M2 in the artefact names? If it is a release and not a milestone then it should be named 2.2.0. -David
Re: Releases from trunk
Reinhard Poetz wrote: I think it's time to release the next milestone of some of our modules: - org.apache.cocoon:cocoon(pom) - org.apache.cocoon:cocoon-core-modules (pom) - org.apache.cocoon:cocoon-core (jar) - org.apache.cocoon:cocoon-blocks-modules (pom) - org.apache.cocoon:cocoon-template (pom) - org.apache.cocoon:cocoon-flowscript (pom) - org.apache.cocoon:cocoon-template-impl (jar) - org.apache.cocoon:cocoon-flowscript-impl(jar) - org.apache.cocoon:cocoon-blocks-fw (pom) - org.apache.cocoon:cocoon-blocks-fw-impl (jar) - org.apache.cocoon:cocoon-tools-modules (pom) - org.apache.cocoon:cocoon-archetypes (pom) - org.apache.cocoon:cocoon-22-archetype-block (archetype jar) That's the minimal set of artifacts to do something useful with Cocoon and to follow the getting started guide. I know that we should release some more blocks (forms, fop, apples, etc.) and the archetype-webapp artifact, but they need some more polishing. I propose that we change the release procedure this time: The person who performs the release, releases the artifacts into our staging repository. Then he calls for a vote, open for 72 hours. If the vote passes, the artifacts are moved to the official Apache sync directory on people.apache.org. The last step is asking on repository@apache.org to sync with the Maven central repo. Is the list of artifacts and the outlined release procedure okay for everybody? If yes, I can do the relase on Thuesday, starting in the afternoon (MET). I am not clear about what is being suggested for this plan. If it is a milestone then it should not end up on the public central repository. If it is a release then it should be accompanied by the sources, etc. Also it should be on the w.a.o/dist mirrors as well as whatever Maven does. http://www.apache.org/dev/release.html#releases http://www.apache.org/dev/#releases -David
Re: Releasing 2.1.10
Carsten Ziegeler wrote: It's time to release again - thanks to Bruno we have solved the rhino licensing problem now and imho nothing is preventing us from a release. If there are no outstanding issues I will assemble a release next monday (11th), put it up for downloading and testing and if nothing bad happens do the release of that assembled version on monday, 18th. WDYAT? +1 for that release plan. -David
Re: [graphics] Masthead artwork for cocoon.apache.org
hepabolu wrote: All: I know it is quite early for this, but in order to review the galleries of samples that Thien will be delivering ;-) we need a space to put them. I don't mind to help out in getting them uploaded, but it would be nice if it's not a public place such as the wiki or Daisy on the zone, to avoid endless discussions (which we will probably have anyway) with a huge group of people. Each committer has an un-official space: http://www.apache.org/dev/new-committers-guide.html#public_html By the way, here are some resources that might help with the contruction of new banners and logos: http://wiki.apache.org/cocoon/PoweredByCocoon http://svn.apache.org/repos/asf/cocoon/trunk/commons/misc http://svn.apache.org/repos/asf/forrest/trunk/tools/logos ... there are apache feather SVG in there. The real name is Apache Cocoon. -David
Re: Submitting patches in JIRA
Mark Lundquist wrote: David Crossley wrote: Use the Edit this issue link on the left-hand panel when you are viewing an issue. It's not there for me. I have Attach File, Attach Screenshot, Clone, Comment, Create sub-task, Voting, and Watching. Ah, i see what is happening. Only people in the Jira group cocoon-developers (i.e. committers) can Edit issues. Some other projects also enable jira-users to Edit, i.e. change Summary, Description, Components, Fix Version, etc. So, Cocoon PMC, should we loosen the permissions for Edit? Lazy consensus: if we don't hear a no then i will do it next week. By the way, all cocoon-developers can do Administer Project, so no need to wait for me for this sort of stuff. -David
Re: Submitting patches in JIRA
Mark Lundquist wrote: Back in the day, with Bugzilla, I remember we had the convention that the issue title started with '[PATCH]'. If there was no patch available when the issue was created, you just edited the issue title and inserted '[PATCH]'. I see that with JIRA, there is this little a patch is available with this issue checkbox on the issue creation page. Funny, I never noticed that before... :-). Ah, now it all clicks... I guess that's where that open-with-patch report comes from :-) And I guess the old convention of starting with '[PATCH]' is superfluous now, right? That's good, because there doesn't seem to be any way to edit the title... maybe I don't have the right karma/mojo/whatever. All I have to do is check the little box... but wait! There's no little box anymore once the issue's been created. And there's no this is a patch checkbox on the Attach File form... SooOOOooo... if I create an issue w/ no patch, then decide to submit a patch later, how do I indicate it? Create a new issue referencing the first? Or just attach the file and don't worry about it? :-) Use the Edit this issue link on the left-hand panel when you are viewing an issue. -David
Re: Rhino (once more)
Ralph Goers wrote: This may not be too big a deal for Cocoon trunk. So long as flowscript is an optional part of Cocoon I believe we are OK. However, it probably also means that while other blocks can take advantage of flowscript they shouldn't rely on it. I presume that this will put the problem onto the Flowscript Block which could not be officially released if Rhino is a mandatory part of that block. -David
Re: [SITE] - Contributions to this relase....
Antonio Gallardo wrote: In http://cocoon.apache.org/2.1/changes.html we read for each release: snip Contributors to this release We thank the following people for their contributions to this release. This is a list of all people who participated as committers: [Committer's list] This is a list of other contributors: [contributor's list] /snip I wonder if we can improve the sentence: This is a list of other contributors: In particular I don't like the other contributor concept. Perhaps it is because I am no a native english speaker. Perhpas we should review the whole section. WDYT? This is generated by the Forrest plugin projectInfo from the data in cocoon/site/status.xml It says other contributors because committers are contributors but these other people are contributors but are not committers. I had tried my best to get that English correct. If people think that they can do better then please send a patch to the Forrest sources. It is very important to acknowledge everyone who is involved, otherwise a community cannot be built. -David
Re: Release roadmap
Has someone attended to the remaining licensing issues? I managed to update all the headers in source files and will do so again just before the releases. However, that is all that i can do. The remaining tasks were noted in some past emails. Going by memory they were: NOTICE.txt and LICENSE.txt files; Check the licenses for third-party products; Somehow refer to such products from LICENSE.txt -David
Re: Forrest zone auto startup
Bertrand Delacretaz wrote: David Crossley wrote: ...Forrest doesn't have automatic httpd restart and the zones machine goes down a lot... Note that, altough Solaris apparently has something new and improved, the old rc*.d stuff does work. On the cocoon zone we have created the usual apache2 start script links: /etc/rc0.d/K16apache2 /etc/rc1.d/K16apache2 /etc/rc2.d/K16apache2 /etc/rc3.d/S50apache2 /etc/rcS.d/K16apache2 And they work fine. Also, if you need to startup non-root stuff automatically, I have created a script for that on our zone, see http://issues.apache.org/jira/browse/COCOON-1923. This is also started in /etc/rc3.d and calls $HOME/rc/start and $HOME/rc/stop for each user where these files exist. We use it to start Daisy, the Cocoon demos and Continuum on our zone, all running under their respective usernames. Thanks for your help mate. One of us that has access to both zones will get around to it. http://issues.apache.org/jira/browse/FOR-940 -David
Re: [RANT] The Cocoon website: move on, nothing is happening here
Niclas Hedhman wrote: Steven Noels wrote: What those Belgian guys ? however (in)frequently murmured amongst themselves was: why the ? stupid fixation with SVN as a required content repository for ? official ASF documentation sites? Why can't cocoon.apache.org simply ? be a proxy for http://cocoon.zones.apache.org/daisy/documentation/ ? I think it is related to the principles of primary resources; - mailing lists - subversion - ? which infrastructure works hard to make sure are operational, backed-up, fail-over, disaster planning et al. Wiki and other stuff is not considered primary, and doesn't enjoy the attention of the infrastructure folks. Yep. Also the cocoon.zones.apache.org is only an experimental playground. It is risky to rely on it. There is a lot of mis-information about the use of SVN and websites. The docs source content is an asset and needs to be stored. The generated docs currently need to be in SVN so that websites can be easily restored by the infrastructure people. The infrastructure site-dev mailing list tried to find other solutions to enable any content repository, generate final docs to staging area, rsync to production. That has stalled. If someone has the energy, it would be great to help move that again. Any committer can subscribe. http://www.apache.org/dev/infra-mail.html ---oOo--- Anyway, here is a proposed solution for Cocoon ... - A) Store docs content in Daisy. The /2.1/ content is already there and /2.2/ is being developed. Move the content for the top-level website from xdocs into Daisy (see http://wiki.apache.org/cocoon/CocoonWebsiteUpdate). Move select docs from the current wiki.a.o/cocoon into Daisy. Remove current wiki and use Daisy instead. - B) Generate final docs into a staging area on cocoon.zones.a.o Don't care how this happens. Some straight Daisy docs, some from Maven, some generated by Forrest (would need to rsync from forrest.zones.apache.org). Using CSS we should be able to make it consistent. - C) Give each committer a local publish shell script. This updates their working copy of the cocoon/site/ SVN, then rsyncs generated docs from cocoon.zones.a.o/stage/ and does 'svn commit'. - D) A cronjob on people.apache.org does 'svn update' to put the site into production. Already happening. - E) Improve the backup of docs source. http://issues.apache.org/jira/browse/COCOON-1925 - F) Work with infrastructure site-dev@ find better solutions. -
Re: [RANT] The Cocoon website: move on, nothing is happening here
Bertrand Delacretaz wrote: ... (http://forrest.zones.apache.org/ seems to be down right now, cannot check it size but I assume it's quite big). Grrr, Forrest doesn't have automatic httpd restart and the zones machine goes down a lot. So it is manual restart. I just did it and updated the notes so other committers can do it. http://forrest.apache.org/zone.html#admin -David
Re: Cocoon on projects.apache.org
Bertrand Delacretaz wrote: Sylvain Wallez wrote: ...So, should we restrict ourselves to a single category (rather limiting for Cocoon), or fix project.a.o to allow multiple categories?.. Fixing projects.a.o would be better, IIRC this is David Reid's work? I haven't found a contact address there. It does allow multiple categories. See http://projects.apache.org/projects/cocoon.html At one time these multiple categories were functioning properly and all were listed at http://projects.apache.org/indexes/category.html etc. Something has changed recently with his site generation and broken it. The site-dev AT a.o list is where it happens. http://www.apache.org/dev/infra-mail.html -David
[jira] Commented: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer
[ http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441895 ] David Crossley commented on COCOON-1928: Sitemap precedence would probably be better, if possible. Another technique that i wonder about: Let the project or plugin declare a separate map:serializer with different name attribute. Then make the name be configurable for deciding which serializer to use later in the map:pipelines. I gather that the Cocoon properties system will enable such configuration (FOR-917). The entities technique should work (being an xml framework). The biggest trouble that i have found is getting the entity resolver to work in all three situations: local jetty, command-line CLI, and webapp war. Forrest entity resolver is able to be used at core, plugin, and project levels. Here is one technique that might help you: http://forrest.apache.org/docs/dev/faq.html#xml-entities Probably should create a FOR Jira issue and leave this one for your original suggestion. Add the ability to pass the doctype in parameter for Serializer --- Key: COCOON-1928 URL: http://issues.apache.org/jira/browse/COCOON-1928 Project: Cocoon Issue Type: New Feature Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Cyriaque Dupoirieux Priority: Minor Attachments: AbstractTextSerializer.diff I need - with forrest - to get the doctype-system and doctype-public in a parameter like following : map:serializer logger=sitemap.serializer.xhtml mime-type=text/html name=xhtml pool-grow=2 pool-max=64 pool-min=2 src=org.apache.cocoon.serialization.XMLSerializer parameter name=doctype-public value=-//W3C//DTD XHTML 1.0 Transitional//EN / parameter name=doctype-system value=http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; / encodingUTF-8/encoding indentyes/indent omit-xml-declarationno/omit-xml-declaration /map:serializer here is a patch which apply to the AbstractTextSerializer. in case the doctype is also found in the childs, child have priority. Regards, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Closing JIRA issues
Jean-Baptiste Quenot wrote: * Antonio Gallardo: Jean-Baptiste Quenot closed COCOON-1774. Resolution: Won't Fix Please reopen the issue if the problem persists with the new Dojo stuff. Thanks! I don't think it is the best way to close bugs. IMHO, the first part of a problem resolution is the problem identification and an open issue without a patch provides this first part. I would left open this bug (and onther of the current closed) until somebody comes with a solution. I don't know if you talked about this in GT2006, but if jira now becomes only a patch repository, I will like to know. At least we should vote for this policy change. Please don't take it personally. ;-) Hello Antonio, Sorry for the late reply, I missed your comment. Here is an explanation, I'm closing issues when: I disagree with most of this. Why are you wanting to close such issues? Why don't we use Jira to classify them, and then use Jira filters to see what needs to be attended to? At Forrest for example, we try to regularly go through the open issues and schedule them to be attended to (Fix Version) for either the current release or the next release. Anything else is left in an unscheduled state. Then a Jira Filter shows us the roadmap. BTW I discussed this with Vadim at the Hackathon. * it has been sitting in JIRA for a very long time So what? That just shows that people are too busy or don't bother to look at Jira. * it is in Feedback Required state and reporter did not reply for a long time Okay, should be closed. * no patch was provided It is still an issue that needs attention. * none of the Cocoon developers contributed to fix this issue So what? That just shows that people are too busy or don't bother to look at Jira. or one of the developers says issue is already fixed Okay, should be closed. I think there is no good reason to keep the issue open forever if no one intends to work on it, especially as the JIRA is full of these. Closing issues prematurely is disrespectful. -David
[jira] Commented: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer
[ http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441620 ] David Crossley commented on COCOON-1928: Cyriaque, have you tried declaring the serializer in your project's sitemap.xmap file? I am not sure which one takes precedence. Add the ability to pass the doctype in parameter for Serializer --- Key: COCOON-1928 URL: http://issues.apache.org/jira/browse/COCOON-1928 Project: Cocoon Issue Type: New Feature Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Cyriaque Dupoirieux Priority: Minor Attachments: AbstractTextSerializer.diff I need - with forrest - to get the doctype-system and doctype-public in a parameter like following : map:serializer logger=sitemap.serializer.xhtml mime-type=text/html name=xhtml pool-grow=2 pool-max=64 pool-min=2 src=org.apache.cocoon.serialization.XMLSerializer parameter name=doctype-public value=-//W3C//DTD XHTML 1.0 Transitional//EN / parameter name=doctype-system value=http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; / encodingUTF-8/encoding indentyes/indent omit-xml-declarationno/omit-xml-declaration /map:serializer here is a patch which apply to the AbstractTextSerializer. in case the doctype is also found in the childs, child have priority. Regards, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Lars Trieloff as a new Cocoon committer
+1 -David
