Re: Website export
Apologies, I now realise that my mail client auto completed the wrong address - no wonder I was getting no response. Ross 2009/11/23 Ross Gardler : > http://community.apache.org is not showing the updates to the wiki, it > still shows the original CWiki index page. Anyone know how the export > thingy works? > > Ross > > -- > Ross Gardler > > OSS Watch - supporting open source in education and research > http://www.oss-watch.ac.uk > -- Ross Gardler OSS Watch - supporting open source in education and research http://www.oss-watch.ac.uk
Website export
http://community.apache.org is not showing the updates to the wiki, it still shows the original CWiki index page. Anyone know how the export thingy works? Ross -- Ross Gardler OSS Watch - supporting open source in education and research http://www.oss-watch.ac.uk
Daisy is down
Can someone please kick the Daisy server on the Zone. Ross
Re: ForrestBot build for cocoon-docs FAILED
Joerg Heinicke wrote: On 18.10.2008 14:25, [EMAIL PROTECTED] wrote: [java] X [0] 2.1/prepare-mojo.htmlBROKEN: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy (Is a directory) [java] ^ 2.1/userdocs/flow/file:/home/daisy/tmpdocimport/documentation/apidocs/org/apache/cocoon/environment/Request.html [java] ^ 2.1/userdocs/flow/file:/home/daisy/tmpdocimport/documentation/apidocs/org/apache/cocoon/environment/Session.html [java] ^ 2.1/userdocs/flow/file:/home/daisy/tmpdocimport/documentation/apidocs/org/apache/cocoon/environment/Context.html [java] ^ 2.1/userdocs/flow/file:/home/daisy/tmpdocimport/documentation/apidocs/org/apache/cocoon/components/flow/WebContinuation.html [java] Total time: 13 minutes 5 seconds, Site size: 18,514,599 Site pages: 353 [java] Java Result: 1 [echo] Copying broken links file to site root. [copy] Copying 1 file to /var/apache2/htdocs/ft/build/cocoon-docs [echo] Oops, something broke On what exactly can ForrestBot fail? The only thing I get from the report is that there are a broken link and some links with file: somewhere in the middle of the name. The forrestbot will break on broken links. The details of the broken links are in broken-links.xml in the root of the built site. But in this case it doesn't help a great deal because of the nuances of the Daisy plugin. I logged into the forrest zone where the Cocoon site is built for you and did: [EMAIL PROTECTED]:2.1]$ grep prepare-mojo * 1297.html:goal documentation generated from the Javadoc NB if you don't have a log in for the zone you can always grab the latest build from http://forrest.zones.apache.org/ft/build/cocoon-docs.tar.gz So now we know which file contains the offending link to a non-existent document. http://cocoon.zones.apache.org/daisy/cdocs/g1/g5/g1/g1/1297.html I've removed the dodgy link so things should build now - we'll see on the next scheduled build cycle (I'm not sure about the other stuff in the log above - lets see if that did the trick) Ross [1] http://forrest.zones.apache.org/ft/build/cocoon-docs/broken-links.xml
Re: ForrestBot build for cocoon-docs FAILED
Ross Gardler wrote: [EMAIL PROTECTED] wrote: Automated build for cocoon-docs FAILED Log attached. ... [copy] Copying 1 file to /var/apache2/htdocs/ft/build/cocoon-docs [echo] Oops, something broke Can whoever broke this please fix it - the nags are annoying and I don't have the time to find other peoples bad commits. Sorry Cocoon folks, I thought this was the Forrest build that was breaking and nobody was dealing with it. My mail filters got confused. Now I see it is the Cocoon docs I recognise it's not that simple. I'll reply to Joerg's mail on this topic in a few moments. Ross
Re: ForrestBot build for cocoon-docs FAILED
[EMAIL PROTECTED] wrote: Automated build for cocoon-docs FAILED Log attached. ... [copy] Copying 1 file to /var/apache2/htdocs/ft/build/cocoon-docs [echo] Oops, something broke Can whoever broke this please fix it - the nags are annoying and I don't have the time to find other peoples bad commits. Ross
Re: [vote] Thorsten Scherler as new Cocoon committer
Ard Schrijvers wrote: I propose Thorsten Scherler as a new Cocoon committer and PMC member. +1 +1 Ross
Re: [Vote] Jasha Joachimsthal as new Cocoon committer
Jeremy Quinn wrote: On 29 Jul 2008, at 10:18, Andrew Savory wrote: It's my pleasure to propose Jasha Joachimsthal as a new committer on the Apache Cocoon project. My +1 +1 Ross
Re: ForrestBot build for cocoon-docs FAILED
On 08/10/2007, Reinhard Poetz <[EMAIL PROTECTED]> wrote: > Ross Gardler wrote: > > On 08/10/2007, [EMAIL PROTECTED] > > <[EMAIL PROTECTED]> wrote: > >> Automated build for cocoon-docs FAILED > > > > Am I correct in thinking Cocoon does not use the Forrest built docs anymore? > > > > Can we (Forrest) remove this automated build or do we need to fix this? > > > > (Note the fix is easy, I can make the fix in almost no time, but not > > sure it is necessary) > > The main site and the Cocoon 2.2 docs are built using the Maven Daisy Export > Plugin. The Cocoon 2.1 docs are still build by Forrest. Therefore I'd say that > we still need the Forrest build because (minor) changes to the 2.1 docs will > be > necessary now and then. ok, I can't do the fix for a coupleof days as I'm travelling. I'll fix ASAP, I'm pretty sure know how I broke it (aminor change in one of theForrest plugins forces a newproperty requirement in cocoondocs) Ross
Re: ForrestBot build for cocoon-docs FAILED
On 08/10/2007, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Automated build for cocoon-docs FAILED Am I correct in thinking Cocoon does not use the Forrest built docs anymore? Can we (Forrest) remove this automated build or do we need to fix this? (Note the fix is easy, I can make the fix in almost no time, but not sure it is necessary) Ross
Re: [graphics] Final version of new Cocoon masthead
Andrew Savory wrote: Once again a big round of applause to Thien. Absolutely. Many thanks, Thien, excellent work! I've kept quiet throughout this work due to other commitments and not wanting to get in the way. Now you reached the end it is time to speak up. Well done! I love the end result and I'm sure others will too. Ross
Re: Inactive Cocoon committers and PMC members
Joerg Heinicke wrote: On 14.03.2007 09:27, Ross McDonald wrote: I suppose a list of active committers will prevent people who are no longer active from receiving emails they don't want to receive from those looking for help.. so it may stop dead end investigations? In that way an up-to-date list of committers would be useful... Also perhaps some other information could be tied in.. such as who are the experts on which blocks or areas within Cocoon, so people who are newer to it could find out very quickly where to get help, given that the state of the docs is still somewhat patchy. This would save a lengthy exploration of the mailing lists, and get names up in obvious public view (such as on our soon to be released new website :-) ). Independent from the counter argument already given the Cocoon changes site [1] already gives this information in a more verbose way. Nobody needs to maintain this list explicitely and nobody might get the feeling that private mails are encouraged. Jörg [1] http://cocoon.apache.org/2.1/changes.html That's not more verbose, it also provides a simple list of contributors to a specific version and contributors to prrevious versions (see the end of the document). However, this only credits people who have an entry in status.xml, so does not credit people who have done other work, such as user support, dev discussion, issue tracking etc. Of course, status.xml could be used to record important events outside of the code base too. For example, an important design discussion could be recorded in status.xml with a link to the mail archives for reference. The onus is then on the people involved with the discussion to ensure that the details are recorded, otherwise they don't get credited with participation. An alternative would be to extract activity details from mailing list archives, issue tracker logs etc. But that all sounds like extra work to me. Ross
Re: Docs for 2.1.10
Carsten Ziegeler wrote: Ross Gardler schrieb: ... Thanks for the info! One final question :) where do I find the docs for 2.1 in Daisy? Fairly important I suppose... http://cocoon.zones.apache.org/daisy/documentation/659.html Ross
Re: Docs for 2.1.10
Carsten Ziegeler wrote: Bertrand Delacretaz wrote: On 12/21/06, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: Could someone please assemble the docs archive for the 2.1.10 release? The generated docs are available as a tar.gz archive from the "cocoon-docs.tar.gz direct download" link at http://wiki.apache.org/cocoon/CocoonWebsiteUpdate, IIUC this is what we ship with the release. Were you thinking of something else? Thanks Bertrand, this is exactly what I'm looking for. Is the download up to date? Or do I have to follow the procedure mentioned there? The download mentioned on that site is generated by Forrest every 12 hours. You only need to update the site manually if you don't want to wait for the next automated update. You can preview what is in the download by looking at http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/index.html You can also verify that there are no broken links by looking at http://forrest.zones.apache.org/ft/build/cocoon-docs/broken-links.xml (it should be empty of course). Ross
Writing and managing news releases (was Re: [RANT] The Cocoon website: move on, nothing is happening here)
Bertrand Delacretaz wrote: On 10/19/06, Ross Gardler <[EMAIL PROTECTED]> wrote: ...But is there any need for the news item to be sent to the live server immediately? I don't think so. A daily update will do just fine. For now use the Forrest generated tar, or a maven generated tar if someone sets it up... You're right, we don't have a need for immediate publishing, a few hours delay could be good enough. Let's see what happens with continuum, but in the meantime we could work as you suggest (assuming someone does write stuff, of course ;-) For those interested Reinhard and I have made a small start on the configuration of Daisy to manage news items in the 2.2 docs. The output needs to be "prettied up" - but it does work. Basically, create a new document of type "NewsItem" and publish it (or get an editor to publish it for you). The seven most recent will appear on the welcome page [1] I've added a tagging system that allows filtered news items to appear on welcome pages for "sub-sites" for each block. The tags field is free form, you can enter anything you want. We can use this field to filter news items. At present there is only one tag that does anything. If you add "core" to the tags your news item will appear on the "core" sub-site [2] [I'm not too familiar with the intended use of the cdocs layout can someone check I put this in the right place.] Sorry I've not added news filters for all of the blocks or added the "lazy consensus" date filter to the queries - no time today - maybe someone can do this. Ross [1] http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g1/1213.htm [2] http://cocoon.zones.apache.org/daisy/cdocs-core/1270.html
Re: [RANT] The Cocoon website: move on, nothing is happening here
I wrote a reply to Bertrands post then read the thread and discovered Reinhard is going to set up continuum. Seems like we have a volunteer and since I'm only giving ideas not implementation time you'd all be best to ignore the rest of this post ;-) Ross Bertrand Delacretaz wrote: On 10/18/06, Ross Gardler <[EMAIL PROTECTED]> wrote: ...Which publishing tool to use? I don't care. Forrest does it well (but it does need a new skin,... Is there a way to republish only a few pages quickly from Daisy to the online site? Or how hard is that to implement? A very good question - and one of the biggest problems with Forrest site generation at this time. Right now it cannot be done. It could be implemented, sure, but it is not easy, at least with my knowledge of the Cocoon CLI and crawler. The problem is that the crawler will follow all links on the page. Daisy can output a recent changed list, perhaps this could be used to limit the pages generated. A solution that requires no tools work... The Forrest zone is already building the site once a day as part of our docs validation process. Why not just grab the tar, untar, svn up (sounds like a script to me). Without going into a tools discussion, having a quick way to update just the homepage and the news (and maybe an aggregated blog feed) would help us be more active on those pages I guess. If I can add a news item in five minutes I'll do it regularly, if it takes 15 minutes it'll be much less often. Fair point. But is there any need for the news item to be sent to the live server immediately? I don't think so. A daily update will do just fine. For now use the Forrest generated tar, or a maven generated tar if someone sets it up. It will mean that someone in the community will need to log in to the Cocoon zone, execute a script, provide their SVN username and password and logout. I can't think of a faster way without working on the tools. Of course, the problem is who is the *someone*. Might simply be a case of the Forrestbot generating a subset tar.gz instead of the one pointed to by http://wiki.apache.org/cocoon/CocoonWebsiteUpdate (http://forrest.zones.apache.org/ seems to be down right now, cannot check it size but I assume it's quite big). No need to download to your local machine, do all the work in the zone.
Re: [RANT] The Cocoon website: move on, nothing is happening here
Daniel Fagerstrom wrote: we have plenty of activity in our community, so a couple of news items per month would be a much better reflection of our reality. So how do we achieve this? Some options (which don't require new tools): Daisy can be used to create "blog like" pages that can be automatically brought together into a news page. I agree that it should be the home page, but Daisy would not limit the info to just this page. Perhaps 3 items on the home page, and a larger news only page. Note that Daisy can also be made to create RSS feeds, but that's a "next step". Alternatively, have the site generation pull content from peoples existing blogs. Forrest has a plugin for this (although it is pretty basic), I'm sure Maven can be made to do it. The problem with this approach is that there is no control over the content that is published. Of course there are lots of other ways, but they involve new tools so I'm steering away form those. First I think we need some common idea about what is a news item. Some suggestions would be: All your suggestions look just fine, I'm sure having an exhaustive list is impossible, but your list is a great starting point. I'm more concerned about *who* will write these items and who will publish the site frequently. It really is a case of providing a login and password to a publishing tool after it is configured. Which publishing tool to use? I don't care. Forrest does it well (but it does need a new skin, there is a partially complete skin that Helma and I put together some time ago, but I have not had the time to finish it off yet. Second we need some (simple) way to suggest news. I think we should suggest possible news items at the dev-list by having a special headers prefix like [news]. I'd suggest just letting (self-registered) people add a news item to Daisy. Committers items will be published automatically, others will require publication by a committer - in daisy this is just a click of a link once logged in. Posting to the list is just a step too many in my view. Why not put it straight in Daisy where it can be edited and published quickly and easily. Don't forget Daisy edits are already sent to the docs list. Third, as the website is our official voice, we need some kind of community oversight. I think lazy consensus should be enough. If no one have protested in maybe three days, we should add the news item to the news page. Of course if someone with marketing skills would like volunteer and take a larger responsibility for creating and editing the news contents that would great. Sure, this all works fine with direct entry into Daisy rather then on the list (where everyone and their dog will chip in but only one or two will actually do anything). Daisy can be configured to only publish items that were written x days ago, thus automatically allowing for lazy consensus. --- I support the above as a "small step", I think it may encourage more people into using Daisy a little. Ross
Re: [RANT] The Cocoon website: move on, nothing is happening here
hepabolu wrote: I know that the current process of updating the cocoon.apache.org website is cumbersome, but still it's a whole lot better than the previous process. I really don't care if it takes one step or twenty, if in the end all I need to do is set a timer that reminds me to provide my username/password to start the update process every X days, I'd be glad to do that. However, that doesn't make sense when nobody bothers to write. And that, as most of us know, is the real problem. It really makes no difference how easy/hard documentation and publishing is. It just doesn't happen. For those new to this kind of discussion just check the archives - the solution proposed is always tools (and I've done it myself in the past). The new tools arrive and still there is no documentation. Ross
Named links in generated site docs (Re: updating the Cocoon website)
David Crossley wrote: See the new section at http://wiki.apache.org/cocoon/CocoonWebsiteUpdate to explain the quick way to update the Cocoon 2.1 docs. Any committer can do it. I followed this today (it has been 2 months since last update). However i don't have time to find out what is going wrong. Would someone else please follow up. -- Some links in the lef-hand navigation menus are being changed, and named documents are becoming numbers, e.g. -http://cocoon.apache.org/community/contrib.html";>Contributing +Contributing Has a navigation file changed in Cocoon's Daisy. Daisy does not store documents by name, it stores them by number. It is possible, via the navigation documents, to map a name to the number. Forrest does its best to work to what the intended name is when creating links, in the same way that Daisy does. The above problem is probably caused by (I have not verified this) the document in Daisy not being assigned a name in the navigation document. If it's not this then we have uncovered a bug in the Forrest XSL that generates the links. I've no time to investigate at present, but if someone can check the status of the Daisy navigation docs then it will at least tell us if we need to dig into the Forrest XSL. New documents are being added without names and not linked in to the navigation menus. Are these missing entries in a Daisy navigation file? Not necessarily. It is possible to have documents that are not in a navigation menu but are linked from another page. However, as I understand it, if they do not have a mapping from node number to name in the Daisy navigation docs then they cannot appear with a name in the final output. This is not a problem for new documents (no existing external links, therefore no broken links). However, if an old document is removed from a navigation page then the URL will change and any external links will break (which may be what is happening above). Ross
Re: ForrestBot build for cocoon-docs FAILED
[EMAIL PROTECTED] wrote: Automated build for cocoon-docs FAILED This time it is because the Daisy instance is down. Thorsten, I think your fix should work OK. Ross
Re: ForrestBot build for cocoon-docs FAILED
[EMAIL PROTECTED] wrote: Automated build for cocoon-docs FAILED Log attached. This is due to a change in the way Forrest SVN head is configured. Will fix ASAP. Ross
Re: ForrestBot build for cocoon-docs FAILED
[EMAIL PROTECTED] wrote: Automated build for cocoon-docs FAILED Log attached. I am looking into this. Sorry it's taken me so long to find the time. (we need someone else who knows how this works) Ross
Re: Can we store all docs in Daisy?
Carsten Ziegeler wrote: Ross Gardler wrote: hepabolu wrote: ... I'm not absolutely sure, but we could, as an itermediate solution, create a separate collection in Daisy in which we move those documents, which are then exported in the same way as the current Daisy docs. I don't think it would be much work to configure Forrest to do this. You are correct, this should not be too much work. Sounds great :) Has someone time to do this? :) HeHe, and there's the problem. First job is to create the new collection from the docs in SVN. Bruno wrote some scripts to do the original import, I guess these can be used again. Bruno? Once they are in Daisy I will do my best to find the time to modify the Forrest config. No promises, I'm realy busy right now, but it will be on my ToDo list. If someone else wants to tackle it I *will* make time to guide them. Having more people understand how it works is a priority. Ross
Re: Can we store all docs in Daisy?
hepabolu wrote: Carsten Ziegeler said the following on 28/7/06 14:00: We have currently a split storage for our docs (and different ways to update the docs). While the main docs for a version of Cocoon are stored in Daisy, the more general stuff, is stored in the cocoon-site module in the forrest format. Wouldn't it make more sense to use the same storage and way of editing for the whole site? What does it take to move the remaining docs into Daisy as well? Yes it would, but the problem lies in the way the URLs are handled. Worst case would be that the entire navigation of Daisy should be changed to reflect the correct layout. I'm not absolutely sure, but we could, as an itermediate solution, create a separate collection in Daisy in which we move those documents, which are then exported in the same way as the current Daisy docs. I don't think it would be much work to configure Forrest to do this. You are correct, this should not be too much work. Note, that would be for the more "static" documents. I'm not sure if the changes page should be built using Daisy. No the changes should continue to be built using the status.xml since that will be updated with commits to SVN, moving this to Daisy adds another step. Ross
Re: Incorrect link in forms documentation
Niels van Kampenhout wrote: Ross Gardler wrote: Niels van Kampenhout wrote: Hmm. I understand from Arje that the documentation I refered to in my post is outdated and not updated anymore. The latest documentation apparently is at cocoon.zones.apache.org. To be honest, I was under the impression that the docs @ cocoon.apache.org are the latest from Daisy... This is incorrect. The published docs are the ones from Daisy. There is a time lag between them being edited and them being published. How long that lag is depends on when someone is able to publish them. The docs from Daisy are built once a day by the Forrestbot, see [1]. These are not intended to be read by users, but are there so that devs can verify the latest version of the docs before they are published to the site. As for a link to the latest devlopment version of a doc in daisy, take a look at the bottom of any page in the docs collection where you will see the following text and link: "Errors and Improvements? If you see any errors or potential improvements in this document please help us: View, Edit or comment on the latest development version (registration required)." Oops, sorry, I was misinformed and didn't bother to check myself :-( Thanks for the clarification! Still I find it a bit confusing that there three publicly available URLs with potentially three different versions of the Cocoon documentation. How is it different from maintaing docs sources in SVN? In this case we would have a location for the sources (SVN), a location for the staging docs (local directory or a staging server) and a location for the public docs (web). The way I see it is: Dev docs in daisy are equivalent to svn sources (i.e for the devs) Forrest zone (or locally created docs) are equivalent to locally created docs from svn sources. These are for QA Published site is no different and is fo rthe end user. Ross
Re: Incorrect link in forms documentation
Niels van Kampenhout wrote: Reinhard Poetz wrote: Niels van Kampenhout wrote: Hi, I just noticed that there is an incorrect link in the Cocoon Forms documentation. In [1], at the end of the section "Selection lists", there is a link which should lead to more info on selection lists [2], but instead leads to the page about datatypes [3]. Very confusing. Can someone fix this? Thanks, Niels [1] http://cocoon.apache.org/2.1/userdocs/widgets/widget_field.html [2] http://cocoon.apache.org/2.1/userdocs/widgetconcepts/selectionlists.html [3] http://cocoon.apache.org/2.1/userdocs/widgetconcepts/datatypes.html thanks for spotting this. Fixed in Daisy now. Hmm. I understand from Arje that the documentation I refered to in my post is outdated and not updated anymore. The latest documentation apparently is at cocoon.zones.apache.org. To be honest, I was under the impression that the docs @ cocoon.apache.org are the latest from Daisy... > Isn't it ridiculous that if I click on 'documentation' at cocoon.apache.org, I am presented outdated docs, and no link whatsoever to the new ones? Not very user friendly, anyway. This is incorrect. The published docs are the ones from Daisy. There is a time lag between them being edited and them being published. How long that lag is depends on when someone is able to publish them. The docs from Daisy are built once a day by the Forrestbot, see [1]. These are not intended to be read by users, but are there so that devs can verify the latest version of the docs before they are published to the site. As for a link to the latest devlopment version of a doc in daisy, take a look at the bottom of any page in the docs collection where you will see the following text and link: "Errors and Improvements? If you see any errors or potential improvements in this document please help us: View, Edit or comment on the latest development version (registration required)." Ross [1] http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/index.html
Re: [Vote] New committers
Joerg Heinicke wrote: 1. Andreas Hochsteger +1 2. Peter Hunsberger +1 3. Jason Johnston +1 Welcome to all three. Ross
Re: ForrestBot build for cocoon-docs FAILED
Bruno Dumon wrote: On Fri, 2006-05-05 at 16:28 +0100, Ross Gardler wrote: [EMAIL PROTECTED] wrote: Automated build for cocoon-docs FAILED ... http://cocoon.zones.apache.org/daisy/documentation/864/forms/widgets/739.html In this document we can see that daisy is using a pseudo protocol of "javadoc:". This protocol is not processed by Daisy when publiching the XML version of the document, and Forrest knows nothing of this pseudo-protocol. However, all is not lost. I recall reading on the Daisy dev list that it uses Forrests locationmap code to handle psuedo protocols like this. if someone can point me at how this is done within Daisy I'll look at making the forrest publication honour the protocol. Alternatively, we need the XML source to contain the URI that this resolves to. Oops! I knew there was some reason I couldn't use this feature yet, but had forgotten about it. Just an update on the current status of this I tried to include the javadoc: protocol support in Forrest the other day, unfortunaly I discovered a bug in SVN head of Forrest that prevents it working. I've got to find out what this is and fix it before the Cocoon-Docs will build properly again, I'll work on it as and when time allows, but please do not hold your breath. Ross
Re: ForrestBot build for cocoon-docs FAILED
Bruno Dumon wrote: On Fri, 2006-05-05 at 16:28 +0100, Ross Gardler wrote: [EMAIL PROTECTED] wrote: Automated build for cocoon-docs FAILED ... This looks like someone has used a javadoc: protocol in the source files. Unfortunately, Daisy does not recognise ... Oops! I knew there was some reason I couldn't use this feature yet, but had forgotten about it. Below is the information about how it is configured. If it would be too inconvenient to add it to forrest right now, I can remove the usages of "javadoc:" in the document itself (though its *very* handy). It's only a matter of finding the time - I don't forsee a problem. I should be OK to do this within a few days. Ross
Re: ForrestBot build for cocoon-docs FAILED
[EMAIL PROTECTED] wrote: Automated build for cocoon-docs FAILED ... [java] X [0] 2.1/userdocs/widgets/javadoc:org.apache.cocoon.forms.formmodel.tree.TreeModel BROKEN: No pipeline matched request: 2.1/userdocs/widgets/javadoc:org.apache.cocoon.forms.formmodel.tree.TreeModel [java] X [0] 2.1/userdocs/widgets/javadoc:org.apache.cocoon.forms.formmodel.tree.Tree BROKEN: No pipeline matched request: 2.1/userdocs/widgets/javadoc:org.apache.cocoon.forms.formmodel.tree.Tree [java] X [0] 2.1/userdocs/widgets/javadoc:org.apache.cocoon.forms.formmodel.tree.TreeWalker BROKEN: No pipeline matched request: 2.1/userdocs/widgets/javadoc:org.apache.cocoon.forms.formmodel.tree.TreeWalker This looks like someone has used a javadoc: protocol in the source files. Unfortunately, Daisy does not recognise We can see which pages contain these broken links by lookig at: http://forrest.zones.apache.org/ft/build/cocoon-docs/broken-links.xml That leads us to: http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/userdocs/widgets/widget_tree.html from where we can get to the Daisy source page by following the edit link at the bottom of the page: http://cocoon.zones.apache.org/daisy/documentation/864/forms/widgets/739.html In this document we can see that daisy is using a pseudo protocol of "javadoc:". This protocol is not processed by Daisy when publiching the XML version of the document, and Forrest knows nothing of this pseudo-protocol. However, all is not lost. I recall reading on the Daisy dev list that it uses Forrests locationmap code to handle psuedo protocols like this. if someone can point me at how this is done within Daisy I'll look at making the forrest publication honour the protocol. Alternatively, we need the XML source to contain the URI that this resolves to. Ross
Re: [ANN] Apache Cocoon 2.1.9 Released
Andreas Hochsteger wrote: Congratulations to all who were involved - you did an awesome job! BTW the page changes.html still shows TBD as release date. This will be corrected when someone updates the website with the new docs build I created tonight. Ross
Re: Docs for 2.1.9
Ross Gardler wrote: Carsten Ziegeler wrote: Antonio Gallardo schrieb: Carsten Ziegeler escribió: Can someone please generate the docs for the 2.1.9 release, so we can put an archive of the docs in the download area like we did for 2.1.8? Carsten Thanks Carsten for the release. As usual, I will take care of the javadocs. ;-) Great, thanks Antonio. I ment the "real" docs from Daisy which we provide as a separate package for download. I've read this and will do my best to create the package sometime over the weekend built docs are available at http://forrest.zones.apache.org/ft/build/cocoon-docs.tar.gz Can someone else please update the website, I'm off to bed. Ross
Re: ForrestBot build for cocoon-docs FAILED
[EMAIL PROTECTED] wrote: Automated build for cocoon-docs FAILED This failure is because I am working on the docs right now. Please ignore. Ross
Re: Docs for 2.1.9
Carsten Ziegeler wrote: Antonio Gallardo schrieb: Carsten Ziegeler escribió: Can someone please generate the docs for the 2.1.9 release, so we can put an archive of the docs in the download area like we did for 2.1.8? Carsten Thanks Carsten for the release. As usual, I will take care of the javadocs. ;-) Great, thanks Antonio. I ment the "real" docs from Daisy which we provide as a separate package for download. I've read this and will do my best to create the package sometime over the weekend, I'm afraid I can't do it sooner than that. I still haven't fixed the broken changes.html file though, if anyone else gets to the docs gen before I do I suspect it is a simple problem with the locationamp entry for the status.xml file. Ross Ross
Re: [RT] The environment abstraction, part II
David Crossley wrote: Carsten Ziegeler wrote: I can't speak for Daniel, but my idea/suggestion was to forget about the different environments and let Cocoon always run in a servlet container. The CLI would then be kind of a http client which starts up jetty and then generates the site using http requests. This would simplify some things in Cocoon, the question is if this would make the life of Forrest too hard? Thanks to you all for the followup. I don't have a ready answer yet. Will make sure that the other Forrest people are aware. Which David has done, with a post to the Forrest list - you may see a few of us post now. I've reviewed this thread, in my opinion and *only* from a Forrest perspective I feel it is unimportant how we generate the static site from Forrest. To be honest, I don't really care if we end up bundling a building/bundling a small crawler along the lines of wget in order to do the static generation (although it is great we won't need to). It looks to me like the proposals here will make life inside Cocoon much easier. This will, undoubtedly, have a knock on effect for projects like Forrest. I'm sure we will have to go through a period of pain before reaping the rewards - but I believe it will be worth it. --- Speaking in a from a wider perspective. I would ask one important question "how many other users, besides Forrest, make heavy use of the CLI and would they be damaged by this proposal?" I would *guess* this is a low number since Cocoon is a *web* framework. Ross
Re: Updating the Website
Jean-Baptiste Quenot wrote: Hello, Is it possible to propagate the update of this page from Daisy to the website: http://cocoon.apache.org/community/members.html Or please tell me where to edit it. That part of the site is not in Daisy. It is still in SVN - only the 2.1.x docs are currently published from Daisy. BTW what remains to be done to switch from the old site to the new one? That all depends on what you mean by "old" and "new" Ross
Re: [vote] Niclas Hedhman as a new Cocoon committer
Daniel Fagerstrom wrote: Hi all! I'd like to propose Niclas Hedhman as a new Cocoon committer. He has been around at cocoon-dev since 2000, regularly delivering insight full comments about technical as well as community questions, high quality patches and strong opinions in various topics ;) He has been and is committer and active in several other Apache projects and have started some OS projects outside Apache. He is also an expert member of JSR 291 (OSGi), and earlier JSR-78 (RMI Custom Remote References). Please cast your votes. +1 Ross
Re: ForrestBot build for cocoon-docs FAILED
David Crossley wrote: Ross Gardler wrote: Perhaps there is a time out occuring. Is there a way of increasing the timeout on files being generated from http: sources? Not a solution, but it would be a workaround. I don't know if it proves anything, but just completed a local build and it worked. This is horrendously slow for some reason (takes 25 seconds per page). Well it proves there is nothing wrong with the conversion process, there is something wrong with the interaction between forrest and the daisy publisher, but only when running on the zones. With respect to the speed, I have noticed one of my own sites, building using a different instance of Daisy is also very slow. I'm thinking that the caching of the site.xml file (which is generated from the daisy.site.* urls) may be failing for some reason (this is done in the sitemap). I'll investiagate as soon as I can. What I find interesting about the failures is that they all come towards the end of the build, and at inconsitent times. I've seen something similar when I have been doing a manual forrestbot build and the cron job for updating the forrest installation has fired up in the middle of the build. I wonder if the two cron jobs are overlapping - this is especially likely if the build on the zones is as slow as you are experiencing locally. Ross
Re: ForrestBot build for cocoon-docs FAILED
Bruno Dumon wrote: On Tue, 2006-03-21 at 19:11 +1100, David Crossley wrote: David Crossley wrote: Bruno Dumon wrote: BTW, this time not because the zone was restarted. Not sure what the problem is though. I investigated a bit yesterday, but cannot see what is the problem. Notice that today there are less breaks than yesterday. However, looking at the cocoon-docs mailing list diffs from Daisy i cannot see any relevant changes. http://forrest.zones.apache.org/ft/build/cocoon-docs/broken-links.xml It complains about Daisy IDs 786 and 655 which are navigation documents. Surely Forrest's Cocoon had already processed those resources. Strange. I am stumped. Ross seems busy with other stuff. Curiouser and curiouser. At the next 12-hourly run there is only one breakage and for a different ID. FYI: I've had a look at the Daisy log files, and don't see anything there. The server has also been continuously up. I've not looked into this in any detail. I'm swamped right now. But it looks to me like there are intermittent network problems between the two zones. I've noticed this failure come and go without anyone touching our Forrestbot or the sources. Is this possible, as far as I am aware they are on the same physical machine, but separate virtual machines. Perhaps there is a time out occuring. Is there a way of increasing the timeout on files being generated from http: sources? Not a solution, but it would be a workaround. Ross
Re: [docs] @cocoon.sitemap tags and Daisy
Bruno Dumon wrote: The goal of all this would be that the basic facts about each component are taken from the source code, and longer (user-oriented) documentation could then be added in Daisy (in a document part that is left alone by this tool). Super cool! Ross
Re: Use Maven 2 for the generation of the Cocoon documentation
Bruno Dumon wrote: On Mon, 2006-03-06 at 18:39 +0100, Reinhard Poetz wrote: hepabolu wrote: Finally, adding the proposed plugin can always be added later without loosing the effort of the current setup. ok, that's right. Anyway, I can't do it myself now but if somebody is interested, I can help. Maybe some of the Daisy gurus here can comment on the idea itself? It shouldn't be too hard. If it is just for publishing, you don't even need the Daisy client libraries, being able to do a HTTP request is enough. Actually, I should correct my previous statement the Forrest plugin uses the http API not the Java client API. No need for the Java API at this stage. I'm not sure what the difficulties are that Ross refers too in reusing the navigation documents. A basic plugin can probably be created in a day (by an experienced Java/XSLT person). Actually, my comment was misleading, sorry. The "difficulties" are not with Daisy itself, rather with the fact that we need(e) to maintain the existing directory structures of the documents and the Daisy nav system didn't work in the same way as the old nav system. With the 2.2 docs there is no legacy structure to maintain so it will be much easier. Ross
Re: Use Maven 2 for the generation of the Cocoon documentation
Reinhard Poetz wrote: As written in my mail "Status of block development" (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=114165989221631&w=2) I propose a change in the Cocoon documentation creation: We have put a lot of work into the Mavenization of the Cocoon build system. As you might know, Maven provides a site generation goal "site:site". This makes is very simple to integrate a lot of reports (javadocs, jdepend, cobertura, svn activities, ...) and uses information available in pom.xml to produce docs. IMO the only missing part is the integration of our docs that are managed by Daisy. My idea is: - write a Maven plugin that can access Daisy - it is configured by the doc-id of a navigation documentent which is the root of the block documentation - the plugin uses the Daisy client API to access this navigation doc and generates docs out of it by crawling all references docs and resources. The result of this process is added to the generated site. First, does this proposal make sense from a technical point of view? Is anybody interested in working on this? I can help with the Maven part of starting a Maven plugin project a bit. I have no experience of Maven so can make no comment on that end of things. Reusing the Daisy navigation documents is not a trivial task, but it is certanly possible. What you describe is exactly what the Forrest plugin does. An alternative approach, and one that I am keen to follow if my own time allows (not right now). Is to create a Maven plugin for Forrest, thus we would use the two tools to produce what they are best at. However, as I said, I do not have the time to do this right now. So if someone wants to go the maven plugin route then go for it. Ross
Re: [Docs] FAQ Document Type
Bruno Dumon wrote: On Wed, 2006-03-01 at 14:01 +, Ross Gardler wrote: A couple of weeks ago I promised to set up a FAQ system in Daisy. I've now done this. Creating a FAQ == There is a "FAQ" document Type. This is a simple document in which the document title should be the question and the content should be the answer. To illustrate things I have copied the "installation faqs" from http://cocoon.apache.org/2.1/faq/faq-install.html into individual FAQ documents, for example: http://cocoon.zones.apache.org/daisy/documentation/799.html?branch=1&language=1 http://cocoon.zones.apache.org/daisy/documentation/806.html?branch=1&language=1 So, if people like this, we should migrate all FAQs from the legacy docs into this format, as well as including relevant ones from the Wiki. Ross Thanks for setting this up. I have some reservations though about copying the FAQs from the legacy docs. I haven't read them all but a lot of them have become either incorrect or irrelevant. One of the reasons for the "new documentation" is that we can leave behind the outdated information. Yes, that makes sense, I'm a little behind with Cocoon, so do not have the knowledge to decide what goes in and what stays out. I'd also like to change the query in the navigation to a query in a document: having the long questions in the navigation doesn't make sense I think. +1 I only really threw these in as examples. Later I realised I had not done an example of creating a complete FAQ document (i.e. with questions & answers) only of indexes (bth navigation and in document). None daisy users should be aware that the query system in Daisy is superb and very flexible. If folk want something better than is currently in place then just ask how (or do it). Similar to the FAQ doctype, I'd also like to set up a "GlosarryItem" doctype which can be used to provide short explanations of Cocoon-specific terms (such as sitemap, subsitemap, FOM, flowscript, blocks, real blocks, ...). +1 Ross
[Docs] FAQ Document Type
A couple of weeks ago I promised to set up a FAQ system in Daisy. I've
now done this.
Creating a FAQ
==
There is a "FAQ" document Type. This is a simple document in which the
document title should be the question and the content should be the answer.
To illustrate things I have copied the "installation faqs" from
http://cocoon.apache.org/2.1/faq/faq-install.html into individual FAQ
documents, for example:
http://cocoon.zones.apache.org/daisy/documentation/799.html?branch=1&language=1
http://cocoon.zones.apache.org/daisy/documentation/806.html?branch=1&language=1
Tagging Faqs
There is an (optional) "tags" field. This can take any number of "tags"
for categorisation of the content. These tags can then be used by the
Daisy query language to build dynamic FAQs.
To create the Installation FAQ index we use a query such as:
select name
where documentType='FAQ'
and InCollection('documentation')
and $Tags='Installation'
Which results in the page at
http://cocoon.zones.apache.org/daisy/documentation/faq.html
FAQ Reuse
-
Custom FAQs can be built from multiple FAQ documents by adding relevant
tags to the appropriate FAQ entries and building a query such as that
above. That is, a single FAQ may appear in more than one FAQ index.
For example, we may have a number of CForm FAQs some of which deal with
the XYZ widget, while others deal with different aspects of CForms.
Tagging FAQs effectively, say with "CForm" and "XYZ widget", allows us
to create a CForm FAQ index which includes all relevant FAQs. At the
same time we can use a search on the "XYZ widget" tag to include the
relevant FAQs within the documentation for that individual widget.
FAQ Navigation
==
It is also possible to create dynamic FAQ indexes in the navigation
menu, for example, see the FAQs/Installation node (expanded on
http://cocoon.zones.apache.org/daisy/documentation/faqs/install/799.html )
So, if people like this, we should migrate all FAQs from the legacy docs
into this format, as well as including relevant ones from the Wiki.
Ross
Re: [DOCS] Missing ChangeLog
Jean-Baptiste Quenot wrote: Hello, This page is broken on the Cocoon website: http://cocoon.apache.org/2.1/changes.html BTW what is the status of the new documentation? When will it be made public? Thanks in advance, Blast. David Crossley pointed this out on the Forrest lists when he noticed the probelm in the Forrestbot staging site. I promised to look into it an promptly forgot. Unfortunately, someone has since republished the site. It's come back to the top of my radar again, should be able to look into it tomorrow afternoon (GMT). Ross
Re: ForrestBot build for cocoon-docs FAILED
Ross Gardler wrote: [EMAIL PROTECTED] wrote: Automated build for cocoon-docs FAILED Ooops sorry, too quick, in trying to formulate my question I realised I'd misread the log. The problem is not with the Forrestbot, it is that the Daisy instance is down again. Ross
Re: ForrestBot build for cocoon-docs FAILED
[EMAIL PROTECTED] wrote: Automated build for cocoon-docs FAILED ... [java] [copy] Copying 6 files to /var/apache2/htdocs/ft/build/cocoon-docs/skin [echo] Copying project skin css and js files to site ... [copy] Warning: /var/apache2/htdocs/ft/src/documentation/skins/common not found. [copy] Warning: /var/apache2/htdocs/ft/src/documentation/skins/pelt not found. This looks like a Forrestbot problem. I've been away for a week or so, working through mail backlog. Will ask Forrest devs if they know what happened. Ross
Re: [WEBSITE] 2.1/userdocs/concepts/modules-ref.html
Alexander Lochschmied wrote: Hello, pretty much on top of this page the link to InputModules Wiki Page is broken. http://wiki.apache.org/cocoonInputModules/ should be replaced by http://wiki.apache.org/cocoon/InputModules as it’s a good page. If you register on Daisy, the CMS we use for our docs, you can make the change yourself in less time than it takes to write this email. We'd really appreciate your help. Follow the link at the bottom of any page to be taken to the relevant page in Daisy. The first time you go there you will need to register in order to be able to edit. Edits to these pages do not appear immediately in the website, they must first be approved by an editor and the site must be rebuilt which is done infrequently at present. However, by making the change you are starting the ball rolling. Thanks, Ross
Re: [docs] regenerated website; why extra docs?
hepabolu wrote: David Crossley wrote: Today i re-generated the cocoon.apache.org/2.1/ website which incorporates a few changes to the Daisy sources, fixes some links that used local hrefs, removes the old ApacheCon logo. There were some new documents generated which do not have any mapping in the navigation. Does someone know what should happen with them? ... They will be linked from another page and thus find their way into the docs. You can check what is linking to a document by visiting the page in Daisy and clicking the "referers" link on the right. For example, the first in your list (doc 372) is referred to by doc 611 (which is http://cocoon.zones.apache.org/daisy/legacydocs/documentation/developing/concepts/httprequest.html which is referenced in the navigation). Interestingly this document (372) is actually an image and therefore should not be linked to like this but embedded as an image. How does Forrest render this document? I didn't (knowingly) handle non-embedded image files in the Forrest plugin. We may need to add some special handling for this. ... New documentation for new releases should go into the "official documentation". However, nobody has decided yet on a structure for that collection nor for the subsequent structure of the navigation as it goes onto cocoon.apache.org. So I suggest that for now you ignore the newly created files when website is re-generated. No, this is not possible. Remember we are building the Forrest site structure from those defined in Daisy. To "ignore" some of the daisy files like this we will need to define a separate Forrest site structure. This is possible but we decided against it when creating the site. What I think we should be doing is creating a new version of the documentation, just as we do with code. Someone (me, the authors, or someone else) has to go through these files, and decide on the following: 1. do they describe something that is part of the next upcoming 2.1.X release? - Yes: add them to the navigation menu in the "legacy documentation" at an appropriate place and give them a "name" in that menu. This is not always appropriate. The above example, in which a new document is an image file is one such example. Furthermore, this assumes that al documents should appear in the navigation menu, which I do not believe is the case. We need to be making the main nav menu smaller and less confusing, not larger. Better to create a new version of the docs for 2.1.9 3. are they random thoughts, wild ideas, parking places for unfinished things? - Yes: mark them as such, they should not be exported as documentation - No: should it really be there? Can't it be deleted? There should be another collection for such "scratchpad" work. We can easily move stuff out of the scratchpad and into an "offical" collection. That leaves us with the decision on the navigation structure of the 2.2/3.0 documentation. It was already decided that the navigation in Daisy should be targeted towards editors (i.e. simplify their work), while the "official" navigation could be entirely different. Maybe we should use the Daisy books definition for the navigation structure of the website to take advantage of the query-based navigation possibilities (or are they not present in books definitions?). Use the books structure for what it is intended for - printed books. Use the daisy navigation structure for what it is best for - web sites. You can have different navigation menus for different purposes, i.e. one for editos, used in Daisy, one for users, used for the user focussed portion of the web site, one for devs, for the dev portion of the web site, etc. Query based nacigation is possible in normal navigation menus as well as book's. When I find the time to put the FAQ documents together you will see an example of what I mean. Ross
Re: New skin for web site
David Crossley wrote: hepabolu wrote: BTW do you like the layout of the Notes, Warnings and Fixes? (See samples page) The main trouble that i see, is that it puts each "note" out-of-context with the main page, i.e. not sure what the warning refers to. Thanks David, I meant to say that, but it got lost in the last few days work. I also feel the context of the note/waring/fixme has been lost, i.e. it is no longer attached to the paragraph that it followed. Otherwise great. Thanks for your excellent work. +1 Ross
Re: New skin for web site
hepabolu wrote: http://web.inter.nl.net/users/hepabolu/cocoondocsskin/index.html and http://web.inter.nl.net/users/hepabolu/cocoondocsskin/samples/sample.html I'll send Ross the set of files offlist so he can figure out what to change to integrate it in Forrest. Great stuff Helma. I've attached your zip to an Issue in the Forrest Jira. I don't have the time to integrate it right now, but someone (or I) will soon. http://issues.apache.org/jira/browse/FOR-817 Ross
Re: A new FAQ entry?
Derek Hohls wrote: I like the idea of a categorised FAQ - a simple Q&A list is fine for a simple project - but Cocoon is *not* that by any measure. Can one have other categories as well? Yes, the category field is a multivalued field. Alternativley, we could just use a "tags" field allowing freeform tagging of the FAQ entries. However, I'm not a big fan of this approach in documentation, it tends to end up a little too unstrucutred. It would be great if we could start with the list that is already in the Wiki... if you need help creating the info for the FAQ, once the code has been setup, please post a request here. Will do - thnks, I'll wait another couple of days to see if anyone has any objections. Ross > [EMAIL PROTECTED] 2006/02/07 06:03:22 PM >>> Berin Loritsch wrote: This is really a three pronged question: 1. Do we have a project FAQ? 2. Where is it? on daisy? (assumption - there isn't a FAQ already) I use Daisy on an in-house project for documentation. One of the things we have done is create a FAQ document type which has a "question" and an "answer" part and a category field (user, developer, installation etc.) We then use the query facilities on daisy to automatically create a variety of FAQ documents. One advantage of this over having a normal document listing the faqs is that you can include each FAQ in other documents. For example, by having a field "commonality" wich is set to "uncommon" or "common", we can use another query to include the common FAQs on relevant pages, e.g. the install documentation can includes the common install FAQs at the end, whilst the "uncommon" ones appear in only in the list of FAQs. I could set this up on the Daisy instance if you like. Perhaps just starting with the basic FAQ doc type for now. Ross
Re: A new FAQ entry?
Berin Loritsch wrote: This is really a three pronged question: 1. Do we have a project FAQ? 2. Where is it? on daisy? (assumption - there isn't a FAQ already) I use Daisy on an in-house project for documentation. One of the things we have done is create a FAQ document type which has a "question" and an "answer" part and a category field (user, developer, installation etc.) We then use the query facilities on daisy to automatically create a variety of FAQ documents. One advantage of this over having a normal document listing the faqs is that you can include each FAQ in other documents. For example, by having a field "commonality" wich is set to "uncommon" or "common", we can use another query to include the common FAQs on relevant pages, e.g. the install documentation can includes the common install FAQs at the end, whilst the "uncommon" ones appear in only in the list of FAQs. I could set this up on the Daisy instance if you like. Perhaps just starting with the basic FAQ doc type for now. Ross
Re: Cocoon zone services are down again (Was: ForrestBot build for cocoon-docs FAILED)
David Crossley wrote: Ross Gardler wrote: Ross Gardler wrote: Bruno Dumon wrote: I restarted them now. Is it necessary that the forrestbot runs so often? Seems like now it runs every 3 hours. IMO once or twice a day would be enough. No it isn't necessary anymore - was handy when doing the work to create the new docs. The idea of frequent builds is to (almost) immediately show errors in the editing which will prevent building the site. But in Cocoons case most of the possible breaks (i.e. ill-formed XML) are handled by Daisy. I'll reduce it to midnight and mid day UTC. Ooops, I can't it's not in my crontab. David, can you please modify the crontab entry for cocoon-docs accordingly. Done. However there is another reason to have it build more often. It would then detect broken internal links and report them quickly, so the user knows that they broke it and can fix it immediately. Daisy handles those too, as long as the links are created correctly (i.e. not using http://cocoon.apache.org/..., but using daisy:...) I am amazed that people want it changed just because of a few error messages, mostly for another reason. Also it reminds us that the zone services are down. That's true. Ross
Re: Cocoon zone services are down again (Was: ForrestBot build for cocoon-docs FAILED)
Ross Gardler wrote: Bruno Dumon wrote: I restarted them now. Is it necessary that the forrestbot runs so often? Seems like now it runs every 3 hours. IMO once or twice a day would be enough. No it isn't necessary anymore - was handy when doing the work to create the new docs. The idea of frequent builds is to (almost) immediately show errors in the editing which will prevent building the site. But in Cocoons case most of the possible breaks (i.e. ill-formed XML) are handled by Daisy. I'll reduce it to midnight and mid day UTC. Ooops, I can't it's not in my crontab. David, can you please modify the crontab entry for cocoon-docs accordingly. Ross
Re: Cocoon zone services are down again (Was: ForrestBot build for cocoon-docs FAILED)
Bruno Dumon wrote: I restarted them now. Is it necessary that the forrestbot runs so often? Seems like now it runs every 3 hours. IMO once or twice a day would be enough. No it isn't necessary anymore - was handy when doing the work to create the new docs. The idea of frequent builds is to (almost) immediately show errors in the editing which will prevent building the site. But in Cocoons case most of the possible breaks (i.e. ill-formed XML) are handled by Daisy. I'll reduce it to midnight and mid day UTC. Ross
Re: New skin for web site
hepabolu wrote: Ross Gardler wrote: hepabolu wrote: Ross Gardler wrote: 2) are there any web designers here willing to work on the skin (you don't need to learn how to get it into Forrest at first, just provide CSS patches and I'll integrate with Forrest for you - you'll quickly see how it is done) ... If you could provide me the end result (i.e. some HTML pages and the resources like images and CSS), I'll give it a go. I've worked out something. It is visible here: http://web.inter.nl.net/users/hepabolu/cocoondocsskin/index.html This looks really nice. When you have received feedback and are ready send me the updated files and I'll put it into a theme for Forrest so that we can generate the Cocoon docs on the staging server using them and try and get wider comment from the list. Some remarks: - I can't make up my mind whether the search box should be at the top of the nav menu (directly visible and at hand) or at the end (gives a nice closure to the menu), so both versions of the samples have it at different locations. At the end looks better, but with a long menu will disappear of the screen. - I added some extra HTML to make the accessibility easier and the unstyled version clearer. Hmmm... depends on exactly what you have done. We have a great deal of control over the structural elements of the page ( etc.) and over the decorations of the page (navigation for example) but very little control over the HTML used in the content since that is managed by Daisy. - I removed all nested tags. This seems like a bug: almost all links were added twice, one nested in the other. Interesting, we (Forrest) recently had a report of a strange bug that related to duplicate anchors. I'll have to look into this, I agree it is a bug. - XHTML 1.0 Strict doesn't allow '+' in the anchor names, at least according to Tidy. I've changed them to underscores. Depends on what these anchor names are, if they are manually entered into the src docs then it is editor error on the part of the sample files used to generate this sample site. If they are auto generated by Forrest we can, of course change this. I'll have to check with the Forrest devs on why we use a '+' - I've split the CSS files in layout, nav and "the rest". This way it is easier to focus on layout only and nav only. They are imported in the "coat.css" file, so there is still only one CSS file to include. I see no problem with Forrest respecting this. Ross
Re: broken URL-space for 2.1 docs (Was: svn commit: r372211 - /forrest/trunk/...)
David Crossley wrote: hepabolu wrote: David Crossley wrote: It seems that despite our concerns and attempts to address it at the time, we still broke the URL space when publishing the 2.1 docs. Vadim, Helma, ... does anyone still have a list of the filenames from when we investigated this. We will need to set up re-directs now. Hi David, I'm not sure which files you mean. I found this thread: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113172159810450 Does this one (and the others in the vicinity) contain the files you are looking for? That is it thanks. Hmm, looks like a big job. Not sure that i can manage it. That is not the most recent list. There are far fewer than that now. I don't have time to look through the archives now, but I think we had it down to a handful of directories that needed redirecting. There was a list posted here. Ross
Re: WEBSITE]2.1/installing/jars.html
Joerg Heinicke wrote: On 19.01.2006 17:01, Ross Gardler wrote: http://cocoon.apache.org/2.1/installing/jars.html What *should* be going in here and how did it get there with the old build system? Is this something Forrest needs to handle? AFAIR it was generated from our jars.xml in the lib dir and with "build docs". I guess that means there is an XSL file for it. I'll hunt around when I get time and create a plugin to generate the content from the file in SVN. Ross
Re: WEBSITE]2.1/installing/jars.html
John L. Webber wrote: Following the link http://cocoon.apache.org/2.1/installing/jars.html brings the message: "This is now an autogenerated document. If you see this message, then something is wrong with the build!" Is this a known problem? ;-) It is now ;-) Thanks for reporting this. What *should* be going in here and how did it get there with the old build system? Is this something Forrest needs to handle? Ross
New skin for web site
When we were doing the work to generate the Docs from Daisy some people showed an interest in developing a new skin for the Cocoon site. Those people may be interested to know that I recently developed a skin to mimic the look and feel at http://www.apache.org This is a much simpler skin, much cleaner and much easier to modify. It is *not* complete. I am not a CSS expert and I have not done any checks in different browsers. But it's a good start I created two versions of this skin, one for the old Forrest skins system and one for the upcoming themes system. The theme is more complete and, is without a doubt, easier to customise. But it is also using code that is less mature (it is unlikely to be in the next Forrest release). This prompts two questions: 1) Should I create an instance in the Forrest Zone that builds the 2.2 docs using this new ASF theme so that it can be used as a base for a new Cocoon theme. 2) are there any web designers here willing to work on the skin (you don't need to learn how to get it into Forrest at first, just provide CSS patches and I'll integrate with Forrest for you - you'll quickly see how it is done) NOTE: since this uses in development code it is likely that the build will break on occasion. I doubt this is a problem for 2.2 docs, but if it is a concern we can use the existing skinning system rather than the dispatcher. Personally I would prefer to use the dispatcher as it is easier to customise and will provide useful feedback for the Forrest devs. It is likely the dispatcher will be ready for release at around the same time as Cocoon 2.2 (I'm not sure how can I possibly know that in Open Source projects though) Ross
Re: Getting response in any particular format required by client
Upayavira wrote: Sumit wrote: Hi All, I have one issue i.e. while developing a dynamic web page i want the response in any particular format required by user, it can be in PDF, TXT, DOC, HTML, ... You should ask this question on the user list. It is a better place for such a question. And the short answer is "yes, Cocoon can help with that." The slightly longer answer is Apache Forrest [1] is a Cocoon app that already does it. See you on the Cocoon and/or Forrest user list ;-) Ross [1] http://forrest.apache.org
Re: How to resolve relative "external" sources?
Geert Josten wrote: You could use input-modules to convert a relative path to an absolute one. It should be possible with the realpath input module for instance. The locationmap in Forrest is an input module that can be used to do this, and much more. Docs at http://forrest.apache.org/docs_0_80/locationmap.html Code at http://svn.apache.org/repos/asf/forrest/trunk/main/java/org/apache/forrest/locationmap/ Ross
Re: [VOTE] Stable CForms
Vadim Gritsenko wrote: [ ] +1, Let's do it! [ ] 0, What is CForms? [ ] -1, It's not stable, because... +1 - been stable for a long time as far as I am concerned ;-) Ross
Re: Editing Daisy docs. was Block deployment: working with blocks from a user's point of view
Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jan 2006, Reinhard Poetz wrote: [1] http://cocoon.zones.apache.org/daisy/documentation/g2/796.html [2] http://cocoon.zones.apache.org/daisy/documentation/g2/797.html If I want to edit those Daisy docs above I probably need additional permission. Can some of the more knowledgable people point me to how to achieve this or give me the needed permissions to become an editor: My login id is 'giacomo'. Done - you are now an editor and committer on docs. Ross
Re: [2.2] Remove documentation
David Crossley wrote: Reinhard Poetz wrote: Carsten Ziegeler wrote: We still have the docs under src/documentation and an addition svn:external in the portals block. I'm not sure why we need these files as our docs are now in the daisy repo. So can we either remove them or - if they are still needed - move out of the trunk to some other place to clean up trunk? I think they are not needed any more. These files were added before we switched to Daisy CMS. By the way Reinhard. Thanks for that big effort with the Cocoon-2.2 docs. If people want to see it one last time, then the Forrest zone has been building them. http://forrest.zones.apache.org/ We will remove those forrestbot jobs soon. If it helps I could set up a Forrestbot to generate the 2.2 docs from Daisy. If we leave the last forrestbot build from SVN online it will (I guess) help with checking content is synchronised. Ross
Re: W3C XML Processing working group
Gianugo Rabellino wrote: On 12/30/05, Sylvain Wallez <[EMAIL PROTECTED]> wrote: Hi all, The W3C recently set up an "XML Processing working group"[1] whose primary goal is to define an XML processing language (i.e. pipelines). ... My impression is that what this WG will end up defining yet another programming language in XML, and that this language will either be very limited in the processing types it allows in order to be implemented on a wide range of platforms (including browsers), or allow a lot of extensibility, thus actually limiting its portability. I'm not so sure. Although I have only read the minutes of their Dec 15th and 22nd meetings. A couple of things strike me: "Scripting language has two parts: having a way to specify a sequence of processes and to talk about what form the data is in as it passes through the process. It would be nice if we could do the former without constraining the latter" Here the words "scripting language" would make one think of a programming language, but replace those two words with "pattern language" or "template language" and it may become more "acceptable". At least to me, since that's why my work focused. Another interesting quote is: "If you had a registry, you could identify small names for the processes that do things, like registering "XSLT" for the XSLT 1.0 process" This seems to support my interpretation of the first quote. The language is describing a set of processes that can be used to move from one state to another. By having a hierarchy of processes, each defined by patterns, you can do something like: "User: give me document X" "App: I have document A, B and C, but need X. Engine: how do I create X from A, B and C" "Engine: apply process 1 to docs B and E. You can create E by applying process 2 to A and C" "App: Program execution is: (A, C) -> 2 = E (B, E) -> 1 = X" "User: Thank you" With respect to portability limitations, there need not be any, just imagine the processes run remotely (yes that introduces a whole load of other problems, but that is not for this WG). Such an approach does make it possible to create a high level "language" that need not define any complex logic through conditional execution since it is implicit rather than explicit. I have working prototypes of such systems (albeit academic proof of concepts). Of course, I'm interpreting just a few words by applying around five years of academic research and therefore have a very biased and blinkered interpretation at this time. It should be recognised that the Cocoon sitemap is surprisingly close to doing this already. This has not gone unnoticed by the WG: "they [Cocoon] have a simple one-level sequence path and I've got a more hierarchical model. Processing subtrees is like having embedded pipelines. That's hard to do in Cocoon because of their syntax." WDYT, should we join the party? I think Cocoon could gain much from this discussion, even if it does turn out to be another low level XML programming language (please no). It's piqued my interest but, I don't do anything in this area any more. Nevertheless, I've joined the public list, it would be nice to actually awaken some of those parts of my brain, maybe I'll find time to return to this work. Ross
Re: ForrestBot build for cocoon-docs FAILED
[EMAIL PROTECTED] wrote: Automated build for cocoon-docs FAILED ... [java] X [0] linkmap.html BROKEN: Connection refused This is because the daisy instance on the Cocoon Zone is down. Ross
Re: forrest and cocoon
Jorg Heymans wrote: Ross | David , Would you mind describing the dependency that forrest has on cocoon? Are you guys using branch or trunk? If the latter, how does the current M10N and a possible repository reorganisation affect you ? We are using a complied version of trunk. We are not using the latest SVN, we periodically update to a snapshot, which we build ourselves with a minimal set of blocks [2]. You can always find out which revision we are using by examining [1]. Since we package a binary version of Cocoon I doubt your reorganisation will have any affect. Ross [1] http://svn.apache.org/viewcvs.cgi/forrest/trunk/lib/core/cocoon-2.2.0-dev.jar?rev=355366&view=log [2] http://svn.apache.org/repos/asf/forrest/trunk/etc/cocoon_upgrade/README.txt
Re: Dists and Core blocks selection [Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Jorg Heymans wrote: Antonio Gallardo wrote: Also, please don't forget the ajax block. It is needed by forms. ;-) Is ajax really a block on it's own ? I mean i know it can be plugged into cforms to make forms ajax aware, but is it useable by other blocks as well ? I'm not really uptodate with this stuff, just curious whether it would make sense to move the ajax code to the cforms block. Or do we prefer to have separate release cycles for these two? -1 over at Forrest one of our devs is experimenting with the Ajax block. We have a demo in our forthcoming Dispatcher (aka views). Moving Ajax into the CForms block would prevent us from using it since we don't want to bundle CForms for fear of confusing the boundaries between Forrest (an XML publishing engine) and Cocoon (a web application framework). Ross
Re: New ASF members
Reinhard Poetz wrote: Sylvain Wallez wrote: Hi all, An ASF members meeting was held yesterday evening here in San Diego during which new members were voted in. Among the 33 new members, some are well known here: - Bruno Dumon - Antonio Gallardo - Ross Gardler - Reinhard Poetz - Jeremy Quinn Congratulations and a warm welcome to the new members! I'm surprised and honored and I have to say that I'm really proud that I was elected. Many thanks to all of you! I have to say, I am also "suprised and honored". Thank you for yet another vote of confidence from the ASF - somehow this kind of thing always feels better than a promotion ;-) Ross
Re: ForrestBot build for cocoon-docs FAILED
[EMAIL PROTECTED] wrote: Automated build for cocoon-docs FAILED Log attached. ... Copying broken links file to site root. [copy] Copying 1 file to /var/apache2/htdocs/ft/build/cocoon-docs [echo] Oops, something broke Looks like something in Forrest has broken. Since it is nothing to do with Cocoon I'm redirecting notifications to te Forrest list until this is sorted. Ross
Re: [Vision] Knowing When We are Done
Ross Gardler wrote: Sylvain Wallez wrote: Ross Gardler wrote: Now I'd better stop before I start convincing myself that people will find all 600 pages of my PhD interesting ;-) Any pointer for those that might be interested? This research is fairly old now (6 years), and things have moved on a little, although mostly in the wrong direction, as observed by others here (i.e. lets make highly configurable components and we'll never have to write code again). I have a couple of papers that might serve as a useful introduction: One covers the use of the XML Pipeline languages to define application templates [1], the other [2] introduces the design methodology that guides the selection of and development of components. This is probably way off topic from the perspective of Cocoon design discussion, but may be interesting nevertheless. I have much more detail in my thesis if anyone is interested in the really detailed stuff. Ross [1] http://citeseer.ist.psu.edu/cache/papers/cs/26837/http:zSzzSzwww.netobjectdays.orgzSznode02zSzdezSzConfzSzpublishzSz..zSz..zSz..zSz..zSzpdfzSz02zSzpaperszSznodezSz0110.pdf/supporting-component-based-software.pdf [2] I can't reproduce this one, but I will send you a copy of the presentation slides and notes offlist (others should ask if they want it) Sorry the [1] and [2] is the wrong way around here, but it is the right link (i.e. the link marked as [1] is actually [2]) Ross
Re: [Vision] Knowing When We are Done
Sylvain Wallez wrote: Ross Gardler wrote: Now I'd better stop before I start convincing myself that people will find all 600 pages of my PhD interesting ;-) Any pointer for those that might be interested? This research is fairly old now (6 years), and things have moved on a little, although mostly in the wrong direction, as observed by others here (i.e. lets make highly configurable components and we'll never have to write code again). I have a couple of papers that might serve as a useful introduction: One covers the use of the XML Pipeline languages to define application templates [1], the other [2] introduces the design methodology that guides the selection of and development of components. This is probably way off topic from the perspective of Cocoon design discussion, but may be interesting nevertheless. I have much more detail in my thesis if anyone is interested in the really detailed stuff. Ross [1] http://citeseer.ist.psu.edu/cache/papers/cs/26837/http:zSzzSzwww.netobjectdays.orgzSznode02zSzdezSzConfzSzpublishzSz..zSz..zSz..zSz..zSzpdfzSz02zSzpaperszSznodezSz0110.pdf/supporting-component-based-software.pdf [2] I can't reproduce this one, but I will send you a copy of the presentation slides and notes offlist (others should ask if they want it)
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
[X] Mix and match (not as simple, but is status quo with today) However, to be effective we need a core development effort, therefore the *official* support should be for a limited subset of what is in use today: Javascript + Java Ross
OT [Re: [Vision] Knowing When We are Done]
Ugo Cei wrote: Il giorno 07/dic/05, alle ore 11:43, Ross Gardler ha scritto: Most businesses are made up of common business processes. The odd one will be unique to that business, but most are common. In the case of the unique practices the software needs to be customised, but in the case of common practices an "off-the-shelf" solution is sufficient. Sorry but I don't believe this dream of high-level, off-the-shelf, customizable components will ever come to fruition, Cocoon or not. On this point, I agree with Dan Creswell [1]: "All attempts at creating high-level business components that can be re-used and re-configured have failed previously. This failure has not been for technical reasons - it happens because the requirements that yielded the original component interface were sufficiently different from the new requirements so as to require re-writing massive chunks of functionality." And David Heinemeier Hansson as well [2]: "On the surface, the dream of components sounds great and cursory overviews of new projects also appear to be "a perfect fit". But they never are. Reuse is hard. Parameterized reuse is even harder. And in the end, you're left with all the complexity of a swiss army knife that does everything for no one at great cost and pain." Off Topic now, but I can't resist... I agree with both of these quotes 100%. In fact, my academic blue sky work, in my "previous life", addressed *exactly* the problems identified within the above quotes. It's all to do with the size of the component base (not the ease of configurability), the ability to identify "good enough" components and the ease of building a custom component when there is no suitable off-the-shelf component. That's why Cocoon can be applied succesfully in this area, it has the potential to be a very powerful web platform. Therefore, for now, I agree that to be useful Cocoon has to be an easy to use web-development framework. Without that, there is no point in me carrying on - so I won't (yet) Ross [1]: http://jroller.com/page/dancres/20050218#soa_doomed [2]: http://www.loudthinking.com/arc/000407.html
Re: [Vision] Knowing When We are Done
Mats Norén wrote: Ross Gardler wrote: Bertrand Delacretaz wrote: Le 7 déc. 05, à 09:10, Ross Gardler a écrit : ...I envision being able to build a Cocoon application by saying "given these input types, I want this output type" and to have the resulting application automatically tested against my test inputs... Not sure if I understand what you mean, could you give an example? Most businesses are made up of common business processes. The odd one will be unique to that business, but most are common. In the case of the unique practices the software needs to be customised, but in the case of common practices an "off-the-shelf" solution is sufficient. Each common practice has a set of inputs, a set of intermediate states and a set of outputs. If the new Cocoon provides a series of components for transforming from an input to an ouput we can use these components to build complete applications. Here's a simple example: Inputs: - purchase order Intermediate Docs: - customer details - credit approval - stock level Required outputs: - Invoice - Packing slip It is possible to describe this process as a series of components, i.e. to get from a "purchase order" document to a "customer details" document use component ABC, to get from a "purchase order" to a "credit approcal" use component XYZ etc. It is possible to automate the discovery of these components and thus to automatically configure an application to move from document A to document B. This seem a lot like the concepts of an ESB, someone mentioned ServiceMix [www.servicemix.org] in a recent thread. It's an interesting vision but is Cocoon NG really going to compete in that arena? See Daniels recent mail about wanting Cocoon to be a set of components that can be used in any context, guided by patterns. That's *exactly* what I'm talking about. When I was first drawn to Cocoon it was a much simpler beast, it was still an XML processing framework. We all know what has happened since, it's been said many times in this and related threads. However, when Cocoon was nothing more than a sitemap defining XML processing pipelines it was a small step away from being eveything any "ESB" today claims to be. "ESB" is only a buzzword, this stuff has been around for many years. Now I'd better stop before I start convincing myself that people will find all 600 pages of my PhD interesting ;-) I'll return to this one day when the vision is settled and in place, and I have the time to express it in a reasonably concise RT. Ross
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Berin Loritsch wrote: Ralph Goers wrote: None of these. I have a vision where the business services are implemented in Java, the web application is defined in a stateful flow controller (xml config) and the views are generated using pipelines with standard components. So my answer is - No programming language on the server, just configuration. This is what I was getting at with my wish to see apps defined in terms of "given this type of input I want this type of output". Shudder. That could be a nice add on to Cocoon. Perhaps a BPL (Business Process Language, an XML standard for what you are talking about) application. In my prototype of such a system I evaluated all the BPL's of the time (and have since updated this again). I rejected them all as being far too complex, verbose and too much like a full blown programming language. What I ended up using was XML Pipelines, a very simple language that covers far more of the required workflows than any of the specific BPL's Why is this relevant here? You would be amazed at how many similarities there are between the solution I developed and Cocoon (that's why I was drawn to Cocoon in the first place). I would argue that what you are talking about is a domain specific language in the guise of configuration (just like your hibernate descriptors and ant scripts). Sometimes, DSL's bring many benefits, just consider the sitemap. Do we want to know more or is this a step too far at this stage of discussion? I'm aware that t could go off on a horrible tangent and we'll never find the real vision, it may be better for me to bring this up again at a more appropriate time, after all its an implementation detail. Ross
Re: [Vision] Knowing When We are Done
Bertrand Delacretaz wrote: Le 7 déc. 05, à 09:10, Ross Gardler a écrit : ...I envision being able to build a Cocoon application by saying "given these input types, I want this output type" and to have the resulting application automatically tested against my test inputs... Not sure if I understand what you mean, could you give an example? Most businesses are made up of common business processes. The odd one will be unique to that business, but most are common. In the case of the unique practices the software needs to be customised, but in the case of common practices an "off-the-shelf" solution is sufficient. Each common practice has a set of inputs, a set of intermediate states and a set of outputs. If the new Cocoon provides a series of components for transforming from an input to an ouput we can use these components to build complete applications. Here's a simple example: Inputs: - purchase order Intermediate Docs: - customer details - credit approval - stock level Required outputs: - Invoice - Packing slip It is possible to describe this process as a series of components, i.e. to get from a "purchase order" document to a "customer details" document use component ABC, to get from a "purchase order" to a "credit approcal" use component XYZ etc. It is possible to automate the discovery of these components and thus to automatically configure an application to move from document A to document B. This latter part is, of course very complex and hard to do. I have a prototype, written for my PhD about 4 years ago, it's not Cocoon based, but has many parallels with both Cocoon and recent discussions regarding making Cocoon much easier to use (some info at http://www.saafe.org) I'm not suggesting we tackle this latter part today. But as part of the long term vision it may be interesting. Ross
Re: [Vision] Knowing When We are Done
Sylvain Wallez wrote: Berin Loritsch wrote: In all the talks of redesign or not, there has been a recurring question as to the vision. Sylvain has outlined some things that he would like to see, but they really don't constitute a vision. They are a nice list of improvements, but they aren't a vision. In my experience the best visions really don't have to do with features and improvements, but with what we expect to be able to do with Cocoon. We need to be able to put our vision statement in one or two paragraphs, and it needs to convey a little more than technology. Visions contain emotional content as well. There are two kinds of visions. One is the kind that you use to attract users, "Oh, that's what I need and they approach things the way I expect". That's the kind that ends up on the front page. Then there's the kind of vision that explains how you think something should be done. Kind of like a how-to that describes what _should_ be instead of what is the case. It has to be something exciting, something that people can get behind. Now, whether we are talking about evolutionary change or revolutionary change, we need to have a common vision. How else will we ensure the transition goes as smoothly as possible? Good foundational principles of modern software development are just side issues. Let's take a look at what we want Cocoon to be. Below is my vision, which I hope starts discussion. We can start consolditing the common points once people post their visions. Let's gather the information, and then see if we can look at some commonalities and think a little outside the box to make as many of us happy as is practical. Berin's Vision I envision a Cocoon which takes its principle strengths in separation of concerns to make developing web applications easier. Modern web applications provide machine-to-machine communications via web services and email as well as various views into the data. I envision a Cocoon that makes Java look attractive again, proving that it is suited for the rapidly changing web environment. I envision a Cocoon which avoids configuration where it is unnecessary, and instead employs easy to understand conventions. I envision a Cocon that is able to be extended using standard Java mechanisms such as the JAR services approach. I envision a Cocoon where I only have to learn Java and XML to be affective. I see a Cocoon where testing is embraced, encouraged, and made easy. I see a Cocoon where any errors/exceptions tell me exactly where the problem lies, down to the source code line--even if that source is not Java code. I see a Cocoon where the Sitemap is not the preferred way to map URLs to generating content. I see a cocoon where convention dictates the pipeline. A note about blocks: while they *can* be helpful, they are not central to my vision. I am open to them, and if they are a part of Cocoon's future then the following applies: "I see a cocoon where communities can share solutions packaged up in blocks to be reused in other applications". I'm thinking solutions like user authentication, portal support, or other generic solutions. - That's my vision. What's yours? How much overlap is there? Let's start this discussion, I think we will be pleasantly surprised how close many of us are with where we want Cocoon to go. Oh yes, we are close. To all the above, add the following: I envision a Cocoon where I can use the power of the pipeline engine in almost every environment where there is some XML data to be processed. I envision a Cocoon where people can use a single unified scripting language for both the client and the server. I envision a Cocoon where the expression used to access a given data is the same everywhere. I envision a Cocoon where any change to a source file, even Java, is instantly reflected in my application. Whilst I agree with everything above I feel they are too focused on the developer side of things. Here are a couple of additions from the perspective of the end user: I envision a transparent integration of remote resources. I envision a transparent integration of dynamic and static resources. I envision being able to build a Cocoon application by saying "given these input types, I want this output type" and to have the resulting application automatically tested against my test inputs. Ross
Re: [Docs] Articles on Cocoon - reminder
hepabolu wrote: Reinhard Poetz wrote: Bertrand Delacretaz wrote: Maybe we could use the private committer's SVN area to coordinate and review stuff once we start writing, not to hide it from our "public" community but to respect the (assumed) magazine's desire for keeping things private before publication. Other suggestion, use Daisy: Create a separate "cocoon-articles" site and collection add a rule that only doc-committers can read/write them. This sounds good. I think it's a good idea to do a community review and I have already thought about how to keep the articles "hidden", but failed to come up with something useful. I just wonder if it is possible to keep the site "invisible", i.e. it is only available through a URL, not through any link on the Daisy site. Just to avoid any questions and hack attempts (I know security by obscurity). When a user arrives at the Daisy site they can only see the sites they have the rights to access. So if you add a rule saying onlyy doc-committers can see the site it will be hiddenf rom everyone else. Ross
Re: author tags (Was: Planning 2.2)
David Crossley wrote: Ross Gardler wrote: David Crossley wrote: Joerg Heinicke wrote: Antonio Fiol Bonn?n wrote: This can't possibly be what we need, as anyone would have done it faster than me, but anyway, here it goes. IIRC the problem was not the pure removal, but the mentioning of the authors in a contrib file file. Exactly. If it was an easy job, then we would have done it by now. There is discussion in the archives about how the attribution should be done. One suggestion was adding to the status.xml file so that they get listed at the changes.html page. Another suggestion was a "contrib" type file. Status.xml already supports authors: id="SM" /> id="SR" /> It's a small job to modify the Forrest projectInfo plugin to render these in changes or any other location. That is not what i was referring to. Rather i meant the attribute due-to="Donald Duck". The contributor is not always a committer. It is just a matter of making sure that there is an entry for each major contribution. OK, I've added the required features to the projectInfo plugin in Forrest: - add a contributor list to each release (derived from @due-to) - add a committer list to the end of changes.html Both of these sections can be turned on or off as required, so if you want to use the developer list and the @due-to attribute in status.xml go ahead. The Forrest zone version of the docs are showing the new build. I've also added a previously requested feature for Cocoon: control the sort order of issues, in the cocoon docs they are no longer sorted. Ross
Re: author tags (Was: Planning 2.2)
David Crossley wrote: Joerg Heinicke wrote: Antonio Fiol Bonn?n wrote: This can't possibly be what we need, as anyone would have done it faster than me, but anyway, here it goes. IIRC the problem was not the pure removal, but the mentioning of the authors in a contrib file file. Exactly. If it was an easy job, then we would have done it by now. There is discussion in the archives about how the attribution should be done. One suggestion was adding to the status.xml file so that they get listed at the changes.html page. Another suggestion was a "contrib" type file. Status.xml already supports authors: id="SM" /> id="SR" /> It's a small job to modify the Forrest projectInfo plugin to render these in changes or any other location. I want to do a little work on that plugin anyway so that the sorting of actions can be turned off (i.e. display them chronologically), I can do this at the same time. Ross
Re: Updating the website
Carsten Ziegeler wrote: The changes list is not current; although it contains the entry for 2.1.9, many entries for 2.1.8 are missing. It should be generated directly from the status.xml file in SVN so I don't understand how any can be missing. Please give an example of a missing item so I can investigate (a quick glance over from me revealed none). Ross
Re: Updating the website
Upayavira wrote: Carsten Ziegeler wrote: The release is built and I'll announce everything tomorrow. This means we should update the website (and docs) tomorrow as well. Can someone please do this? A request, from a marketing perspective. Could we write a special announcement for this that says more 'personally' what has changed, rather than using the same release announcement as last time? If necessary, I'd happily write it (basically a manual conversion of notable parts of status.xml into a paragraph or two of readable English). For future reference (or possibly this one depending on the inclination of whoever does this)... A new feature of the projectInfo plugin in Forrest is that a more personal release notice can be written "as you go" during development. It works by including narrative release notes in the status.xml file and by marking up some of the actions as being "important", i.e. ones that should be highlighted on the announcement document. The actions that are "important" are then filtered and sorted according to the type of action they are (code, docs etc.) and shown in the special release notes page. You can then use the forrest output plugins to provide the release notice in whatever format you need (i.e. HTML for the web page, Text for email, PDF for press releases etc.) It is also now possible to use full xdoc within the action descriptions. This means you can insert images, links etc. Therefore, it is now easy to produce "new and notable" documents like the excellent ones produced for Eclipse [1]. THe hard part is insisting that people place minimal documentation for new features in status.xml rather than a one line description. If this is done the resulting doc acts as useful form of documentation for those upgrading, and provides a starting point for real documentation for new features. For an example of how to markup the document see the forrest status.xml [2] (note the categories are user definable so you could have a category for blocks, core etc.) Ross [1] http://download.eclipse.org/eclipse/downloads/drops/S-3.2M3-200511021600/eclipse-news-M3.html [2] http://svn.apache.org/viewcvs.cgi/forrest/trunk/site-author/status.xml?view=markup
Docs available in my zone account
You can get the most recent build of the 2.1.8 docs from my cocoon zone home (~rgardler), filename docs-2.1.8.tar.gz I'm away from a net connection for most of the day. If there are any problems ask one of the Forrest devs to help out by retrieving the docs from the Forrest Zone. I'll check my mail at the earliest opportunity. NOTE Helma reports there are still some incorrect paths due to the Daisy navigation differences. They need to be handled with .htaccess Ross
Re: ForrestBot build for cocoon-docs FAILED
[EMAIL PROTECTED] wrote: Automated build for cocoon-docs FAILED Log attached. don't worry about that one, I was doing a test build and the cron job to update forrest occurred during the build. I've done another one since. Ross
Is status.xml up to date?
I promised to create a tarball of the docs for release, but I can't do that until the status.xml file has been verified as being complete and the release date has been entered into it. Can people please give it a look over. We generate from the version in SVN so just update SVN as appropriate (at the very least someone needs to put the release date in there). If anyone can be bothered there are a load of new features for the changes document. Such as the generation of release notes: http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.input.projectInfo/releaseNotes_0.1.html In order to generate a doc like this you need to add some markup to status.xml, so it is probably better to do it for the next release rather than this. Let me know when this is done and I will generate the docs for you. I can do them late tonight (GMT) or early tomorrow (Thurs, GMT) Ross
Re: ForrestBot build for cocoon-docs FAILED
hepabolu wrote: Ross Gardler wrote: I suppose this is due to my changing of the navigation document in Daisy, so I suppose Ross needs to fix the Forrest side of things. There should be nothing needs doing on the Forrest side, but obviously something is wrong somewhere ;-) I'm investigating right now. just tell me gently if I messed up seriously. ;-) :-)) No, it was on the Forrest end as you suspected. Ross
Re: ForrestBot build for cocoon-docs FAILED
hepabolu wrote: [EMAIL PROTECTED] wrote: Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 16 November 08:16 AM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- I suppose this is due to my changing of the navigation document in Daisy, so I suppose Ross needs to fix the Forrest side of things. There should be nothing needs doing on the Forrest side, but obviously something is wrong somewhere ;-) I'm investigating right now. Ross
Re: Status of docs/Releasing? - Vadim heads up
hepabolu wrote: Ross Gardler wrote: Vadims diff should be helpful, I can't find it in the archives right now, but it was posted late last week. Just had a look, but I can't figure out what has yet to be done. Vadim could you run the diff one more time please? Vadim, here is the latest docs list from the forrest zone: http://forrest.zones.apache.org/ft/build/cocoon-docs/docslist.txt Ross
Re: Status of docs/Releasing?
hepabolu wrote: Ross Gardler wrote: Carsten Ziegeler wrote: Hmm, so it seems that we can release on thursday (I hope). Can someone please provide me an archive (zip/tgz) of the docs (e.g. on our zone) that I can put in our download section? I will be able to do that (including changes.html) tomorrow (wednesday) as long as someone else can find the time to make any final modifications to the Daisy nav document to solve the URL space issues. Assuming they have not been done already that is. I'll do it if someone tells me what to do. I'm going to do the forms part now, and leave it at that, until someone posts more. Basically any node in the daisy navigation that does not have a correcsponing element in the UrlSpace at http://cocoon.apache.org/2.1 needs to be an import like you did with the documentation nodes. etc. Vadims diff should be helpful, I can't find it in the archives right now, but it was posted late last week. There will be some that have only a couple of pages in, it's your choice what is sensible to do like this and what is sensible to do with .htaccess (or lose the low level grouping where appropriate as you suggested with the two deeply nested binding docs in forms). Ross
Re: Status of docs/Releasing?
Carsten Ziegeler wrote: Hmm, so it seems that we can release on thursday (I hope). Can someone please provide me an archive (zip/tgz) of the docs (e.g. on our zone) that I can put in our download section? I will be able to do that (including changes.html) tomorrow (wednesday) as long as someone else can find the time to make any final modifications to the Daisy nav document to solve the URL space issues. Assuming they have not been done already that is. Ross
Re: [DOCS] Building for release - update round 2
David Crossley wrote: Ross Gardler wrote: ... * Extra URI segments: Some of these are a result of the lack of a clean build space (i.e. about/), but others are the same problem with the daisy navigation, for example, the extra dirs under /userdocs/forms/ Helma did warns us that there were other places the URLspace had been changed in Daisy, I was hoping it would be less widespread than this though :-( I'm looking into it. What is the status of this? Did you produce a new list for Vadim, or someone else, to verify? I've been inundated with work lately and have been unable to do anything about this. It can be solved by the same method as the previous extra info in the URL space, however, in some places this will result in navigation docs that are too fragmented on Daisy. The other options are for us to put in the code to support extra nodes in the Daisy to allow "Title" nodes that do not have a corresponding URL entry. Bruno suggested this on the Daisy list so he is receptive to the idea, problem is finding the time to do it, I have no idea how easy/hard it is (Bruno said it would be fairly easy, but then Bruno knows Daisy code inside out ;-) .htaccess is a quick and dirty solution to get the release out. Butchering the Daisy nav docs will work, is quick and easy and can be reverted in 2.2 release. I'm afraid I am unlikely to get any real time on this until much later this week (possibly as late as Friday). So it's up to you folk. Ross Ross
Re: Status of docs/Releasing?
Bertrand Delacretaz wrote: Le 14 nov. 05, à 10:09, hepabolu a écrit : ...From my POV there are no or only minor issues in the docs. Let's see what the others have to say... IMHO the only critical thing is to have these pages updated when the release is done: http://cocoon.apache.org/2.1/changes.html David and I did some work on this during our Forrest Friday last week. We both have a version of the Daisy plugin that will produce changes.html from the status.xml file alongside the daisy docs. So all you need to do is make sure that status.xml is up to date. I can't release the plugin with this hack as it breaks other users sites. I know what I need to do to make it releasable though. If I don't get the opportunity to release before the end of the week I will generate the docs on my local machine for the release - they will be identical to those on the Forrest Zone, but with the inclusion of changes.html. http://cocoon.apache.org/news/ Probably best to get this into Daisy, since a news page should be fairly frequently updated. Ross
Re: Status of docs/Releasing?
hepabolu wrote: Carsten Ziegeler wrote: What is the status of the 2.1.8 docs? I would like to release 2.1.8 by the end of this week. If there are only minor issues, we could perhaps use the docs as of now and then perhaps release a docs update some weeks later? From my POV there are no or only minor issues in the docs. Let's see what the others have to say. I agree (see my other mail in the docs thread). There are a few extra parts in some fairly deeply nested paths. I offered a number of solutions for these elsewhere, in summary (in order of my personal preference): 1) add .htaccess rules to make sure 2) modify daisy navigation in same way as we did for higher level paths 3) modify Daisy to allow a Title node in the navigation (I'd like to see this for future docs, but is unlikely to happen in time for this release) Ross
Re: TOCs in documentation (Re: [DOCS] Building for release - update round 2)
David Crossley wrote: Ross Gardler wrote: Vadim Gritsenko wrote: Ross Gardler wrote: Vadim Gritsenko wrote: Forgot to add... Can we loose page toc which now appears within left navigation bar? I'm not sure we should have it there, it certainly looks strange... It was moved there as a test, come people like it in the body, come in the page menu, some not at all. It is easy to move/remove (a setting in skinconf.xml in the daisy-to-docs module) - the question is where do we want it (or do we want to remove it). I am in "remove it completely" camp... On the Cocoon site, I am too, lets leave it for a while with the new subject line and see if anyone objects to us removing it completely. As i said earlier in this thread, i prefer the ToC in the top of the page body (probably listing only one level). I definitely do not like it in the side-panel menu. But really i don't care if others want it gone completely. I'' remove it completely. Some others have stated that they don't like it in the top. Ross
Re: [DOCS] Building for release - update round 2
hepabolu wrote: David Crossley wrote: There are a number of places in the source documents with the token "@released.version@", e.g. http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/index.html I'll see to this. I don't know how big a job this is. But if it is still worthwhile the Daisy plugin allows for Daisy documents to be pre and post filtered through and XSL. We can therefore automatically replace these tokens if you want to. Ross
Re: [DOCS] Building for release - update round 2
Vadim Gritsenko wrote: Ross Gardler wrote: I just sent it offlist, but I sent it from the zone, not sure if mail is set up correctly there. If you don't recieive it you can get it at http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/fileList.txt Got the mail ok. (note this is not regenerated when the site is rebuilt) .. Diff attached. Lots of differences, I'll sum up some of them here: Thanks for this Vadim, saves us lots of time - sorry it wasn't as encouraging as I thought. * Duplicates: See example above. Was it simply because output directory was not cleared up between forrest runs? Yes, that is the problem, as David identified. I'm discussing with David as to whether the Forrestbot should always clear out its build directory on a new run (I thought it did). * Extra URI segments: Some of these are a result of the lack of a clean build space (i.e. about/), but others are the same problem with the daisy navigation, for example, the extra dirs under /userdocs/forms/ Helma did warns us that there were other places the URLspace had been changed in Daisy, I was hoping it would be less widespread than this though :-( I'm looking into it. Ross
TOCs in documentation (Re: [DOCS] Building for release - update round 2)
Vadim Gritsenko wrote: Ross Gardler wrote: Vadim Gritsenko wrote: Forgot to add... Can we loose page toc which now appears within left navigation bar? I'm not sure we should have it there, it certainly looks strange... It was moved there as a test, come people like it in the body, come in the page menu, some not at all. It is easy to move/remove (a setting in skinconf.xml in the daisy-to-docs module) - the question is where do we want it (or do we want to remove it). I am in "remove it completely" camp... On the Cocoon site, I am too, lets leave it for a while with the new subject line and see if anyone objects to us removing it completely. Ross
