Re: Forrest Friday -10 March - Reminder/Topic Solicitation
On Thursday 09 March 2006 8:55 am, Tim Williams wrote: > We're about 13 hours out now... > --tim should have started by now, no? Diwaker > > On 3/2/06, Tim Williams <[EMAIL PROTECTED]> wrote: > > Forrest Friday is rapidly approaching, little more than a week away now. > > > > http://forrest.apache.org/forrest-friday.html > > > > Mark your calendars. > > > > http://www.timeanddate.com/worldclock/fixedtime.html?year=2006&month=03&d > >ay=10&hour=6&min=0&sec=0 > > > > In the mean time, use this thread for topic discussion. Some topics > > to get the ball rolling: > > > > o) Finishing Locationmap > > o) Prioritize Issues for next release > > o) Maybe it's time to re-address XHTML2 and figure out what the tasks > > are. o) and last but not least... old faithful... JIRA Cleanup > > > > btw, should this also go to [EMAIL PROTECTED] > > > > Thanks, > > --tim -- Web/Blog/Gallery: http://floatingsun.net/blog On Apache: http://people.apache.org/~diwaker
#for-feb logs
http://casa.che-che.com/~bot/forrest/forrest.log.10Feb2006 http://svn.apache.org/repos/asf/forrest/events/forrest-friday/20060210-log.txt Just in case someone was late. -- Web/Blog/Gallery: http://floatingsun.net/blog On Apache: http://people.apache.org/~diwaker
Re: Dispatcher rc1
On Thursday 02 February 2006 10:21 am, Thorsten Scherler wrote: > Please try with a the blank, fresh-site, ... then you see the full > power. The first thing I could notice was the speed of rendering. Both in static and dynamic modes, I think there's a *significant* speedup. This is great! Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker
Re: Dispatcher rc1
On Thursday 02 February 2006 10:21 am, Thorsten Scherler wrote: > > I just tested it (with seed-v3) and it seems to work just fine for me. > > Hmm, I have to remove v3 asap. The problem is that it was the testing > ground to develop dispatcher compatible contracts. Since they are all > still in there and further there is a project specific override of > *.html you are actually not really using the new plugins. ;-) > > Please try with a the blank, fresh-site, ... then you see the full > power. I tried with 'forrest seed' as well -- still works. :) > > Awesome work, Thorsten! > > > :) > > Thanks, I could not have done it without the support of this community > (special thanks to Cyriaque who ported nearly all contracts from v2 to > the new grammar and everyone that is helping testing now and giving > feedback). > > > Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker
Re: Dispatcher rc1
On Sunday 29 January 2006 3:16 pm, Thorsten Scherler wrote: > Please test the rc1. I just tested it (with seed-v3) and it seems to work just fine for me. Awesome work, Thorsten! Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker
Re: [jira] Updated: (FOR-617) Forrest DOAP file
On Tuesday 24 January 2006 4:09 pm, David Crossley wrote: > The new http://projects.apache.org/ is now > available. Forrest is not yet listed. > > Do we need to change our DOAP file [1] > or maybe transform into a different syntax? > [1] http://forrest.apache.org/doap.xml > > Will it still serve the existing purpose > or do we need to maintain two files? I had created the aforementioned file to facilitate indexing in O'Reilly's CodeZoo [2]. The current doap.xml is not really a DOAP file -- its actually an ATOM feed, that contains an embedded DOAP spec as an entry. My bad in not naming it appropriately. So what we need to do is: o create a proper DOAP file for Forrest. There's even a web-based form to help creating/updating it [3] o make sure the embedded DOAP in the Atom feed (rename the current doap.xml to atom.xml?) remains in sync with the actual DOAP. [2] http://codezoo.com [3] http://projects.apache.org/create.html Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpHNRIhVZwCU.pgp Description: PGP signature
Re: Forrest Friday - January 2006
A live log is available at: http://people.apache.org/~diwaker/for-j.log I'll post the stats after the day is over. On Thursday 12 January 2006 9:14 pm, David Crossley wrote: > 13 January starting at 06:00 Greenwich Mean Time. > See the calendar for your time zone. > http://forrest.apache.org/forrest-friday.html > > We will use conventional IRC. The main communication > medium is still the dev mailing list. > > The channel name is #for-j at irc.freenode.net > > The topic is: > Finish locationmap, clean up Jira, prioritise issues > for next release, more xhtml2 dev, Dispatcher +docs. > > So the start time is about 45 minutes away. > > -David -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpcT9O7kfFI7.pgp Description: PGP signature
Re: Forrest Friday - January 2006
On Wednesday 11 January 2006 4:24 pm, David Crossley wrote: > The same semi-automation of the log as last time. > If Diwaker or Cheche is around, then they might also > have a logger bot (the up-to-date logfile is good). I'm not sure how much time I will spend myself on IRC, but I'll definitely leave the bot running. I'm really sorry about not participating for a while now -- I was in India for a month and have just got back. I'm still swamped with work and still trying to catch up with all the unread mails on the dev/commit/user lists :( Just too much to page in! -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgp5hE4v5o5J2.pgp Description: PGP signature
Re: Forrest Friday
Unforunately I'm going to be offline for the next 3 weeks, so I won't be around for this ForrestFriday. Hopefully cheche will bring JennuCuran back to life. I'll catch up with the logs later. Good luck guys, and have a good christmas everyone! Diwaker On Monday 05 December 2005 1:32 pm, Tim Williams wrote: > I reckon the topic for this ForrestFriday should be discussed and set. > I also wanted to see if I'm the only one impacted by travel with > ApacheCon this weekend. I'll be traveling on Friday so won't be much > help again. If there's enough people in this situation I thought maybe > we could look at an alternate date? No problem if not, just thought > I'd ask. > > As for topics, I suppose with Thorsten's recent email, it appears it > might be a good time to take another whack at XHTML2 in core. > > Also, moving many JIRA issues to a 0.9 fix or later. > > --tim -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker
Re: Views
On Sunday 04 December 2005 9:08 pm, Paul Bolger wrote: > [views: .fv files] Is there a way to specify one .fv file for multiple > input files, or does every page need an individual file? Yes. If you search through the archives, you'll find several emails from Thorsten covering the resolving mechanism. I believe its something like this (this is not authoritative, but indicative): o for pagename.html, first check if pagename.fv exists o if not, look for themename.fv in the resources/themes directory o if not, use default.fv that ships with Forrest. In addition, I believe its possible to specify per directory view files as well. I'll try to find the appropriate thread and post it here. But do search the archives, you'll find plenty of information. > [views:modify html classes] I'm trying to work out where css classes > are being inserted, specifically in content-main.ft, because I'd like > to modify local versions to skip a lot of the superfluous ones. Some css classes are generated by the contracts themselves. Others are generated by forrest:hook in view files. Views tries to do everything using CSS, so it should be easy to structure your CSS around views. > [views: no css] Is there a way, yet, to set views to produce no css at > all? I notice there was some discussion about this a few months ago, > but couldn't find any reference to it happening. I'm not sure I understand. You can choose to use no css if you so wish -- views doesn't impose any CSS on you. It generates divs with CSS class, but if your theme doesn't import any CSS or doesn't specify any extra-css, then you'll get a site with no CSS. > [indent html] Where would one put the indent="yes" attribute to get > Forrest to output indented html? I'm unable to recall any such attribute in views right now. It _is_ possible to use JTidy to indent the generated HTML -- but the last time I tried it, I ran into some problems. More details on this later. For now, I'd say you are better off just running tidy on your own, after Forrest is done generated the HTML. > [views: naming] I'm confused! Themer, v2, structurer, views, > dispatcher - are these all the same thing? Views are still evolving, and there have been several iterations/discussions over naming. I admit it can be confusing at first. IIUC, the official name for the whole framework is Dispatcher (aka v2). Views was the first implementation. Structurer is one component of the dispatcher framework :) > [apache copyright] Finally, and this is probably heresy, is it really > necessary for all the config files to have a whole screen of Apache > copyright/disclaimer info at the top? Can't it be one line at the top > and more at the bottom? The config files that ship with the distro have the copyright notice. I don't think (IANAL, so please correct me if I'm wrong) you need to have that copyright notice in any config files that you write yourself. Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker
Re: genericMarkup contract
On Friday 25 November 2005 9:13 pm, Ross Gardler wrote: > Diwaker Gupta wrote: > > I'm using the genericMarkup contract, and was wondering if it could be > > simplified. In particular (and I copy this from index.fv in seed-v2), > > lets say I want to insert a somewhere in my template. For that, I > > need this XML snippet: > > > > > > > > > > > > > > > > > > I find that way too verbose, and confusing. Why is sitting in a > > property? > > If it weren't in a property it would have to be in XSL, which would be > more verbose wouldn't it? I'm not sure I follow. How is a in a forrest:property any different from directly under a forrest:contract? Perhaps I'm missing something really obvious here, but why can't we simply copy over everything between the contract tags (for the genericMarkup contract) verbatim (as CDATA, for instance) over into the output? > > And while I was looking at it, I had another question: since > > is a child element of a , why do > > we need that contract attribute? > > It's gone in the planned POJO version I think (see above). Thorsten will > correct me if my understanding is incorrect. POJO? :/ :) Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker
genericMarkup contract
Hi devs, Thorsten I'm using the genericMarkup contract, and was wondering if it could be simplified. In particular (and I copy this from index.fv in seed-v2), lets say I want to insert a somewhere in my template. For that, I need this XML snippet: I find that way too verbose, and confusing. Why is sitting in a property? And while I was looking at it, I had another question: since is a child element of a , why do we need that contract attribute? Is it possible to ever have the value of the contract attribute be different than the name of the enclosing forrest:contract? Lets keep it simple! :-) Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker
[jira] Assigned: (FOR-230) forrestbot log workstages
[ http://issues.apache.org/jira/browse/FOR-230?page=all ] Diwaker Gupta reassigned FOR-230: - Assign To: Diwaker Gupta (was: Dave Brondsema) > forrestbot log workstages > - > > Key: FOR-230 > URL: http://issues.apache.org/jira/browse/FOR-230 > Project: Forrest > Type: New Feature > Components: Forrestbot > Reporter: Dave Brondsema > Assignee: Diwaker Gupta > > forrestbot should log all workstages, not just the site build. it should > also notify properly if a failure occurs in any workstage (e.g. cannot get > source) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FOR-392) deploy of deleted files
[ http://issues.apache.org/jira/browse/FOR-392?page=comments#action_12358450 ] Diwaker Gupta commented on FOR-392: --- I'm not sure if this is the "correct" behavior -- atleast I disagree. I don't want the deploy to EVER touch any existing files on a remote host. Yes, having a configurable option helps. Was there a feature request for this? Do users miss this feature? If not, I would close this issue. A specialized protocol like rsync is really the best of doing such a thing. And unless Forresbot has access to some rsync implementation, with the existing deploy targets (scp, ftp, with the exception of svn) this is probably non-trivial to implement. I'm not saying this is a reason not to pursue this, but just want to make sure we understand the cost-benefits of the issue. > deploy of deleted files > --- > > Key: FOR-392 > URL: http://issues.apache.org/jira/browse/FOR-392 > Project: Forrest > Type: Task > Components: Forrestbot > Versions: 0.7 > Reporter: Dave Brondsema > Priority: Minor > > Investigate what happens when you delete a file, and then deploy your site. > All deploy implementations should probably delete the remote file, if > possible. Maybe make it configurable whether it is to be deleted or not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (FOR-361) deploy.ftp workstage
[ http://issues.apache.org/jira/browse/FOR-361?page=all ] Diwaker Gupta resolved FOR-361: --- Fix Version: 0.8-dev Resolution: Fixed Assign To: Diwaker Gupta > deploy.ftp workstage > > > Key: FOR-361 > URL: http://issues.apache.org/jira/browse/FOR-361 > Project: Forrest > Type: New Feature > Components: Forrestbot > Versions: 0.7 > Reporter: Dave Brondsema > Assignee: Diwaker Gupta > Priority: Minor > Fix For: 0.8-dev > > create a deploy.ftp workstage for forrestbot -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FOR-361) deploy.ftp workstage
[ http://issues.apache.org/jira/browse/FOR-361?page=comments#action_12358449 ] Diwaker Gupta commented on FOR-361: --- I added the deploy.ftp target a long time back. I guess its safe to close this now? > deploy.ftp workstage > > > Key: FOR-361 > URL: http://issues.apache.org/jira/browse/FOR-361 > Project: Forrest > Type: New Feature > Components: Forrestbot > Versions: 0.7 > Reporter: Dave Brondsema > Priority: Minor > Fix For: 0.8-dev > > create a deploy.ftp workstage for forrestbot -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
upgrade fop?
http://marc.theaimsgroup.com/?l=fop-dev&m=113270183731548&w=2 Do we want to upgrade yet? Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker
Re: [Summary] Recent proposals around v2
This is not in SVN yet right? Just confirming, because I don't see anything yet... :) On Tuesday 22 November 2005 2:05 pm, Thorsten Scherler wrote: > Contract implementation > ^^^ > 1) contracts are now standalone, which means that they need to > match="/". Sorry I don't think I follow the terminology here :( By stand-alone, you are implicitly saying that earlier contracts depended on something else? I know this has something to do with moving processing over from XSLT to Java, but it'll be great if you can elaborate this a bit :) > a) If raw data (dataURI) is requested it matches the first element of > the dataURI. So a dataURI can contain multiple "elements"? What are these "elements"? Or did you mean to say that if there are multiple dataURI attributes, the value of the first one will be used? > b) If no dataURI is requested the dispatcher passes a dummy document to > the transformation containing only one element: forrest:foo. What does the Dispatcher do with forrest:foo then? Is this just an artefact of the implementation or something more fundamental? In other words, why can't I have the Dispatcher just use a null value if no dataURI is specified? Just being curious here, I have no problems with the way it is right now :) > The attribute @xpath determines that the elements within the content > container should be insert in a given location. In html for example some > function need to be inserted into the /html/head and/or /html/body. > > The location of the /html/body *normally* is defined through a > forrest:hook path (we called it structureAware="true"). So I propose > that IIUC, this bodes well for the architecture in general. Earlier we had some discussions on using the terms "head" and "body" in templates since they seemed to be specific to HTML. By using xpath expressions, we have removed this limitation completely! Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker
Re: [IMPORTANT] Licenses and SVN (Re: svn commit: r348114 - in /forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.input.Resume/src/documentation/content/xdocs: resume.xml site.xml)
On Tuesday 22 November 2005 2:04 pm, David Crossley wrote: > > >PS: do I need to add a license for this? I hope not. I mean we can > > > always create our own sample from this skeleton. This is just to get > > > things started. > > Even to "create our own sample from this skeleton" we would > need to retain the copyright notice in the document. > The file's license conditions are very explicit about that. alright, I'll just create my own from scratch (I have one "almost" ready, but it doesn't confirm to the DTD yet) > > I'm going to try and answer this, others will correct any mistakes I > > make - we never stop learning about this legal stuff. Thanks for the clarifications Ross, they certainly help! Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpzXGeX1EZCG.pgp Description: PGP signature
schema formats
I know David made some commits using RNG schemas earlier, but I'm not quite confident with them yet. Do we need to do anything special to use RNG schemas? How about XSD schemas? -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpiY9GbI0mXE.pgp Description: PGP signature
Re: CSS in Views 2
On Saturday 19 November 2005 3:10 pm, Ross Gardler wrote: > Where should my CSS go? I find it easiest to just create my own custom theme (it can inherit from pelt etc). Lets say you called your theme ross-theme (ingenious!): $ cd src/documentation $ mkdir -p resources/themes/ross-theme $ mkdir -p resources/themes/ross-theme/css $ mkdir -p resources/themes/ross-theme/html $ mkdir -p resources/themes/ross-theme/js Your custom fv can be put as resources/themes/ross-theme.fv Put the CSS in the css directory above and use it by just the filename (no prefix/full path required). If you don't to do create your own theme, I believe you should be able to create a tree structure with a theme name pelt and repeat the steps above. v2 will pull the CSS file from your project theme directory. -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgppGJKPbcz8I.pgp Description: PGP signature
Re: logger bot for ForrestFriday (Was: for-n stats)
> Thanks for doing this. The statistics don't seem to > mean much, probably because it is a small sample. I agree. > The log file is important. That needs to be a live > log file available on a webserver and using UTC time. This should be easily doable. I have a cron job that will periodically update the log file on a server. > I reckon that you should change the name of the bot. > Using the name "forrestbot" is not good. There was one > occasion where i needed to refer to the actual forresbot. > Your bot started talking to me. Hilariously funny, > but not good. > > Perhaps take over the excellent name that Cheche > had chosen: "JennyCurran". I'll call upon my creative juices and if I can't come up with anything on my own, then JennyCuran it will be :-) -- Web/Blog/Gallery: floatingsun.net
linkmap empty
I just checked now so I'm not sure when the problem originated, but if I do a fresh seed-v2 and navigate to localhost:/linkmap.html after 'forrest run', I get a mostly empty page. That is, the regular page structure is there, but there's no content. The problem persists with a normal forrest seed/seed-basic so the problem is deeper than v2. Any ideas? -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpAUVLnSQPUk.pgp Description: PGP signature
for-n stats
Just for kicks: http://people.apache.org/~diwaker/for-n.html I think I'll be much smoother in managing my bot and gathering log/stats next time :) (Tim and David should know what I'm talking about!) Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker
Resume input plugin
I believe this plugin was being developed by Ross? I've used xmlresume before (after some modifications to their DTD) and now that the project is effectively dead, I can't rely on their stylesheets any more. So I'm starting to poke around the Resume plugin. Right now if I do a 'forrest run' in the plugin directory, nothing useful really comes up. Ross do you have stuff lying around locally that you haven't committed yet? :-) Otherwise I'll try to throw in an example atleast and see what else needs to be done to make it better. cheerios, Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker
Re: Please TEST SVN head
> Can all devs please SVN up and build the sites you are most familiar > with and look for any problems. My own website seems to build fine. I'll test with some more plugins (text, pdf) shortly. -- Web/Blog/Gallery: floatingsun.net
Re: remove old views (Was: [jira] Commented: (FOR-697))
> Will veiews 1 sites work in views2 or is there some modification needed? > > (this is a general question, I am +1 on the removal) Automatically? No. With really little effort? Yes. I was running v1 on my website and now it runs v2. -- Web/Blog/Gallery: floatingsun.net
Re: svn commit: r332592 : please don't commit build directories
On Friday 11 November 2005 8:31 am, [EMAIL PROTECTED] wrote: > Author: ferdinand > Date: Fri Nov 11 08:26:33 2005 > New Revision: 332592 > > URL: http://svn.apache.org/viewcvs?rev=332592&view=rev > Log: > SmartSlides Input Plugin (work in progress). > > forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.input.smartSlide >s/build/ Bulk of this last batch of commits is the 'build' directory. It can always be built locally from sources, so should not be committed. -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpkdLGp55oTS.pgp Description: PGP signature
[jira] Resolved: (FOR-697) rename [format]2[format].xsl files
[ http://issues.apache.org/jira/browse/FOR-697?page=all ] Diwaker Gupta resolved FOR-697: --- Resolution: Fixed Works with v2 and regular "forrest seed". I haven't checked with v1 yet, but should work fine. > rename [format]2[format].xsl files > -- > > Key: FOR-697 > URL: http://issues.apache.org/jira/browse/FOR-697 > Project: Forrest > Type: Sub-task > Components: Locationmap > Reporter: Ross Gardler > Assignee: Diwaker Gupta > Fix For: 0.8-dev > > There were two ways of naming XSL files that converted files from one format > to another. Some were called [format]2[format].xsl, others were called > [format]to][format].xsl > In converting all sitemaps to the locationmap this has been standardised to > [format]2[format].xsl, which in retrospect is the wrong way around since some > formats have a version number, resulting in files such as docv102docv11.xsl, > which is rather confusing. These files should be standardised to > [format]to][format].xsl instead (or even [format]_to_][format].xsl for > clarity). > However, this is not an easy job until all sitemaps have been converted, > hence this sub-task -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (FOR-697) rename [format]2[format].xsl files
[ http://issues.apache.org/jira/browse/FOR-697?page=all ] Diwaker Gupta reassigned FOR-697: - Assign To: Diwaker Gupta > rename [format]2[format].xsl files > -- > > Key: FOR-697 > URL: http://issues.apache.org/jira/browse/FOR-697 > Project: Forrest > Type: Sub-task > Components: Locationmap > Reporter: Ross Gardler > Assignee: Diwaker Gupta > Fix For: 0.8-dev > > There were two ways of naming XSL files that converted files from one format > to another. Some were called [format]2[format].xsl, others were called > [format]to][format].xsl > In converting all sitemaps to the locationmap this has been standardised to > [format]2[format].xsl, which in retrospect is the wrong way around since some > formats have a version number, resulting in files such as docv102docv11.xsl, > which is rather confusing. These files should be standardised to > [format]to][format].xsl instead (or even [format]_to_][format].xsl for > clarity). > However, this is not an easy job until all sitemaps have been converted, > hence this sub-task -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: XSL duplication
On Wednesday 02 November 2005 2:33 am, Ross Gardler wrote: > All the XSLs were renamed from *2*.xsl to *-to-.xsl, but the original > *2*.xsl have been added back. We now have two version of very such XSL. > > The commit message said it was to make the old views work. What should > happen is that old views should use the new XSL names, not that we > duplicate the XSL. It should only be a search and replace, but since > this wasn't done I suspect there may be a reason for it. What was that > reason? Yeah, that was a quick hack to "make things work". > (alternatively old-views should be converted to use the locationmap then > the name of the XSL is irrelevant - again, should just be a search and > replace). +1 -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpA9rt3rBjqD.pgp Description: PGP signature
Re: playing with v2
On Tuesday 01 November 2005 6:04 am, Ross Gardler wrote: > > I started playing around with v2 today. After a little tweaking, I had my > > own skin working in v2. There will be a live deployment on my home page > > (floatingsun.net) sometime today or tomorrow :-) > > I look forward to that :-)) Just FYI: its online now on my homepage. The design remains the same, of course. A few things: o My main CSS stylesheet does an @import on another CSS stylesheet, that rightfully lives under themes/themename/css/ -- however, on a build, Forrest does not copy this CSS file. It only copies the files that are explicitly references in *.fv (atleast this is the behavior I'm seeing). IMHO the default behavior is the Forrest copies over everything under the css/ directory of the user. o Is there a reason why the PDF/XML links are provided via "cocoon://prepare.tiles.export-link" instead of the regular content-xml-link/content-pdf-link contracts in samples/index.fv under seed-v2? I think it makes the example slighly confusing. More later, v2 looks good Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpzCe4AbzKWk.pgp Description: PGP signature
playing with v2
Hi everyone, This mail is basically to tell people I'm not dead :-) I started playing around with v2 today. After a little tweaking, I had my own skin working in v2. There will be a live deployment on my home page (floatingsun.net) sometime today or tomorrow :-) I haven't looked at all the contracts yet, but a lot of them look very interesting. Specially all the ajax stuff, and the genericMarkup contract look very very useful to me. So great work Thorsten, Ross, Kevin, Gav, and everyone who's been involved! Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpkueHkN93Oa.pgp Description: PGP signature
devs in UK?
Hey everyone, I'm in Brighton till 26th for a conference. Anyone living around here? Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpgp6Chx9Jdq.pgp Description: PGP signature
Re: Static site updating of xml files
On Tuesday 18 October 2005 1:37 am, Ross Gardler wrote: > I *think* that the forrestbot uses the timestamp of the source file not > the generated file to detect when a cheange occured. Atleast the deploy.target that I used uses checksums. I think there's a flag to turn it on/off. -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker
Re: Static site updating of xml files
On Monday 17 October 2005 7:00 am, Gav wrote: > 1. Whenever a change is made to an xml file, for instance index.xml, I > again do > a 'forrest site' and upload the updated files. Now, all I have done is > made > minor changes to index.xml and not added/subtracted any links at all, > but > because of timestamping of files etc I find that my editor wants me to > upload all files, inlcuding images, because they have changed. If, in > the > future I make only minor changes to an .xml file, is there a better > way to > update this to produce the static .html equivelant ? > This is a known problem, and while there are some discussions on how to approach it, there is no good solution yet. Its late here so I'm lazy to dig around in the archives, but if you google, you'll find: o there have been some discussions on using Cocoon's checksum support to only build changed file o forrestbot has a FTP deploy target which supports uploading only files which differ in content than the uploaded ones. However, since the "Time published" string probably gets rewritten with different values, this is unlikely to help much with generated documents. But it should certainly avoid uploading the image files. -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker
Re: ForrestBot build for forrest-seed FAILED
On Sunday 09 October 2005 9:55 pm, [EMAIL PROTECTED] wrote: > Automated build for forrest-seed FAILED Hey everyone, I think the renaming of files broke something. I'm on it, just hang in there (or don't update just yet). Sorry abt that, Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker
Re: svn commit: r307241
On Saturday 08 October 2005 2:53 am, Ross Gardler wrote: > [EMAIL PROTECTED] wrote: > > Added: > > forrest/trunk/main/webapp/resources/stylesheets/lucene-search-to-xdoc.xsl > > When moving a resource please use "svn move path/to/resource", this adds > the now one and deletes the old on in one command, but more importantly > it keeps the history of the old file. Agreed. I just didn't want to do a move right away -- wanted to make sure things were working fine first. Anyways, the rename is underway now. -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker
[heads-up] stylesheet renaming
As discussed earlier (I can't seem to find the thread right now. If someone else does, please post in this thread), we thought it would be better to rename all transformation stylesheets to something like docv20-to-doc12.dtd rather than the somewhat (current) awkward docv202docv12.dtd. I'm beginning this right now. I should be done in a few hours. Just FYI. -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpZbgnXotpRO.pgp Description: PGP signature
Re: Changing the Day of Forrest Tuesday?
On Wednesday 05 October 2005 4:38 pm, David Crossley wrote: > I can do it anytime. Going from experience, i reckon > that option 3 will work best. Weekends are generally better for me (not that I've been participating heavily in the past tuesdays!) :) -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpC0A53v9VvK.pgp Description: PGP signature
Re: collaborative editing tools (Was: svn commit: r293179)
> We could create a howto for each tool: > Lenya, SubEthaEdit, Gobby, InkScape. SubEthaEdit is Mac only, and IIUC will remain so. Inkscape is a tool for creating SVG files. I'm not sure how useful that is to us. I think real time collaborative editors are complementary to Lenya et al. The "real time" part is what is important. In Lenya, I can't see in real time what others are doing with the document. In my head, Gobby and such are only meant for short, highly focused interactions and not much more than that. So if people have ideas for some document, they can write it up on Gobby and publish as usual through Lenya. Further edits etc would also go through Lenya. Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpuZs52bxNeo.pgp Description: PGP signature
Re: Collaborative editing with Gobby
We have an IRC channel #forrest-gobby open on Freenode if people need help with Gobby. On 10/2/05, Ross Gardler <[EMAIL PROTECTED]> wrote: > Ross Gardler wrote: > > OK, there are lots of people wanting to try. I'm going to just state a > > time I will be online and see how many people are able to join in. > > I've opened the session, and will have it open for the next hour. Mail > me privately for IP and password details. > > If you are behind a firewall ensure you open port 6522. > > If you have problems with connecting you can contact me via skype > (rgardler) or via email. > > I'll report back to the list on our opinion of the software. > > Ross > -- Web/Blog/Gallery: floatingsun.net
Re: [jira] Created: (FOR-697) rename [format]2[format].xsl files
> In converting all sitemaps to the locationmap this has been standardised to > [format]2[format].xsl, which in retrospect is the wrong way around since some > formats have a version number, resulting in files such as docv102docv11.xsl, > which is rather confusing. These files should be standardised to > [format]to][format].xsl instead (or even [format]_to_][format].xsl for > clarity). Yes, I think we should use some more characters for clarity in file names. Personally I prefer dashes over underscores -- they don't get lost in emails (some clients will convert underscores to underlines) and they are easier to type (one less key :D). So something like [format]-to-[format].xsl (eg: docv10-to-docv11.xsl) -- Web/Blog/Gallery: floatingsun.net
Re: locationmaps not working?
On Sunday 02 October 2005 3:46 am, Ross Gardler wrote: > Cool. Does this mean the issue you raised earlier in this thread about > the LM verifying the existence of a file is not critical? > > I think you had a valid point about this when using the LM to rewrite > links, but I'm not sure if this was all one of the strange effects you > were getting. This issue still exists (try changing burrokeet.org to foobar.com or some random name in samples/locationmap/index.xml and see what happens). I certainly think its critical (and I think an implementation that does _not_ do this check would be simpler). What do other people think about it? -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpqmyTG93u8C.pgp Description: PGP signature
Re: locationmaps not working?
ok, I'm a dumb-ass (*bangs head against the wall*) I copied over the locationmap from the seed site and customized it like I wanted (and I *swear* I'd tried this before), and it just worked. I don't know what was wrong, and I don't even know how it got fixed. Can things possibly get worse??! Anyways, all's well that ends well and I can now go to sleep peacefully knowing that my website has been updated properly :) PS: locationmap looks great. The xmap files already look much less intimidating! -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgp0eF3CwWI3N.pgp Description: PGP signature
Re: locationmaps not working?
So finally in frustration, I created a fresh site (views enabled), made sure that locationmap rewriting is working (in samples/locationmap/index.html). Then I copied over the seed-site's locationmap and the sample index.xml file over into my content area and did the same thing. Doesn't work! I'm totally out of ideas now. I've made sure that my sitemap.xmap, catalog.xcat, CatalogManager.properties, forrest.properties -- all are basically identical to the seed site. But it just doesn't work. I think I'm going to take a break now and wait for some fresh inspiration :) -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgppD3q5WOVaM.pgp Description: PGP signature
Re: locationmaps not working?
Ok, atleast part of the problem seems to be from the fact that Forrest tries
to verify the existance of the target of a locationmap expansion before using
it. So if I have a match for rewriteDemo/** that maps to
http://floatingsun.net/foobar/{1}.html, and this file doesn't exist then the
locationmap fails.
IMHO, locationmap should generate what I ask it to, irrespective of its
existence. There are multiple reasons:
o at the time I'm generating my static pages, the targets may not exist. But I
might just copy them later on.
o how does Forrest do this check precisely? I'm assuming some kind of message
to the webserver? That might not be a very good idea...
But I'm having problems despite this. More as I find out.
--
Web/Blog/Gallery: http://floatingsun.net
On Apache: http://people.apache.org/~diwaker
pgpIlGRy1Bygg.pgp
Description: PGP signature
Re: locationmaps not working?
On Saturday 01 October 2005 4:17 pm, Ross Gardler wrote: > Is this a views based site? (if so try turning off views to see if it > works with skins) Doesn't seem to be views related. The *exact* same locationmap is working in a Forrest seed but not for me. Even weirder, it works some times and doesn't other times. Ok, I know I'm not giving any real information here, but right now I'm just trying to isolate the problem :) Will keep this thread updated as I find something new. Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpktw3Y4gIxQ.pgp Description: PGP signature
Re: locationmaps not working?
On Saturday 01 October 2005 4:17 pm, Ross Gardler wrote: > However, the locationmap does work, see the link reqriting section on > our forest-seed site [1] > > http://forrest.zones.apache.org/ft/build/forrest-seed/samples/locationmap/i >ndex.html Yep, sure does. > Do you have a custom sitemap for your project? Nope. > Is this a views based site? (if so try turning off views to see if it > works with skins) Yep. Trying without views right now. Will report back shortly. -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpNfrE8e7ZcC.pgp Description: PGP signature
Re: locationmaps not working?
On Saturday 01 October 2005 11:00 am, Ross Gardler wrote:
> Daffy Installer
Still not working :( Now I get:
X [0]
projects/{lm:code/DaffyInstaller.jar} BROKEN: No pipeline matched request:
projects/{lm:code/DaffyInstaller.jar}
Is there a working sample in one of the plugins I can look at?
--
Web/Blog/Gallery: http://floatingsun.net
On Apache: http://people.apache.org/~diwaker
pgp2KsXGbmoFB.pgp
Description: PGP signature
locationmaps not working?
I'm getting errors using locationmap:
$ cat content/locationmap.xml
http://apache.org/forrest/locationmap/1.0";>
http://floatingsun.net/code/{1}"; />
Usage in my pages is like:
Daffy Installer
On running Forrest, I get errors like:
X [0] projects/lm:code/DaffyInstaller.jar
BROKEN: No pipeline matched request: projects/lm:code/DaffyInstaller.jar
Seems like locationmap's are not being used in the pipeline or something
similar. Any ideas?
Diwaker
--
Web/Blog/Gallery: http://floatingsun.net
On Apache: http://people.apache.org/~diwaker
pgpTg6q0hh9Ni.pgp
Description: PGP signature
Re: A 0.8 release? (was Re: [Proposal] rollback)
> No offense to anyone but if somebody wants to release 0.8 as - > refactored sitemaps to utilise locationmap, then we (or better this > somebody) has to put some more work into it. It cannot be that we expect > from the usual suspects that they now as well put more work into that > part of forrest. > > Actually that is the point, why you only? Refactoring the sitemaps can > be done by *all* committers. There is no secrets to it. I think this remark carries some negative connotation that bothers me. I will try to be concise and objective in my statements so as to avoid any confusion. I started using Forrest because it was a cool tool that fit my needs perfectly. In using it I found some things that I needed that weren't there and were not hard to fix, so I sent in the occasional patch. I like living on the bleeding edge of cool software, so when views were out I was quick to put them to test and I really liked the concept. With every project, there comes a time when the project sort of comes of age. I think Forrest is nearing that time now. There are a lot of ideas, discussions, community building up -- Forrest is trying to define itself, which is fantastic. But like all good things, it will take its time. I try to follow the discussions as and when I can, and put in my thoughts if I have something to add. Otherwise I'm happy to watch. I don't use Forrest at work. I don't get money out of Forrest related work. For me, the only interest in Forrest is personal. I try and contribute when I have the time and motivation, and it doesn't help if I feel there is some 'pressure' or 'expection' when I don't. Like Ross said, this is open source. If someone has a itch, they scratch it. At the same time however, for any good and large open source project to succeed it usually takes more than a passing interest and commitment on the part of atleast some of the developers. Typically (there are always exceptions) people who have a more concrete interest (work related, for instance) in the product will be the stewards of large changes and I think that works out well. While I really appreciate all the hard work everyone puts into Forrest, getting negative vibes about the "other" developers not putting in enough effort doesn't help the project or the community. People do what they want to do, and the community recognizes them for it. If I am unable to contribute as much as the next developer, I don't want to be judged for it, nor want other developers to feel bad about it. I have great respect for the work that people are doing here, but I feel bad if they think of themselves as the "usual suspects". Just my 2c. -- Web/Blog/Gallery: floatingsun.net
Re: Collaborative editing with Gobby
On Friday 30 September 2005 2:47 am, Ross Gardler wrote: > If we can get just three people to drop in at the same time that owuld > be great. So we are not wasting our time we could use the session to > write a How-To on doing collaborative meetings. Please raise your hand > if you will attend (meeting time being suitable of course). I'm in. Weekend should be (hopefully) fine. -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpGPdlloujon.pgp Description: PGP signature
Re: [Proposal] rollback
On Tuesday 27 September 2005 5:08 pm, Thorsten Scherler wrote: > > Added two new plugins for > > refactoring views into the core: > > - structurer > > - themes > > > > Recent changes to views with using jxtg as core component > > made the old view plugins unusable (FOR-675) > > which can not longer stay like this. > > > > I recommend to rollback: > > - org.apache.forrest.plugin.internal.view > > - org.apache.forrest.plugin.output.viewHelper.xhtml > > to revision -r280939 and then commit them back as views head. Why can't we just roll back trunk to a stable version, and move the views/xhtml2 work to a new branch? I think thats much neater, and easier both on devs and users alike. People can hack away on the views/xhtml2 branch without having to worry about breaking trunk for someone. -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpQUACT6pbro.pgp Description: PGP signature
Re: svn commit: r290132 - /forrest/trunk/site-author/content/xdocs/live-sites.xml
On Monday 19 September 2005 5:08 am, [EMAIL PROTECTED] wrote: > Add our first views based site. Created a section for views sites. umm... ahem! I believe mine was the first "views" based site ;-) :-) Hail views! -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpytJkOZb9i9.pgp Description: PGP signature
Re: my trip through the view-related pipelines
Wow, just finished reading this. Fantastic work Tim. We should put this in a doc. I'm tied up most of this week, but if no one has taken a stab at it till then, I'll get around to it. Again, great job. Until now I was using views pretty much as a black box. I think I atleast have a vague understanding. And Thorsten, you are officially crowned the XSLT woodoo master ;-) Nothing intelligent to add now, so adios Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpCuRASQgwVW.pgp Description: PGP signature
Re: Using the Cocoon sitemap profiler
On Monday 12 September 2005 12:23 am, David Crossley wrote: > This enables us to list the various sitemap pipelines > and components that are being used, how much time was > used by each, whether each component uses the Cocoon cache, > and show the actual xml data. This is just fabulous. There's just too much to learn about Cocoon and Forrest :-) Great work David! -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpCEpxBlcRoI.pgp Description: PGP signature
Re: [FT] 2005-09-06 Summary
> Diwaker: How is public transportation in SD? If I stay at some cheapy hotel > not down by the water will I be able to get to the conference easily? It sucks mostly. If you're living in the downtown area (where motels are likely to be not cheap), then you can get around on tram/bus. Anywhere off and you can't get by without a car. But I'm always happy to drive you around -- so keep that alternative in mind. -- Web/Blog/Gallery: floatingsun.net
Re: Proposal: interactive planning session for views/xhtml2/internals
> Looking for a suitable time. If it doesn't suit > then propose another: > http://www.timeanddate.com/worldclock/meetingtime.html?day=11&month=9&year= >2005&p1=136&p2=48&p3=176&p4=240&p5=224&p6=213 1) Saturday, September 10, > 2005 at 20:00:00 > 1) Sunday, September 11, 2005 at 19:00:00 Wow, that was kind of sudden! :-) Is it still happening? I assume the time's David mentioned are UTC? I have a busy weekend, but I'll still try to be online whenever its happening. Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpyDZYdSK3ch.pgp Description: PGP signature
Re: forrest:views and xhtml2
Hi all, While the discussion in this thread is valuable, I'm not sure it is sending the right message across. We must try and keep the discussions analytical, where possible -- I'm inclined to say that I sense some personal frustration in this thread. Anyhow, I'm writing just to clear up some confusion in my head: o As a community, I think we agreed that XHTML2 was the way forward o Again, as a community, we agreed that views were the way forward o At some point, views will have to move into Forrest core, and so will XHTML2 o Views had been under development, are usable, but not yet into core o Our first FT was largely experimental -- people played around with XHTML2; for lack of time and keeping in mind the future merge of views and XHTML2 into core, some shortcuts were taken (copying over of old sitemaps for instance) to get "something" working and show up in the browser On the whole, I think this is *great* and I don't really see what the problem is. o the first FT was (hopefully) fun for people. o For those who like to "hack around", it must have been a valuable hands on experience to know more about views and sitemaps o as a result more people are now comfortable working with views (so we have more, much needed man power) o and, we have a more concrete understanding of what are the problems that need to be solved. In the end, I think this will all add up to a neater, leaner, cleaner architecture for the new Forrest core. Maybe we're trying to do too much with this plugin. But we have to start *somewhere*, and we won't find out until we do it. For me, involvement in Forrest is *purely* for fun -- I don't use it in any work related areas. I felt the first FT was fun, just to hang around and learn a little bit more about people. For some (maybe most) devs, Forrest might be more work related, and thus more important professionally and so I understand if people are concerned about making good use of their time. But thats the beauty of this environment right -- that we can choose to work on what we want, how we want, in a way that makes most sense to us? So really, whats the big deal here? -- Web/Blog/Gallery: floatingsun.net
Re: xhtml2 tonights update & questions
> > We need to be clear on what we are going to achieve and how *before* > > having a Forrest Tuesday event. > > To an extent. It is very hard to be clear beforehand. I agree. Besides, I think FT's provide a unique opportunity for people to collaboratively explore new directions. This is important, because even if we are clear on what we want to achieve, unexpected surprises might come up on the way (implementation details/limitations that we didn't think of earlier etc) so we need some kind of "slack". > > No, having asynchronous discussion will sort out the issues. This is not > > noise, it is very important dicussion that is analysing the experimental > > work carried out on Forrest Tuesday. We have to find what is valuable > > about that approach and what is valuable about the alternative > > approaches that have not yet been worked on. It will sort out issues eventually. But I agree with Gavin that there seems to be a lot of confusion as to what was achieved and how valuable it was during the last FT. Personally, I think it was great -- well begun is half done, and I think after all those discussions on XHTML2 it was a good first step. True we might have wasted time, and we might end up implementing the same thing over and over again -- apart from the learning experience people had, I think this has value of its own in terms of understanding exactly what are the hard problems that we need to focus on. > I wonder if we can gather together for an hour or two > to just discuss in real time where we are going. > Define some objectives. > > It could be an IRC session. For me the other day > i found it difficult to hold multi-facetted discussion. > Still worthwhile. +1 for IRC. +0 for Skype. Weekends work best for me, I'll go with the majority. > If there is no one against this idea, then we could > define what we want to achieve and find a suitable > time slot. WDYT? Lets do it! -- Web/Blog/Gallery: floatingsun.net
Re: [FT] 2005-09-06 Summary
> Can you bring a supply to the upcoming ApacheCon > in San Diego? :-) > > That is only partially a joke. At least Ferdinand > is going to be there, maybe more of us. It would be > great to have other Forrest developers and users. I live in San Diego :-) So I'm definitely going to be there (modulo certain unexpected events in my calendar). -- Web/Blog/Gallery: floatingsun.net
[FT] 2005-09-06 Summary
Topic: XHTML2 core and Jira cleanup === Scribe: Diwaker Gupta DISCLAIMER: What follows is my understanding of the IRC logs. If you feel I have mis-interpreted something, do help me improve this document. This summary is by no means complete, please refer to the logs for full details. Interesting summary at: http://casa.che-che.com/~bot/forrest/ It was a new experience for a lot of people and generally enjoyable for all I hope. Unfortunately I could not participate actively due to other engagements. Ross skipped pleasantries and created an internal plugin to start the work on XHTML2. As a first milestone, the goal was to use Gav's sample XHTML2 and convert that to HTML using the xhtml2 plugin. Cheche started the bot and Ferdinand can tell us the funny incident involving the bot. Nicola expressed concern that despite having all the pieces of the puzzle (locationmap, views, xhtml2) we are having a hard time putting things together. He boldly ventured to suggest that perhaps we should rewrite the pipeline(s) from scratch. Other devs present shared similar thoughts. The general feeling was that the move to XHTML2 should be taken as an opportunity to consolidate our code base -- use locationmap as much as possible, remove duplicated code, remove unused code, refactor where necessary and so on. Directory Structure and Configuration - Discussion regarding the directory structure surfaced briefly, but there was no consensus. It is an important issue that needs a little more discussion, that will perhaps be taken up in another FT (ForrestTuesday) or hopefully even earlier. This has been discussed earlier on the dev list: http://www.mail-archive.com/dev@forrest.apache.org/msg00372.html Ferdinand suggested the following layout: my-project/ configuration/ forrest.properties skinconfiguration.xml sitestructure.xml tabs.xml content/ status.xml ** all other content Some devs expressed concern over the disruption the new layout will bring, and whether there was really a "need" for a new layout. Eventually the discussion just died out. IIUC, the bottomline is that we do need a layout change at some point of time; it just didn't happen today. Pipeline stages --- Thorsten started a discussion on being able to request any stage of the pipeline by itself. Cheche also gave some inputs on this. At some point the discussion digressed to talk about naming (index.tab vs. index.nav.xml) and other issues (site.xml is data or meta-data; role of editors and content producers etc). I'm not sure if any concrete conlusion/decision came out of this discussion. Later on Ross and Tim got back to this discussion. Ross tossed the idea of using Cocoon Views (not to be confused with forrest:views) as an alternate mechanism for achieving the same goals. Getting started on XHTML2 - People got off to a start after a few initial hiccups. There were some issues with namespace resolution; an initial stylesheet to convert XHTML2 to HTML was picked up from etherealwake.com for boot strapping (thanks Google!) which didn't seem to work all that well (lots of problems due to namespaces and the template not matching anything). David has been working on a relaxng schema for XHTML2 and validation using Cocoon. Thorsten hit a bug with 'src' attribute on some Actions in LocationMap (I really don't understand what this all means, just trying to hash stuff out of the logs) and Tim committed a partial fix for it; meanwhile Ross continued work on the pipelines. Location Resolution (thanks Tim for these notes!) - As a part of the making deeper use of Locationmaps in the core Sitemaps with a goal of letting locationmaps do all location resolution and letting sitemaps stick to the pipeline processing. For those that are familiar with name resolution servers or the Handles Service, it might be easier to think of the locationmap as a name resolution module or sort of a handle resolution module in that it accepts "names" or whatever you desire to call these "hints" and returns the location. The thought is that by using file name "looking" hints it disguises what locationmaps are really doing for us. By using URN-style names, we are truly disassociating the name/hint form the physical location. For example, here is a locationmap entry based purely on filename: and now below is that same entry using a "name" style. One implies a certain physical location where as the one below is truly a name that needs to be resolved to a physical location. The format is essentially: resource-type(dot)transform-type(dot)from-format(dot)to-format resource-type(dot)type(dot)name Examples of these two: transform.xslt.xthml2.html graphic.png.project-logo Views: naming and plugins ---
[jira] Closed: (FOR-555) xml comments are no longer generated or are stripped
[ http://issues.apache.org/jira/browse/FOR-555?page=all ] Diwaker Gupta closed FOR-555: - > xml comments are no longer generated or are stripped > > > Key: FOR-555 > URL: http://issues.apache.org/jira/browse/FOR-555 > Project: Forrest > Type: Bug > Components: Core operations > Versions: 0.7, 0.8-dev > Reporter: David Crossley > Assignee: Diwaker Gupta > Fix For: 0.8-dev, 0.7 > > The xml comments that are either in source documents or added via stylesheets > are now being stripped. > (The generated mirrors.html for our site-author is missing the special html > comments that are parsed by mirrors.cgi script.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (FOR-555) xml comments are no longer generated or are stripped
[ http://issues.apache.org/jira/browse/FOR-555?page=all ] Diwaker Gupta resolved FOR-555: --- Resolution: Fixed Assign To: Diwaker Gupta Isolated bug to strip_namespace.xsl in the common-skin files. Have committed a patch that fixes this. > xml comments are no longer generated or are stripped > > > Key: FOR-555 > URL: http://issues.apache.org/jira/browse/FOR-555 > Project: Forrest > Type: Bug > Components: Core operations > Versions: 0.7, 0.8-dev > Reporter: David Crossley > Assignee: Diwaker Gupta > Fix For: 0.8-dev, 0.7 > > The xml comments that are either in source documents or added via stylesheets > are now being stripped. > (The generated mirrors.html for our site-author is missing the special html > comments that are parsed by mirrors.cgi script.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [views] xsl:comment in templates
Alright, so I've isolated the bug to skins/common/xslt/html/strip_namespaces.xsl Commenting it out brings back the comments. A comment in sitemap.xmap says it was introduced due to a bug in Cocoon: http://issues.apache.org/bugzilla/show_bug.cgi?id=35348 I couldn't find any new information on that web page. I haven't played around with i18n, so I don't know what the initial problem was. But presumably we can fix strip_namespaces to leave the comments untouched. Now that we know where/why the bug is, hopefully someone can find a smarter way to fix it :-) Diwaker -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpH9qP4TpksX.pgp Description: PGP signature
Re: [views] xsl:comment in templates
I'm still an XML newbie, so you gotta help me out here Thorsten :-) On Friday 26 August 2005 12:57 pm, Thorsten Scherler wrote: > http://localhost:/prepare.include.xhtml.index > > still contains them but the stylesheet is and the > . That could be the cause. hmm, I don't quite understand. The rest of the tags are still in the xsl: namespace, so why is this a problem? > You need to add a stylesheet in pattern="get.contract.*.xhtml"> that transforms to > Alright, so here's what I did. o in the viewHelper.xhtml plugin's output.xmap, I added just before the i18n transform. o aliascomment.xsl looks like: If I now view http://localhost:/prepare.include.xhtml.index, I can see that all xsl:comment elements now appear as alias:comment elements. But the HTML still doesn't comtain the comments. From David's mail, it seems that this problem is not view related? But I'm not sure. In any case, I'd like to gain a little more understanding of exactly how does this whole "alias" business work, and why does it affect comments in this weird manner. We don't want to have a hack here, we need to understand the problem first :-) -- Web/Blog/Gallery: http://floatingsun.net On Apache: http://people.apache.org/~diwaker pgpIEpGXLvgQi.pgp Description: PGP signature
Re: [jira] Created: (FOR-652) CSS Style Sheets need cleanup and optimization
On Monday 29 August 2005 5:58 am, Gav wrote: [snip lots of good stuff] > We should use mainly ems for the content side of things, specifically > font-size. > > As a general rule of thumb : This will help: http://www.reeddesign.co.uk/test/points-pixels.html > I agree, I was just having a test using a seed site and pelt to make sure > there > wasn't any problems. If we can agree on a way of doing things then I'll > certainly jump in to CSS on views. Should I be looking at > /webapp/skins/leather-dev/css for this or somewhere else.? You can either work on files under: whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml/resources/skin/css Or (recommended), just copy them into your project dir skins/css and work on that. You can set which css to use in your *.fv files. Please, keep up the good work :-) -- Web/Blog/Gallery: http://floatingsun.net pgpJDZ074Ygwo.pgp Description: PGP signature
Re: updating the public forrest web site
On 8/29/05, Ross Gardler <[EMAIL PROTECTED]> wrote: > Tim Williams wrote: > > Do we have a document equivalent to this? > > http://incubator.apache.org/howtoparticipate.html#Project+Website+Howto > > http://svn.apache.org/viewcvs.cgi/forrest/trunk/etc/publishing_our_site.txt?view=markup > > I *think* this is up to date, David will tell us if it is not (right > after he recovers from fainting at the shock of someone helping with his > many management tasks ;-) I think it is. Atleast I followed it to the word and it worked for me (great job, David!). The first time I tried though, I ran into some svn related issues (don't remember the exact error I got). But its been fine since. Also see this message: http://www.mail-archive.com/dev@forrest.apache.org/msg03955.html -- Web/Blog/Gallery: floatingsun.net
Re: Automated formatting of XML files
> So do we all want to work with the same editor for cleaning or do we > want to use a cleaning tool and give up our blank lines in XML files? Many of us are sensitive to our development environments (atleast I am!), and forcing a particular choice of editor would not be a good idea IMHO :-) The reason I don't want to use any IDE for this cleanup task, and instead a tool like Tidy, is that things can be automated much more easily. We can schedule clean-ups periodically, add targets to the build process to do it automatically -- there's a lot of flexibility in how we go about it. Using an XSL transform for cleanup is attractive because we don't need any external utility; Forrest is all about XML processing anyywas :-) So I'm +1 on either Tidy or XSL (personally, I prefer Tidy since in my experience its much smarter and faster). -0 on jEdit plugins and such. -- Web/Blog/Gallery: floatingsun.net
Re: Forrest Tuesday (Was: Bug Days (Was Re: better use of Jira for Forrest))
On Saturday 27 August 2005 10:33 pm, David Crossley wrote: > I would like to deal with "Internal structure is XHTML2" > and the associated issues. +1 > Do others have better suggestions? > > Perhaps just dealing with the Jira backlog would keep > us amused, i.e. the Issue Tracker is this month's topic. I would make XHTML2 the "primary" topic. And if people get bored, they can spend time cleaning up JIRA. I think cleaning up JIRA should an ever present background task during ForrestTuesdays :-) Just as you suggested below > > Despite that, each BUG day should have some time devoted to cleaning up > > JIRA. In the long run its critical that JIRA serves to guide us, and not > > confuse us. Periodic cleaning should help. > > Yes, that should be a topic at every ForrestTuesday. Diwaker -- Web/Blog/Gallery: http://floatingsun.net pgpuNJFfXnmaQ.pgp Description: PGP signature
Re: [jira] Created: (FOR-652) CSS Style Sheets need cleanup and optimization
On Sunday 28 August 2005 5:55 am, Gavin (JIRA) wrote: > The current CSS implementation needs a bit of a cleanup, some tweaking and > optimization. It needs to be improved and some styles converted to % in > order to cater for different browsers and user resolutions. A more fluid > design needs to be the outcome. The overall style and look and feel of the > current pelt skin is to largely remain the same where possible whilst > implementing these improvements. The style sheets are to remain CSS1 valid > and aim for CSS2 valid. When XHTML2 is implemented perhaps CSS3 can be > achieved. Lets not rush into %ages. %ages are *not* a good way to create a fluid design. The biggest problem with %ages is that they cascade across elements, which makes the math slighly difficult. ems and px are both immune to cascading. For more details, check out: o http://css-discuss.incutio.com/?page=UsingFontSize o http://alistapart.com/topics/design/typography/ That said, there _are_ some very good uses for %ages -- for instance, if you want to restrict a box's width relative to its parent. I've looked at the diff in this issue -- it'll be good if you can describe exactly what problem they fix (like a browser screenshot or something). Also, since we will be moving to the views-based Pelt rewrite, we are probably better off focusing our CSS efforts into that CSS rather than the old Pelt's CSS :-) Diwaker -- Web/Blog/Gallery: http://floatingsun.net pgpaRJ5bFURLD.pgp Description: PGP signature
Re: Automated formatting of XML files
> I think that it is doing too much, e.g. removing the > blank lines before major elements, e.g. Hmm, I can't seem to make Tidy not do this :-( Is this a blocker? If not, then I'd like to stick with Tidy. If it is, read on. I was researching XML pretty printers a bit to see if we had alternatives. It seems one can just write a simple stylesheet [1] to clean up XML (since its part of the XSL language -- see the xsl:output element [2]) [1] http://lists.xml.org/archives/xml-dev/200110/msg00620.html [2] http://www.zvon.org/xxl/XSLTreference/Output/xslt_output.html Although I haven't tried this method yet and its not configurable at all. So I'm not sure how well it'll work. -- Web/Blog/Gallery: floatingsun.net
Re: Automated formatting of Java files
> I think that it is doing too much, e.g. aligning like this: > this.processor = null; > this.parser= null; Ok, we can choose not to. I'll modify the config and add it to the repository sometime later tonight. Meanwhile, I really don't see why doing "too much" is a problem. Its an automated tool, its _trivial_ to change such things at a minute's notice. But I'll go with the majority, I'm not anal about cleanup conventions :-) > 1 whitespace at end-of-line Ok > 2 tabs to four-space Ok > 3 indentation Ok > 4 organise imports Ok. Jalopy can get fancy and explode imports (so instead of org.apache.forrest.* it will declare only those classes that are actually used) or it can collapse them (use foo.* instead of individual classes). Any preferences there or do I just leave them as it is? > 5 whitespace in java statements This is vague. Are you talking about assignments? expressions? operators? brackets? space before? space after? An example would really help :-) > 6 aligned variable assignments Subject to dev preferences I guess. -- Web/Blog/Gallery: floatingsun.net
Re: Automated formatting of XML files
On 8/26/05, Thorsten Scherler <[EMAIL PROTECTED]> wrote: > Can't we have *one* thread for that? I created two threads simply because of convinience. XML and Java will use different cleanup tools with a different set of configurations. They have different syntaxes and different types of cleanups we might want. So I just thought it would be easier for people to focus on one type of file at a time when they are giving their preferences. Apparently I was wrong :-) > formatting of Java files". Is there a reason to treat java seperate from > other files? There most certainly is. -- Web/Blog/Gallery: floatingsun.net
Re: Automated formatting of XML files
On 8/25/05, David Crossley <[EMAIL PROTECTED]> wrote: > Diwaker Gupta wrote: > > When I say XML, I mean all kinds of XML files (XSL, *.fv, *.ft) > > How will the tool know which are xml file-types? > We have a multitude of xml filename extensions. > There is a list on one of the tools in the > "committers" svn repository at relicense/src/insert.pl I don't see why this is a problem. I'll just write a simple script that runs the tool on whatever extensions we use for XML files. Tidy doesn't know/care about the file extension -- you just feed it some input, and it gives you the output. > I think that it is doing too much, e.g. removing the > blank lines before major elements, e.g. Like I said, its configurable. We can pick and choose. Since this is an automated process, I'm not too worried about the tool doing "too much" -- just change the config, re run and voila! > We should start with very simple stuff, e.g. just tabs > and trailing whitespace, then gradually add other operations. > However we don't want to get too strict on code style. Agreed. > I suggest that we define a list of what we would possibly > want to adrress. Here is a start: > > 1 whitespace at end-of-line > 2 tabs to four-space You mean 2 spaces. > 3 indentation Ok. > 4 word-wrap for long lines What would be a good length? Right now I use 80. > 5 whitespace between attribute definitions Ok. > We need to at least do 1 and 2 while 5 may be doubtful. > > It seems to be too vigorous with wrapping. Perhaps wider > would be better. > <use="generate-id(preceding-sibling::h4[1])"/> > --- > >> use="generate-id(preceding-sibling::h4[1])" /> It won't wrap if there are no spaces to break the line at. It won't wrap between attribute values (I think this is configurable though). I usually use 80 in my editor as well, so this works for me. We can set it to 100 or something else if that works for more people. > Also we need to run it on one of the xdocs > in site-author/content/xdocs to see what it does > with word-wrapping for long lines of element content. I'll do this soon. -- Web/Blog/Gallery: floatingsun.net
[views] xsl:comment in templates
I'm writing a template which contains a
Re: Automated formatting of Java files
> Can you tell me what settings you are using so I can try to match them > with my Jalopy plugin without thinking too hard? :) Attaching the convention file. I use it with the Ant plugin. But you can use whatever you want. -- Web/Blog/Gallery: floatingsun.net 14Forrest Coding Conventions Forrest false [A-Z][a-zA-Z0-9]+ [A-Z][a-zA-Z0-9]+ [a-z][\w]+ [a-z][\w]+ [a-zA-Z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-zA-Z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-zA-Z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-zA-Z][\w]+ [A-Z][a-zA-Z0-9]+ \w+ [a-z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-z][\w]+ [a-z]+(?:\.[a-z]+)* [a-z][\w]+ [a-z][\w]+ [a-z][\w]* false false false false false false false false false false false false false false false false false false 6 3 3 3 3 3 3 true 1 true false true true true bak 0 1 0 1 0 1 1 1 2 1 1 1 0 1 1 1 1 1 1 0 0 1 false false true true true true true false false false false false false true true true false false false true 0 0 0 0 false */ * @throws $exceptionType$ DOCUMENT ME! * @param $paramType$ DOCUMENT ME! * @return DOCUMENT ME! /**| * DOCUMENT ME! false false false - true false Inner Classes Constructors Instance fields Instance initializers Inner Interfaces Methods Static fields/initializers 0 false The Apache Software Foundation 0 /*| * Copyright 1999-2004 The Apache Software Foundation or its licensors,| * as applicable.| *| * Licensed under the Apache License, Version 2.0 (the "License");| * you may not use this file except in compliance with the License.| * You may obtain a copy of the License at| *| * http://www.apache.org/licenses/LICENSE-2.0| *| * Unless required by applicable law or agreed to in writing, software| * distributed under the License is distributed on an "AS IS" BASIS,| * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either e
Re: Automated formatting of XML files
> What are your settings? Tidy is giving errors around the CDATA sections > and it won't tidy til those errors are "corrected". Attaching the RC file. I haven't tested it extensively -- only on the sample files in test-whitespace. So it might very well need some more tweaking. Just for convinience I think its better to setup the parameters in one place. Once we have decided on the config, we can make it available to all the devs who are interested. If multiple people try to do the cleanup and even if one of the config files changes inadvertantly, it would do more harm than good :-) -- Web/Blog/Gallery: floatingsun.net forrest.tidyrc Description: Binary data
Automated formatting of XML files
When I say XML, I mean all kinds of XML files (XSL, *.fv, *.ft) As with Java, I have committed a "tidied" version of the html2document.xsl sample document in the test-whitespace directory. As with Jalopy, Tidy (http://tidy.sf.net) is extremely configurable, so if you don't like something or have a suggestion, just let me know. Diwaker -- Web/Blog/Gallery: http://floatingsun.net pgpef880MQmUi.pgp Description: PGP signature
Automated formatting of Java files
Following up with our earlier discussion on whitespace cleanup, I have added two "jalopied" Java source files in the test-whitespace directory. I would urge the devs to take a look at both the original Java file and the formatted file and see if it suits their tastes. Please post any comments and suggestions in this thread. Bear in mind that with Jalopy, almost *anything* is configurable. So if you find anything, however small/trivial it is that you don't like, please let me know. Its a great tool, so lets make the best use of it. To see exactly what is configurable, take a look at: http://jalopy.sourceforge.net/manual.html As an example of things that it can do: o automatically add/update headers (the Apache license, for instance. In future if we have to change one line in the license, Jalopy will automatically delete the old one and insert the new one) o sorting/group of imports, methods, variables o alignments, braces, spaces -- you name it! o automatic javadoc generation, correction -- Web/Blog/Gallery: http://floatingsun.net pgpqkvXX7zy85.pgp Description: PGP signature
Re: whitespace cleanup test
> Jalopy was mentioned during that big cocoon-dev thread. > Follow the links from http://issues.apache.org/jira/browse/FOR-644 > > For some reason, we decided not to use it. Perhaps because > periodic cleanups can still cause havoc for people who > are working on those files. A lot of Cocoon people gave > it good reviews, but warned that any such cleanup > needs to be very careful. I would still like to give it a shot. Hows this -- I run Jalopy on one of the "bad" files in the directory you have setup, and then the devs can have a look and decide if it works for them. If everyone like the output of Jalopy, I can run our source files through it once every week or so? > Another issue is that it is only for java files, > whereas most of our problems are in the XSLT files. True. Again, I would like to automate the process of cleaning. Tidy does a fairly good job with arbitrary XML (tidy.sf.net). We can also try using XML-Tidy (http://www.cpan.org/modules/by-module/XML/XML-Tidy-1.0.4C8K1Ah.readme). I'll give these a shot tonight and post feedback. Diwaker -- Web/Blog/Gallery: floatingsun.net
Re: whitespace cleanup test
Can we use something like Jalopy (http://jalopy.sf.net) to periodically clean up all the Java files? It doesn't need to be a Forrest. One of us can run it through once in a while (I'm happy to volunteer). I've used Jalopy in the past -- it works really well, its highly customizable, and has excellent Ant integration. On Tuesday 23 August 2005 9:15 pm, David Crossley wrote: > Tim Williams wrote: > > Can someone with whitespace knowledge see if this actually cleaned up > > the whitespace issues in this file properly? > > It was not a good test, because this file did not have a mixture > of tabs and space indenting, like many of our files do. > > Also this file was in good shape - just some some trailing whitespace, > which your editor did properly clean up. > > Other files (e.g. many of our stylesheets) have a mess of inconsistent > indenting. That is why we cannot just do a simple "replace all tabs > with spaces" - those files would still have bad indenting. > > I think that we need to set up a test directory which has > examples of bad whitespace. I will go and start that. > > > I think my text editor > > has "wanted to do the right thing" all along but I've forced it into > > just doing functional diffs instead. I'm fairly confident that no one > > else is touching the files I am so if this works, I could go ahead and > > fix them all fairly quickly. > > --tim > > > > > Author: twilliams > > > Date: Tue Aug 23 19:41:53 2005 > > > New Revision: 239511 > > > > > > URL: http://svn.apache.org/viewcvs?rev=239511&view=rev > > > Log: > > > whitespace cleanup test > > > > > > Modified: > > > > > > forrest/trunk/main/java/org/apache/forrest/locationmap/LocationMapModul > > >e.java > > > > > > Modified: > > > forrest/trunk/main/java/org/apache/forrest/locationmap/LocationMapModul > > >e.java URL: > > > http://svn.apache.org/viewcvs/forrest/trunk/main/java/org/apache/forres > > >t/locationmap/LocationMapModule.java?rev=239511&r1=239510&r2=239511&view > > >=diff > > > === > > >=== --- > > > forrest/trunk/main/java/org/apache/forrest/locationmap/LocationMapModul > > >e.java (original) +++ > > > forrest/trunk/main/java/org/apache/forrest/locationmap/LocationMapModul > > >e.java Tue Aug 23 19:41:53 2005 @@ -1,13 +1,13 @@ > > > /* > > > * Copyright 1999-2004 The Apache Software Foundation or its > > > licensors, * as applicable. > > > - * > > > + * > > Argh, it seems that our program that inserted the license headers > in java files that were missing the license, adds trailing whitespace > after the comment marker on "blank" lines. So many of our java files > will have this problem. > > -David -- Web/Blog/Gallery: http://floatingsun.net pgp0K4ql2NBKj.pgp Description: PGP signature
Re: Profiling Forrest [FOR-572]
On Sunday 21 August 2005 10:11 pm, David Crossley wrote: > We cannot create a dependency on an LGPL library. > The terms go beyond those of the Apache License. Forrest doesn't need to "depend" on JRat. Its only a tool for profiling. Is there no provision for including optional code under a different license? Or does Forrest *need* to ship with Apache compatible licenses? Also, what is the intended usage of the lib/optional directory? Meanwhile, here's a list of open-source Java memory profilers: http://java-source.net/open-source/profilers -- Web/Blog/Gallery: http://floatingsun.net pgpAKBKro9xrN.pgp Description: PGP signature
Profiling Forrest [FOR-572]
Greetings everyone, Ron has done some excellent work on profiling Forrest (see [1], [2]). Since then I've been looking at how can we integrate profiling into Forrest's build process. My requirements were: o open source (not necessarily, but preferable) o good integration with our build process (so for instance, I would like to generate a "debug" version of Forrest through our Ant build files) o meaningful reports o good documentation, active development o *no* modification to the source code of the application to be profiled should be required. Byte code instrumentation is OK though. To start off, I found a list of open source Java profiling tools [3]. After doing a preliminary check-off (by looking at web site, features and so on), I settled on JRat [4]. I might try something else later, but for now this is what I played with. So here's what I have right now: o I can do a simple ./build.sh jar.debug -- this creates a "debug" version of Forrest. When you next run Forrest, the data will be automatically logged. Where and how and what to log is all configurable via an XML file o JRat has a nice GUI to view the generated log reports. I presume it will not be too hard to write our own parsers if we so wish. You can see an example of the kinds of reports it can generate here: http://people.apache.org/~diwaker/forrest-jrat-stat-method.png http://people.apache.org/~diwaker/forrest-jrat-rate-method.png http://people.apache.org/~diwaker/forrest-jrat-tree-method.png These were generated after running Forrest on site-author. JRat is released under LGPL. Right now its at version 0.71b. Development seems ok (just one guy actually). Documentation is ok, but could get better. So what do devs think of this? If we find this valuable, I can commit everything to SVN. You can checkout JRat website for documentation and other details. Diwaker [1] http://thread.gmane.org/gmane.text.xml.forrest.devel/14875 [2] http://thread.gmane.org/gmane.text.xml.forrest.devel/15261 [3] http://java-source.net/open-source/profilers [4] http://jrat.sf.net -- Web/Blog/Gallery: http://floatingsun.net pgpfNGwa7IzN0.pgp Description: PGP signature
Re: Trimming SVN checkouts (was Re: Move eclipse tools out of trunk)
On Thursday 18 August 2005 8:21 am, Ross Gardler wrote: > core >/trunk >/branches > plugins >/org.apache.forrest.input.wiki > /trunk > /branches >/org.apache.forrest.output.pdf > /trunk > /branches > tools >/eclipse > /trunk > /branches >/forrestbot > /trunk > /branches > docs >/trunk >/branches +1. I would also add a /tags to each of the sections. However, we might get away without it since IIUC projects are *required* to use archive.apache.org for older versions? -- Web/Blog/Gallery: http://floatingsun.net pgpcG5MMsEDkg.pgp Description: PGP signature
Re: Forrest Tuesday (Was: Bug Days (Was Re: better use of Jira for Forrest))
On Thursday 18 August 2005 7:05 am, David Crossley wrote: > In our earlier discussions, we agreed that we don't > want to have the channel as a permanent means of > communication. So i looked into how to restrict it. > Just start a new channel at the beginning of the > day with name like for-09 and it will close when > the last one of us leaves at the end of the 24 hours. > Simple. +1 For a short turn around time and quick feedback, I think using IRC as a temporary mode of communication is a great idea. > Each meeting could either just concentrate on getting Jira > under control or have a special topic like a group effort > to move the core to use xhtml2. More generally, we could identify a particular area to work on before hand. That way we can sort of direct attention to some really needy-aspect that might otherwise get left behind simply because no individual dev has a strong enough itch to work on it. Despite that, each BUG day should have some time devoted to cleaning up JIRA. In the long run its critical that JIRA serves to guide us, and not confuse us. Periodic cleaning should help. > Also it is a place for us to get to know each > other a little. +1 :-) -- Web/Blog/Gallery: http://floatingsun.net pgpmt7EzxcwYN.pgp Description: PGP signature
Re: debugging views - short (was Re: [views] head broken?)
On Thursday 18 August 2005 4:32 pm, Thorsten Scherler wrote: > First general rule of debugging views is make sure your modified > contracts are not causing the problem. Bingo! :-) -- Web/Blog/Gallery: http://floatingsun.net pgp05qf1PxQ5b.pgp Description: PGP signature
Re: [views] head broken?
Sorry for the false alarm folks. Here's a tip for the future: $ svn diff (or svn status) (maybe you made a change that doesn't collide with the latest SVN up, but broke stuff!) cheerios, Diwaker -- Web/Blog/Gallery: http://floatingsun.net pgpKpO77zJUkK.pgp Description: PGP signature
Re: Move eclipse tools out of trunk
On Wednesday 17 August 2005 7:22 am, Ross Gardler wrote: > So, I would like to move the Eclipse tools from: > > https://svn.apache.org/repos/asf/forrest/trunk/ > > to: > > https://svn.apache.org/repos/asf/forrest/tools/eclipse/trunk +1 -- Web/Blog/Gallery: http://floatingsun.net pgpMFgUjcJ6pe.pgp Description: PGP signature
[views] head broken?
Folks, Since the past 2 days, I've been getting this: $ forrest site X [0] linkmap.html BROKEN: javax.xml.transform.TransformerException: Empty expression! With $forrest run, I get: Message: null Description: No details available. Sender: org.apache.cocoon.servlet.CocoonServlet Source: Cocoon Servlet Request URI index.html cause javax.xml.transform.TransformerException: Empty expression! request-uri /index.html A fresh forrest seed-sample with views enabled breaks identically. Is anyone else seeing this problem? -- Web/Blog/Gallery: http://floatingsun.net pgpB61rsr3TGx.pgp Description: PGP signature
Re: (FOR-583) Pelt compatible [views/templates] skin
On Monday 15 August 2005 10:41 am, Thorsten Scherler (JIRA) wrote: > to activate the pelt theme in your project set the following properties: > *** forrest.properties ** > project.skin=leather-dev > project.theme=pelt > project.view-defaultView=pelt.fv We really should take leather-dev and put it *inside* views. It just adds to the confusion right now. -- Web/Blog/Gallery: http://floatingsun.net pgpN0F1gwhVzo.pgp Description: PGP signature
Re: Using Jira and branches for Project Management
Thanks for a wonderful roundup of issues, Ross. On Saturday 13 August 2005 4:00 am, Ross Gardler wrote: > We are getting larger as a developer base. As a consequence there is an > increasing tendencies for small numbers of devs to work on different > sections of the code base. As a result we are becoming a little > disorganised - one virtual team not knowing what the other is doing. I agree. Even the mailing list is overwhelming these days, let alone JIRA. > Jira is the tool for keeping track of this stuff so that we can track > and prioritise things. However I'm not too sure what the best way of > utilising this resource is. DOes anyone have an experiences to share? I think voting on issues is a good idea. It will give us a feel of what users and developers want and can be a good starting point for a roadmap document. IMHO, we do not practice "release early, release often", often enough :) This has been mentioned on the list before (see [1], [2]), however I don't think it has actually seeped into our development just as yet. [1] http://article.gmane.org/gmane.text.xml.forrest.devel/14805/ [2] http://article.gmane.org/gmane.text.xml.forrest.devel/11665/ Take a look at our release durations: o 0.2 -> 0.3 : 2 months o 0.3 -> 0.4 : 1 month o 0.4 -> 0.5 : 7 months o 0.5 -> 0.6 : 1 YEAR o 0.6 -> 0.7 : 8 months o 0.7 -> 0.8 : 2 months and counting... I just think that releasing as soon as we have some set of self contained features in is a good idea. It gives confidence to the users that all is well -- I mean what the end user usually sees are "releases". Talking about users, what do people think of doing a survey of Forrest users. During the time that I've hung around the lists, I've noticed that often times people start in the user-list, then slowly migrate to the dev-list and some eventually end up as devs, which is just *great*. However, I do think that we need to put in some more efforts to publicize Forrest, make it more visible. Having an overlap between users and dev is not only good, but IMHO necessary, but we still need to expand our user base. Diwaker -- Web/Blog/Gallery: http://floatingsun.net pgpf8vqCPR2LE.pgp Description: PGP signature
[jira] Resolved: (FOR-617) Forrest DOAP file
[ http://issues.apache.org/jira/browse/FOR-617?page=all ] Diwaker Gupta resolved FOR-617: --- Fix Version: 0.8-dev Resolution: Fixed The DOAP file is available at http://forrest.apache.org/doap.xml I've heard from Mark Hedlund at O'Reilly: "Thanks for creating the feed. We currently have a bug in the feed parser, which we're working out shortly. Once that's fixed, new version of Forrest will appear in CodeZoo very quickly." > Forrest DOAP file > - > > Key: FOR-617 > URL: http://issues.apache.org/jira/browse/FOR-617 > Project: Forrest > Type: Improvement > Components: Documentation and website > Versions: 0.8-dev > Reporter: Diwaker Gupta > Assignee: Diwaker Gupta > Priority: Trivial > Fix For: 0.8-dev > Attachments: doap.xml > > See http://thread.gmane.org/gmane.text.xml.forrest.devel/15097 for background. > I've created an initial DOAP file for Forrest. Its easy to do this manually > at each release. I wasn't sure how to publish it, so I thought I'd let it > burn on JIRA for a while. What do people think? > Its a regular XML file, but we want it published as-is, without any > processing from Forrest. Will putting an directive for doap.xml in > cli.xconf be enough? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (FOR-617) Forrest DOAP file
On Thursday 11 August 2005 1:40 am, David Crossley wrote: > Aha, i see that you have been misunderstanding > something fundamental. It needs to be published > via our normal document publishing, just like > any other document. Thanks a ton for clearing that up! All this while I had been under the impression that everything on Forrest's website had to go through a Forrest publishing process. Completely forgot about the .htaccess! :-) I have added the doap.xml file both to Forrest trunk and site. Right now I've just synced them manually, and its not linked from anywhere within site.xml yet. That will probably change as we figure out the best way of publishing this info. > To publish the website manually, do the following. > It is good to get a feel for how it all happens, > then use the forrestbot most times after that. This was very useful, thanks again! > Or use the forrestbot as described in > trunk/etc/publishing_our_site.txt > which you already did sucessfully recently. I sure did. Diwaker -- Web/Blog/Gallery: http://floatingsun.net pgpKwWGwNtnpX.pgp Description: PGP signature
Re: [jira] Updated: (FOR-617) Forrest DOAP file
On Wednesday 10 August 2005 11:34 pm, David Crossley wrote: > It would be better to have it in our SVN. > In that way, if you are absent at the time that we do > the next release, then we will still be able to update it. > No rush with that part of course, but that would be preferable. I can put it in SVN, thats not a problem. But it still needs to be published *somewhere* -- that was my main concern. Is there a way to host it under forrest.apache.org somehow? Diwaker -- Web/Blog/Gallery: http://floatingsun.net pgpT8jZuAgyz0.pgp Description: PGP signature
Re: [jira] Updated: (FOR-617) Forrest DOAP file
On Wednesday 10 August 2005 1:04 am, David Crossley wrote: > How about just linking to it from one of our pages > or as a menu item in the Project tab. Sounds fine. I've put the file up at [1] and I will maintain it there till we need a better solution. I'll get this information into Codezoo asap. > That works for me. However, i needed to adjust your > xml file because nothing is allowed before the > xml declaration. Yep, I noticed. I fixed that. Do you have this file online somewhere too? We just need a single copy. [1] http://people.apache.org/~diwaker/doap.xml -- Web/Blog/Gallery: http://floatingsun.net pgpLdowN40rd5.pgp Description: PGP signature
Re: [Who we are] How to become an inactive commiter ;-)
On Wednesday 10 August 2005 7:28 am, Ferdinand Soethe wrote: > I think we'll do fine having people adjust their status as they see > fit in most cases. No need to create more work around that. +1 -- Web/Blog/Gallery: http://floatingsun.net pgp1kGyi1pv7s.pgp Description: PGP signature
Re: Reducing Forrest build time
On Tuesday 09 August 2005 4:56 pm, CFAS Webmaster wrote:
> *Please*? ;) I filled my disk twice before I did a ln -s /dev/null
> ${..}/logs/core.log
Yeah, I had a log of 3.6G lying around in the build dir, and I was wondering
why my backups were suddenly taking _so_ long...
*dives into Cocoon documentation*
--
Web/Blog/Gallery: http://floatingsun.net
[jira] Updated: (FOR-617) Forrest DOAP file
[ http://issues.apache.org/jira/browse/FOR-617?page=all ] Diwaker Gupta updated FOR-617: -- Attachment: doap.xml Initial version of the DOAP file for Forrest > Forrest DOAP file > - > > Key: FOR-617 > URL: http://issues.apache.org/jira/browse/FOR-617 > Project: Forrest > Type: Improvement > Components: Documentation and website > Versions: 0.8-dev > Reporter: Diwaker Gupta > Assignee: Diwaker Gupta > Priority: Trivial > Attachments: doap.xml > > See http://thread.gmane.org/gmane.text.xml.forrest.devel/15097 for background. > I've created an initial DOAP file for Forrest. Its easy to do this manually > at each release. I wasn't sure how to publish it, so I thought I'd let it > burn on JIRA for a while. What do people think? > Its a regular XML file, but we want it published as-is, without any > processing from Forrest. Will putting an directive for doap.xml in > cli.xconf be enough? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
