Re: [VOTE] Move Apache Forrest to the Attic
Hello I have earlier argued for the maintenance mode of Forrest, and had some plans for contributing to areas important to us in divvun.no. Alas, after all these years that has not materialised, and I see little chance that we will contribute in any meaningful way in the medium-term future. Given this, the only logical conclusion for me must then be: +1 for moving to the Attic. Best regards, Sjur > 11. nov. 2019 kl. 07:46 skrev David Crossley : > > The Apache Forrest project has seen little activity for a long time, and > there has not been a release since 2011. > > As noted in the quarterly Board reports [1], for years the Forrest PMC has > been keeping the project in maintenance mode. > > Recent board reports have indicated a move to the Apache Attic. A thread was > commenced on the project mailing lists to provide an opportuntity for people > to discuss that possibility and to re-engage [2]. There was no further > discussion. > > Note that the project resources would still be available. There would be no > further releases. The Apache Forrest PMC would be terminated by Board > resolution, and the Apache Attic PMC would instead have the oversight. > > This vote thread is to confirm the desire of the project, being the next step > in the Attic process [3]. > > The general voting process is explained at the Forrest project guidelines > [4]. This situation was not anticipated by the guidelines. So in this case > anyone can vote. > > So please vote whether Apache Forrest will be retired and moved to the Attic: > +1 yes move to the Attic > -1 the project should continue, and indicates commitment to revitalise the > project > > The three outcomes could be: > > A) There are three or more people voting -1, saying that they would instead > like the project to continue and agree to be involved. > In this case, a probable course would be to go via the Apache Incubator [5] > to revitalise the community. > > B) The normal positive outcome, with three or more +1 votes. > C) Insufficent votes indicates a dormant PMC. > > So in those latter cases, the remainder of the Attic process would ensue. > > Also note that even after moving to the Attic, there are processes defined > there regarding moving out again. > > The vote will run for one month to be summarised on 11 December. > > > [1] https://whimsy.apache.org/board/minutes/Forrest.html > > [2] > https://lists.apache.org/thread.html/fda24957e049f10d282037594d2aa61ce9a31cf8fc5313959aa81672@%3Cdev.forrest.apache.org%3E > Subject: Forrest possibly retiring? > Date: 2019-06-11 > > [3] https://attic.apache.org/process.html > > [4] https://forrest.apache.org/guidelines.html > > [5] https://incubator.apache.org/ >
Re: External component and forrest site
Thanks to both of you for tips and suggestions:-) Sjur > 7. sep. 2016 kl. 06:07 skrev David Crossley : > > Brian M Dube wrote: >> Sjur Moshagen wrote: >>> Hello all, >>> >>> As a follow-up on the previous question, here’s another one: >>> >>> I need to be able to build a static version of the site. This works fine >>> _except_ for this editor thing that I added to >>> $PROJECT_HOME/src/documentation/resources/. >>> >>> The thing is, that the ant build files are _mimicking_ the xmaps etc, they >>> are not directly using them. And in this case ant is not copying any (?) of >>> the files found in that resources dir except for the one linked to in the >>> html page that contains the editor. > > Around line 82 of main/targets/site.xml > it copies only certain project resources, explicitly the images directory. > > Perhaps the ability was never completed to copy over certain relevant > other project resources. > >>> So: >>> >>> how can I tell ant that _in this project_ I need to copy everything in >>> resources/x/ to site/x/? > > Perhaps this is indicating that this should be in a plugin. > There is a section at the end of each plugin build.xml file, > that shows how to copy over extra resources. > > I only found one that utilises that: the output.htmlArea plugin. > (Not sure about the state of that plugin, but at least useful as an example.) > > As a plugin would make it easier to apply to various projects. > >> I thought I remembered there being a setting to control this. All I'm >> finding now is: >> >> https://forrest.apache.org/docs_0_100/howto/howto-asf-mirror.html#link >> and >> https://forrest.apache.org/docs_0_100/faq.html#cli-xconf >> >> Have you already tried that? >> >> Brian > > And if your project uses Forrestbot to deploy, then that might assist > on a per-project level. > > http://forrest.apache.org/tools/forrestbot.html#Workstages > discusses using your own "getlocal.get" workstage. > > Another way is shown in our "zone" SVN forrest/zone/config/run-forrestbot.sh > which can copy some stuff before invoking forrest. > > -David
External component and forrest site
Hello all, As a follow-up on the previous question, here’s another one: I need to be able to build a static version of the site. This works fine _except_ for this editor thing that I added to $PROJECT_HOME/src/documentation/resources/. The thing is, that the ant build files are _mimicking_ the xmaps etc, they are not directly using them. And in this case ant is not copying any (?) of the files found in that resources dir except for the one linked to in the html page that contains the editor. So: how can I tell ant that _in this project_ I need to copy everything in resources/x/ to site/x/? Regards, Sjur
Re: External component integrated in a forrest page
3. sep. 2016 kl. 02:32 skrev Brian M Dube :
>
> On 09/02/2016 12:43 AM, Sjur Moshagen wrote:
>> The main issue is that of getting url’s mapped to the correct directory on
>> disk. I though I had done it correctly, but still no success. The CKEditor
>> code is located in:
>>
>> $PROJECTROOT/src/documentation/resources/ckeditor/*
>>
>> and I have the following entry in
>> $PROJECTROOT/src/documentation/content/locationmap.xml:
>>
>>
>>
>>
>>
>>
>>
>
> I got it to work using {properties:resources} instead of
> {properties:resources-dir}. I tried briefly with the locationmap, but
> didn't get that working.
Thanks a lot! Those two tips - removing ‘-dir’ from the location variable, and
skipping the locationmap - solved the problem :-)
Sjur
External component integrated in a forrest page
Hello all, We’re trying to make CKEditor [1] work in a forrest page (and as part of it, a speller plugin we have developed to support the languages we work on). CKEditor is all JS and CSS, and I have tried following the descriptions here [2] to make it work, with no success so far. The main issue is that of getting url’s mapped to the correct directory on disk. I though I had done it correctly, but still no success. The CKEditor code is located in: $PROJECTROOT/src/documentation/resources/ckeditor/* and I have the following entry in $PROJECTROOT/src/documentation/content/locationmap.xml: I also added the following to $PROJECTROOT/src/documentation/sitemap.xmap: But no success. Any feedback would be most welcome. Sjur [1] http://ckeditor.com [2] https://forrest.apache.org/docs_0_100/project-js-css.html
New skin fleece
Hi all, I have started work on the bootstrap based skin I mentioned on the list quite some while ago. Up until now it has only been in use for two sites our group maintains (divvun.no and divvun.org), with some local modifications and changes that are not appropriate for a more general audience. Today’s commits are the first steps into making a proper forrest skin out of it. One of the improvements from our first, internal implementation is that it is fully self-contained - our internal version just linked to the bootstrap site, and would thus not render when working offline. The code is based on bootstrap 3.3.6 and jquery 1.11.1. I have only used the bootstrap and jquery downloads as is, for easy updates in the future. All modifications and changes to bootstrap have been done as css overrides in the screen.css file in the skin. It works ok as it is now, although there are a couple of minor errors and things to improve. To test: 1. forrest seed 2. edit forrest.properties: set the skin to fleece-dev 3. forrest run 4. open http://localhost:/ Enjoy! Feedback, improvements & bug fixes welcome. Sjur
Re: Title element content in v2 docs
Thanks for the research and feedback. It seems those elements have been added to the dtd, but without the corresponding changes to the skinning transformations. I’ll have a look at that. Sjur > 25. nov. 2015 kl. 00:11 skrev David Crossley : > > I did some net archaeology: > > This was initially added to document-v11 DTD around 2003-03-20, > i gather as part of the alignment with xhtml at the time. > Soon after, the DTD changes since Forrest-0.4 were removed > and the new document-v12 was commenced in CVS on 2003-04-24: > http://marc.info/?l=forrest-dev&m=105115903415487 > which did contain a comment about it. > > The comment is also listed at the end of our example documents, e.g.: > http://forrest.apache.org/dtdx/document-v20.html#changes-12 > viz: > "doc-v12 enhances doc-v11 by relaxing various restrictions that were found to > be unnecessary. > * Links ((link|jump|fork) and inline elements (br|img|icon|acronym) are > allowed inside title. > * ..." > > -David > > Sjur Moshagen wrote: >> Hello all, >> >> I just noticed a discrepancy between the dtd and the actual rendering in the >> default (and possibly all) skins for the title element. The DTD says: >> >> title >> Element name title >> Content model( #PCDATA | strong | em | code | sub | sup | a | br | >> img | icon | acronym | map ) * >> Attributes >> id type: ID >> classtype: CDATA >> xml:lang type: NMTOKEN >> Used inside header | section >> >> I then tried to add an img element inside title, but it is removed during >> the transformations to html. It is there in the intermediate xml: >> >> >> >> OSX >> >> >> Question: >> >> Does this mean that it never has been added to the html rendering (ie >> various skins/default html transform), or that it really should not be part >> of the content model for the title element? The same question is valid also >> for the remaining title subelements. >> >> Grateful for feedback. >> >> Sjur >> >>
Title element content in v2 docs
Hello all, I just noticed a discrepancy between the dtd and the actual rendering in the default (and possibly all) skins for the title element. The DTD says: title Element name title Content model ( #PCDATA | strong | em | code | sub | sup | a | br | img | icon | acronym | map ) * Attributes id type: ID class type: CDATA xml:langtype: NMTOKEN Used inside header | section I then tried to add an img element inside title, but it is removed during the transformations to html. It is there in the intermediate xml: OSX Question: Does this mean that it never has been added to the html rendering (ie various skins/default html transform), or that it really should not be part of the content model for the title element? The same question is valid also for the remaining title subelements. Grateful for feedback. Sjur
Re: Experimenting with a bootstrap-based skin
12. feb. 2015 kl. 08:40 skrev David Crossley : > > Wow, this is nice. Thanks :) > It seems better than when i looked the other day. Yeah, we had a build bug that caused elements of the old skin to reappear mixed in with the new skin. It was corrected two days ago. > The top-level navigation collapses beautifully when i narrow the browser > window. > The second-level tabs are behaving properly. > However not on the front page, for example the "Events" tab. We are aware of it, we need to do some more work on organising the tabs and the left menu. > Anyway, great stuff. :) Sjur
Experimenting with a bootstrap-based skin
Hello all, As part of improving our web site, a colleague of mine made a first stab at creating a boostrap based skin. The result can be seen at divvun.no. So far the skin is only in our own svn repo, but if successful, the intention is to make it available to the Forrest community. Known issues: * Several features of Forrest are not yet supported, such as warning and note elements (they will be rendered roughly as regular p elements). * most of the menu items and tabs are presently untranslated * it has the same inflexibility as other skins (but Dispatcher has turned out to be way to heavy, memory consuming and slow for our purposes, so that is not an option) BTW, the i18n implementation you find there is a post-processing hack, due to the lack of i18n support in the Cocoon/Forrest CLI. We build the static site once for each locale, and then merge them into one site while injecting the language choice menu. We need the static version, as Forrest is not stable enough to be run dynamically (at least not in our case). Feedback is welcome. Sjur
Re: buildbot failure in ASF Buildbot on forrest-trunk
26. nov. 2014 kl. 05:08 skrev David Crossley : > > On Tue, Nov 25, 2014 at 10:45:26PM +0100, Sjur Moshagen wrote: >> 25. nov. 2014 kl. 22:33 skrev David Crossley : >>> I had a similar problem back on September 14. See the logs above. >>> The next day it came good all by itself. >> >> Thanks for the follow-up. I am kind of hoping that it will disappear by >> itself also this time, we’ll see tomorrow. > > I just triggered it with another commit, and now it is happy. > No idea why. Strange - good that it is happy, anyway. And thanks for adding my change to the status.xml file - should have remembered that. Sjur
Re: buildbot failure in ASF Buildbot on forrest-trunk
25. nov. 2014 kl. 22:33 skrev David Crossley : > > On Tue, Nov 25, 2014 at 03:18:39PM +0100, Sjur Moshagen wrote: >>> program finished with exit code 0 >>> elapsedTime=0.017328 >>> program finished with exit code 1 >>> program finished with exit code 0 >> >> The process before (svn --version) ends with a normal exit code, and the >> same for the following process. That is, one single, anonymous process did >> not end successfully, but everything else did. >> >> How come? > > I do not know either. Something about "corrupted xml". > > I had a similar problem back on September 14. See the logs above. > The next day it came good all by itself. Thanks for the follow-up. I am kind of hoping that it will disappear by itself also this time, we’ll see tomorrow. > If not, then perhaps need to contact Infrastructure. > I am not sure how, but start here: > http://ci.apache.org/#buildbot Ok. Sjur
Re: Improving the localisation of the search box
25. nov. 2014 kl. 22:14 skrev David Crossley : > > On Tue, Nov 25, 2014 at 02:46:32PM +0100, Sjur Moshagen wrote: >> With no objections so far, and this being the 0.10-dev code base, I think it >> is ok to disregard older browsers for now. > > That is a good approach. > > Yes, i was going to suggest option two too. Thanks a lot for the feedback :) Sjur
Re: buildbot failure in ASF Buildbot on forrest-trunk
25. nov. 2014 kl. 15:07 skrev build...@apache.org: > > The Buildbot has detected a new failure on builder forrest-trunk while > building ASF Buildbot. Full details are available at: >http://ci.apache.org/builders/forrest-trunk/builds/17 > > Buildbot URL: http://ci.apache.org/ > > Buildslave for this Build: lares_ubuntu > > Build Reason: The AnyBranchScheduler scheduler named 'on-forrest-commit' > triggered this build > Build Source Stamp: [branch forrest/trunk] 1641622 > Blamelist: sjur > > BUILD FAILED: failed > > Sincerely, > -The Buildbot Thank you, Buildbot! Except that I do not understand what has gone wrong. In the log file for the failed process, the only fail is logged as follows: > program finished with exit code 0 > elapsedTime=0.017328 > program finished with exit code 1 > program finished with exit code 0 The process before (svn --version) ends with a normal exit code, and the same for the following process. That is, one single, anonymous process did not end successfully, but everything else did. How come? Sjur
Re: Improving the localisation of the search box
24. nov. 2014 kl. 16:59 skrev Sjur Moshagen : > Question/viewpoints requested: > > Is this important enough that we want to find a JS solution for older > browsers? I tried one, but couldn’t get it going (that might well be because > of my non-existent JS knowledge). > > OR: > > Would it be ok to drop support for older browsers in this case? It just means > that there won’t be any lead text/placeholder text in the search field, it > will just be plain white instead. With no objections so far, and this being the 0.10-dev code base, I think it is ok to disregard older browsers for now. Sjur
Improving the localisation of the search box
Hello all, I am looking at improving the localisation support of the search box, but am running into a backwards compatibility wall. Here’s the situation: * the old code added placeholder text to the search field to guide users as to what the search will do * it also contained a simple js to clear the field upon text input * the old code didn’t work with the i18n setup, so the placeholder text would always be in English * modern browsers have support for @placeholder: * using this attribute, the placeholder text works exactly as intended, including i18n and l10n * … EXCEPT for IE9 and older, in which case the search field will be just empty Question/viewpoints requested: Is this important enough that we want to find a JS solution for older browsers? I tried one, but couldn’t get it going (that might well be because of my non-existent JS knowledge). OR: Would it be ok to drop support for older browsers in this case? It just means that there won’t be any lead text/placeholder text in the search field, it will just be plain white instead. WDYT? This is tested with the Pelt skin, but the code changes are small and should portable to all skins without issues. Sjur
Re: The Forrest feels like home
Welcome back! :) Sjur > 14. nov. 2014 kl. 03:05 skrev Ross Gardler (MS OPEN TECH) > : > > It’s been many many years since I was in the Forrest, but it feels like home. > Hello folks J > > I’m re-evaluating Forrest for a small project I have. After searching far and > wide there still isn’t a solution for my use case other than Forrest. So I’ve > re-subscribed to the dev list, more out fond memories than any intention to > contribute again – though if I do use it on this project who knows… > > My first comment – damn this community documented Forrest well :-D > > Ross
Re: Customizing a website using forrest 0.10-dev and dispatcher
11. sep. 2014 kl. 18:52 skrev Vicent Mas : > I've done it but I get a "Resource not found error". Anyway I've found > the xml version of the document and the content seems to correspond to > the document I mention above. The document talks about an > org.apache.forrest.themes.core plugin that I'm unable to find This was a plugin that was later moved into the Dispather plugin, see https://issues.apache.org/jira/browse/FOR-1213. You should not use it :) Sjur
Re: Javascript mime type
Den 24. jan 2013 kl. 22:33 skrev Tim Williams: > On Thu, Jan 24, 2013 at 4:32 PM, Tim Williams wrote: >> On Thu, Jan 24, 2013 at 4:25 PM, Sjur Moshagen wrote: >>> According to this page: >>> http://stackoverflow.com/questions/4101394/javascript-mime-type >>> and many others on the net, application/javascript is the correct answer, >>> but not accepted by MS IE ≤ 8. Which leaves us with text/javascript. But >>> several places (including the above) argues that leaving it empty is fine, >>> and the most compatible. I have no strong opinions, though, just that the >>> present mime type definitely is wrong :) >> >> I'd go with text/javascript - it's a reasonable default. Agrre, I'll commit. >> It's worth >> noting that we serve it as 'application/javascript' because that's the >> default mime-type mapping for httpd[1]. > > Ooops.. dangling pronoun:( "we" == forrest.apache.org :) :) Sjur
Re: Javascript mime type
According to this page: http://stackoverflow.com/questions/4101394/javascript-mime-type and many others on the net, application/javascript is the correct answer, but not accepted by MS IE ≤ 8. Which leaves us with text/javascript. But several places (including the above) argues that leaving it empty is fine, and the most compatible. I have no strong opinions, though, just that the present mime type definitely is wrong :) Sjur Den 24. jan 2013 kl. 22:12 skrev Tim Williams: > I'd say text/javascript or application/javascript is the right answer. > Omitting it feels pretty wrong though. > > --tim > > On Thu, Jan 24, 2013 at 4:01 PM, Sjur Moshagen wrote: >> Hello, >> >> In the file '$FORREST_HOME/main/webapp/resources.xmap' there's the following >> match: >> >> >>> /> >> >> >> x-javascript looks kind of strange and old. This is what wikipedia has to >> say about javascript mime type >> (http://en.wikipedia.org/wiki/Internet_media_type): >> >> «• application/javascript: ECMAScript/JavaScript; Defined in RFC 4329 >> (equivalent to application/ecmascript but with looser processing rules) It >> is not accepted in IE 8 or earlier - text/javascript is accepted but it is >> defined as obsolete in RFC 4329. The "type" attribute of the
Re: Deploying wiki plugin (I can't)
Hello again, Den 18. jan 2013 kl. 15:04 skrev Sjur Moshagen: > Hello all, > > Could some developer be kind and run 'ant deploy' in > $FORREST_HOME/plugins/org.apache.forrest.plugin.input.wiki/ ? I have issues > with my own instance of Forrest, and am not able to get a clean deploy > through. There should be no issues with the plugin though. Request canceled. I managed to deploy the updated wiki plugin (as seen by the svn mails) by checking out a fresh copy of forrest, with no local modifications. I have tested the deployed plugin with different versions of forrest (svn HEAD and latest official release), and both are able to find the deployed plugin. It seems everything is fine. Sorry for the noise. Best, Sjur
Deploying wiki plugin (I can't)
Hello all, Could some developer be kind and run 'ant deploy' in $FORREST_HOME/plugins/org.apache.forrest.plugin.input.wiki/ ? I have issues with my own instance of Forrest, and am not able to get a clean deploy through. There should be no issues with the plugin though. I need the latest dev version of that plugin online as soon as possible, so that I can start to rely on the availability of the new features for my colleagues. Thanks a lot in advance, Sjur
Re: Suggested changes to wiki plugin
Den 17. jan 2013 kl. 02:08 skrev David Crossley: > Sjur Moshagen wrote: >> * I added support for definition lists (terms + definition), but *NOT* in >> accordance with the jspwiki spec >> >> The reason for not following the spec was that I could not get the Chaperon >> grammar (which is used to parse the jspwiki document and convert it to xml) >> to accept the syntax used by jspwiki. I don't know why, but to me it looks >> like a bug in the Chaperon lexer. >> >> The jspwiki syntax is: >> >> ; Term : definition > > I wonder if it is the "space" characters. The reference [1] shows no spaces. It turned out to be a missing feature in the grammar. I have now implemented it, and it behaves as expected. I had to both tinker a bit with the grammar, and resolve some abiguity afterwards in the xsl processing (it is impossible for the tokeniser to know that a ':' at the end of a word is *not* a term definition separator, so I had to reconnect it to the preceding text if it was not inside an already established definition list). Thanks for following up, it inspired me to try once more, and that fixed it :) >> * it is said in the wiki plugin docs that we should keep the sources in sync >> with the Cocoon 2.1 block - but does that even apply for the syntax-breaking >> changes? > > I reckon so. There is not enough activity to warrant separate versions. Ok, I will do that soon. Sjur
Suggested changes to wiki plugin
Hi all, I needed to fix some bugs (or missing features) in the wiki plugin, to better cope with the jspwiki format. So far I have only stored the changes locally in my project folder (thus the previous commit to fix the locationmap for finding resource files). Now I would like to move the changes to the plugin, but there are one change that I would like feedback on before I do this. The changes I have made are these: * I added support for formatting and links within table cells, so that tables now should behave as the jspwiki spec [1] says * I added support for definition lists (terms + definition), but *NOT* in accordance with the jspwiki spec The reason for not following the spec was that I could not get the Chaperon grammar (which is used to parse the jspwiki document and convert it to xml) to accept the syntax used by jspwiki. I don't know why, but to me it looks like a bug in the Chaperon lexer. The jspwiki syntax is: ; Term : definition My syntax is: #; Term ##: definition Not as elegant, but it works, and my implementation allows for links, formatting and breaks within the definition (which should be in accordance with the jspwiki syntax). Now the question(s): * is it ok with you if I commit these changes, even though one is with a different syntax than expected? I will of course update the documentation accordingly * it is said in the wiki plugin docs that we should keep the sources in sync with the Cocoon 2.1 block - but does that even apply for the syntax-breaking changes? Best regards, Sjur [1] http://www.jspwiki.org/wiki/TextFormattingRules
Re: [VOTE] re-release version 0.9
Slightly late: +1 $ md5 apache-forrest-0.9-sources.tar.gz MD5 (apache-forrest-0.9-sources.tar.gz) = 2bc9e0b220f8ec5bc1f228dbc3023e0e $ md5 apache-forrest-0.9-dependencies.tar.gz MD5 (apache-forrest-0.9-dependencies.tar.gz) = 7752ee4f85066dd7a0901c06c5949c9d Sjur
Re: bootstrap
Den 22. mar. 2012 kl. 14.03 skrev Thorsten Scherler: > On 03/22/2012 03:08 AM, Tim Williams wrote: >> I've been playing with bootstrap[0] lately, I'm thinking it could >> freshen up our heavy look. :) Bootstrap looks nice, and I like the usage of LESS. >> Is anyone interested in helping? Or >> perhaps a part of a rewrite? I've used it for the barcamp site[1] - >> it naturally scales to different devices as well. Device scaling would be both nice and a natural requirement for forrest sites these days. >> Thanks, >> --tim >> >> [0] - http://twitter.github.com/bootstrap/ >> [1] - http://events.apache.org/event/2012/barcamp-dc/ > > Yeah looks nice, further it seems to be usable as well as base for Cordova > [2]. I am interested but I am not sure how much time I could offer you > fordoing a rewrite. My situation is the same as for Thorsten and David - I don't have much time to put into it. But i will try to help. Sjur > [2] http://incubator.apache.org/callback/ > > -- > Thorsten Scherler > codeBusters S.L. - web based systems > > > http://www.codebusters.es/ >
Re: [jira] [Commented] (FOR-1188) ant test failure on forrest
Den 23. mar. 2012 kl. 12.26 skrev Cyriaque Dupoirieux: > Hi Sjur, > >Can you wait few days before to consider the issue as solved ? Sure:) >I still have the problem with ProjectInfo Plugin (I think this is the > culprit because it is the only one to use svnHelper...) > > * [3/35][0/0] 0.16s 2.0Kb linkmap.dispatcher.css > X [0] cours/attestation.html > BROKEN: D:\Cyriaque\Perso\forrest\main\webapp\.\D:\Cyriaque\Perso\Em > m\Site > Internet\build\tmp\D:\Cyriaque\Perso\forrest\build\plugins\svnHelper.xmap > (Syntaxe du nom de fichier, de r├®pertoire ou de volume inc > orrecte) Hm, this shows that the fix needs to be applied to each plugin - somehow. The next task would be to identify exactly what change in the dispatcher plugin fixed the path mis-behaviour on Windows for dispatcher (or to confirm that it was the same fix as the one applied pre the 0.9-release to other parts of forrest). Unfortunately I don't have a Windows box running close to me, so it is not straightforward for me to debug this. Sjur
Re: [jira] [Issue Comment Edited] (FOR-1188) ant test failure on forrest
Den 20. mar. 2012 kl. 15.03 skrev Thorsten Scherler: > That sounds an awful lot of an issue Gavin had back in the days. I guess the > solution is somewhere in the archives but looking at > > D:\forrest\main\webapp\D:\giellatekno\ped\build\tmp\d:\forrest\build\plugins\dataModel.xmap > (The filename, directory name, or volume label syntax is incorrect) > > > It seems the path is not resolved correct > > D:\forrest\main\webapp\D:\g... No it is not. But the issue has been resolved. The solution was to update to the latest svn trunk. But we need to remember that we have an issue with Forrest 0.9 on Windows and dispatcher, at least in some cases (too many variables in what we saw to pinpoint the exact cause of the bug). I'll update Jira as well. Sjur
s5 output plugin for Forrest
Hello Ross, In the thread [1] the issue of moving the s5 plugin somewhere else was mentioned. The Forrest whiteboard is blocked due to licensing issues, but I could probably find a home for it at work - we have an open repository at https://victorio.uit.no/langtech/. If someone has other suggestions, that is of course all very well (our svn repository is probably not the best place since getting commit access requires manual set-up). Would moving it to a new home be ok with you? (I see that the burrokeet sf site you mentioned in an old discussion as a possible home hasn't been active for over 500 days - that site is probably not the best one either, anymore - if it is still a possibility, my sf username is 'moshagen'). Also, the s5 plugin as it stands does not fit my needs that well, and I would like to rewrite it from the bottom, more or less. In practice, I would probably create a new plugin, but based on your work (yes, I am aware of the w3c slides vs s5 discussions), with proper credits of course. Would that be ok as well? Best regards, Sjur N. Moshagen Samediggi · Sametinget Project Manager for the Divvun project http://www.divvun.no/ http://www.samediggi.no/ +358-9-49 75 29 (w) +358-505 634 319 (m) [1]: http://marc.info/?l=forrest-dev&m=129591307420205&w=2
Re: 404 - s5 css not found
Den 24. jan. 2011 kl. 02.35 skrev David Crossley: >> Would it be a good idea to move the plugin to the whiteboard, to make it >> easier for others to contribute? > > The reason for plugins being outside of our plugins area > is either that the developer wants to maintain it > by themself, or that there are licensing reasons. > > I reckon the latter. Might need to search the archives. I did, and it seems you are right. > Also i suggest to contact Ross as he might be interested > in someone else taking over maintenance. Ferdinand also > had a hand in developing this plugin. I'll do in a while. I played around with it, and there were several errors for making it work somewhat with the current forrest code. Now it displays, but it is still quite awkward to work with from my point of view, and with several bugs still. What I would like to have is a way to use one of the supported wiki inputs and get it transformed automatically to slides. That is possible now, but in a very unnatural way: wiki bullets disappear, and you need to use nested wiki headings to get slide bullets, where the sub-headers become bullet points. It might be easiest just to take Ross' code as a starting point, and rewrite/recreate most of the plugin into a new one that is closer to my need. Because of the license issue, I'll probably host it on our own server for the time being. Regards, Sjur
Re: 404 - s5 css not found
Den 23. jan. 2011 kl. 22.54 skrev Sjur Moshagen: > Hello all, > > I was going to try out the s5 slides plugin, but it only returnes unstyled > html. When I try to get the css directly, I get the following: > > http://people.apache.org/~rgardler/testingGround/forrestPlugins/s5/sample/s5slides/ui/s5-core.css Also: pretty.css framing.css give the same error. Sjur
404 - s5 css not found
Hello all, I was going to try out the s5 slides plugin, but it only returnes unstyled html. When I try to get the css directly, I get the following: http://people.apache.org/~rgardler/testingGround/forrestPlugins/s5/sample/s5slides/ui/s5-core.css Not Found The requested URL /~rgardler/testingGround/forrestPlugins/s5/sample/s5slides/ui/s5-core.css was not found on this server. Apache/2.2.15 (Unix) DAV/2 mod_ssl/2.2.15 OpenSSL/0.9.8k Server at people.apache.org Port 80 The plugin page seems to work ok otherwise. Would it be a good idea to move the plugin to the whiteboard, to make it easier for others to contribute? Regards, Sjur
Re: [Vote] Release Plan for Forrest 0.90
Den 14. des. 2010 kl. 01.15 skrev David Crossley: Please vote on this release plan. > > According to our guidelines, > http://forrest.apache.org/guidelines.html#actions > "A lazy majority vote requires > 3 binding +1 votes and more binding +1 votes than -1 votes". > > As usual anyone is encouraged to vote, just the votes > of PMC members are binding. +1 Sjur
Re: dispatcher compile errors
Den 3. jun. 2010 kl. 01.39 skrev David Crossley: > Sjur Moshagen wrote: >> >> Here's my output: >> >> jar: >> Building jar: >> /usr/local/forrest/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/build/org.apache.forrest.plugin.internal.dispatcher.jar > > Did you see this bug (now fixed). > https://issues.apache.org/jira/browse/FOR-1195 > "the plugins 'clean' target should remove previously built classes" > > Perhaps your's missed the "compile" phase and just re-packed the jar. > > Needs 'ant clean' beforehand. You were right. I manually deleted the whole build/ dir in dispatcher, cleaned forrest, rebuilt, cleaned by project, and reran. The relevant output was: compile: Created dir: /usr/local/forrest/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/build/classes Compiling 33 source files to /usr/local/forrest/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/build/classes Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Copying 1 file to /usr/local/forrest/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/build/classes jar: Building jar: /usr/local/forrest/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/build/org.apache.forrest.plugin.internal.dispatcher.jar local-deploy: Locally deploying org.apache.forrest.plugin.internal.dispatcher Copying 354 files to /usr/local/forrest/build/plugins/org.apache.forrest.plugin.internal.dispatcher Copied 91 empty directories to 5 empty directories under /usr/local/forrest/build/plugins/org.apache.forrest.plugin.internal.dispatcher Copying 1 file to /usr/local/forrest/build/plugins/lib Copying 14 files to /usr/local/forrest/build/plugins/lib build: Plugin org.apache.forrest.plugin.internal.dispatcher deployed ! Ready to configure Still no problems, now using HEAD of trunk. Sjur > -David > >> $ java -version >> java version "1.6.0_20" >> Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065) >> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode) >> >> MacOS X 10.6.3
Re: dispatcher compile errors
Den 1. jun. 2010 kl. 04.34 skrev David Crossley: > Tim Williams wrote: >> Anyone else getting: >> >> >> compile: >>[javac] Compiling 1 source file to >> /Users/twilliams/Development/forrest/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/build/classes >>[javac] >> /Users/twilliams/Development/forrest/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/java/org/apache/forrest/dispatcher/transformation/DispatcherTransformer.java:399: >> cannot access SourceResolver >>[javac] class file for SourceResolver not found >>[javac] resolverDispatcher = new CocoonResolver(m_resolver); >>[javac] ^ >>[javac] 1 error >> >> ... in dispatcher? I'll poke around locally but wanted to see if it >> was just me since zones is apparently working fine. > > It does the "compile" phase for me okay. (Mac 10.5.8 with Java 1.5). Here's my output: jar: Building jar: /usr/local/forrest/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/build/org.apache.forrest.plugin.internal.dispatcher.jar local-deploy: Locally deploying org.apache.forrest.plugin.internal.dispatcher Copying 354 files to /usr/local/forrest/build/plugins/org.apache.forrest.plugin.internal.dispatcher Copied 91 empty directories to 5 empty directories under /usr/local/forrest/build/plugins/org.apache.forrest.plugin.internal.dispatcher Copying 1 file to /usr/local/forrest/build/plugins/lib Copying 14 files to /usr/local/forrest/build/plugins/lib That is, no problems. This is against r950069. $ java -version java version "1.6.0_20" Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode) MacOS X 10.6.3 Sjur
Re: ElemTemplateElement error: carry-body-attribs caused by r887050
Den 26. mai. 2010 kl. 06.25 skrev Brian M Dube: Sjur, you are talking about a Dispatcher-based site, correct? >>> >>> Yes, but the bug is showing up whether or not I have dispatcher >>> enabled. I stripped the plugins down to only pdf, and I still got >>> that bug. >>> Are you sure that r887050 is the cause? Remember that the svn merge of the new Dispatcher branch happened one day prior to that date, 03 December 2009. >>> >>> I know, and that was what I suspected as well. But so far r887050 >>> is the one that triggers the bug. That doesn't mean that the bug >>> hasn't been introduced earlier, but somehow was hidden until this >>> revision. >> >> I found the bug - it is on our side. It turned out that at some >> point the default skin directory tree was copied from the forrest >> code to our project code, and perhaps slightly modified. This local >> skin copy of course was not kept in sync with the improvements and >> bug fixes made to the common skin files were transfered to our local >> copy. After I updated all local files to be in sync with the Forrest >> ones, the bug disappeared. > > Out of date skins files prevented your site from building while > dispatcher was enabled? No. Out-of-date skins files prevented the site from building independently of dispatcher being enabled or not (see above). Dispatcher wasn't part of the problem at all. > And it hasn't been clear to me, does your site even use body > attributes? Only in two documents. Best, Sjur
Re: Latin1 character problems in dispatcher
Den 21. mai. 2010 kl. 12.03 skrev Thorsten Scherler: >> The text returned by that Uri is: >> >> Divvun - >> Sámi proofing tools project >> >>UTF-8 character test> class="content"> >> There seems to be problems with certain characters, but only in >> Dispatcher:http://www.w3.org/2001/XInclude"/> >> a á c č d đ n ŋ s š t ŧ z ž ae æ >> oe ø ao å a¨ ä o¨ ö g ǥ h ħ u ʉ i ɨ >> >> >> >> >> Two things to note here: >> >> The encoding is specified as ISO-8859-1, which is wrong, > > yes should be utf8. >> ... >> I don't know where the encoding comes from - everything on my end is marked >> as UTF-8. I grepped for the string "ISO-8859-1" in the Forrest sources, and >> got many hits, but nothing that seemed to relate to Dispatcher. > > The *.body.xml comes from the dataModel.xmap: > > > > > > > > > > > The serializer here is the default one. > > we define it in the xmap as > > > > That should read: > > > I added to revision 946939 please see whether that fixes the issue. I added a > test note to > org.apache.forrest.plugin.internal.dispatcher/src/documentation/content/xdocs/index.xml > so you can directly run "forrest run" in the plugin and see the outcome. I did it using my own site (the same document as earlier) - and your change FIXED the bug:) All instances of garbled utf-8 characters are now fixed, both in the body text, and elsewhere. Thanks a lot! Best, Sjur
Re: Latin1 character problems in dispatcher
Den 20. mai. 2010 kl. 15.26 skrev Thorsten Scherler: > On 20/05/2010, at 14:18, Sjur Moshagen wrote: >>> ... >>> Hmm, that is weird. Please try the following: >>> - add a new contract that uses ñ, í and similar characters >>> - see what comes out >> >> I added a blank contract that just printed the same line of characters I >> used earlier for testing, and this is what came out: >> >> This is a text containing problematic characters: >> a á c č d đ n ŋ s š t ŧ z ž ae æ oe ø ao å a¨ ä o¨ ö g ǥ h ħ u ʉ i ɨ >> >> That is, the text from the contract comes through just fine, but text coming >> from a standard Forrest v2 document gets garbled. >> >> I have attached a picture of the page as it renders. The box comes from the >> document, the text at the bottom is from the contract. > > Ok I see. > > Please post the dataUri you use for the contract. It seems that the utf-8 is > lost in this step. If you have the dataUrl of the contract see what is coming > out there, whether it is already scrambled or not. I'm not sure about how to do this, but I'll try. The dataUri used in the structurer is: <-- this is the dataURI which I take to mean: http://localhost:/index.body.xml The text returned by that Uri is: Divvun - Sámi proofing tools project UTF-8 character test There seems to be problems with certain characters, but only in Dispatcher:http://www.w3.org/2001/XInclude"/> a á c č d đ n ŋ s š t ŧ z ž ae æ oe ø ao å a¨ ä o¨ ö g ǥ h ħ u ʉ i ɨ Two things to note here: The encoding is specified as ISO-8859-1, which is wrong, and which leads to all characters outside Latin1 to be encoded as numeric entities. In the next step, this causes all non-ASCII, non-Latin1 characters to survive correctly, while the Latin1 chars will be messed up when they are reinterpreted as UTF-8 later - or something along these line. I don't know where the encoding comes from - everything on my end is marked as UTF-8. I grepped for the string "ISO-8859-1" in the Forrest sources, and got many hits, but nothing that seemed to relate to Dispatcher. Sjur
Re: Latin1 character problems in dispatcher
Den 20. mai. 2010 kl. 14.51 skrev Thorsten Scherler: > > On 20/05/2010, at 13:15, Sjur Moshagen wrote: > >> Den 20. mai. 2010 kl. 13.56 skrev Thorsten Scherler: >> >>> Are you using the latest head revision, because I had a similar usecase and >>> after the fix it works fine. >>> >>> Make sure you did a clean before building again. >> >> Just to double check, I did the following in $FORREST_HOME: >> >> $ svn up >> $ cd main/ >> $ ./build.sh clean >> $ ./build.sh >> >> I then switched to my project, and did: >> >> $ forrest clean >> $ forrest run -Dforrest.jvmargs="-Dfile.encoding=utf-8" >> >> I also tried with regular 'forrest run'. >> >> The result is still the same - Latin1 chars are not rendered. > > Hmm, that is weird. Please try the following: > - add a new contract that uses ñ, í and similar characters > - see what comes out I added a blank contract that just printed the same line of characters I used earlier for testing, and this is what came out: This is a text containing problematic characters: a á c č d đ n ŋ s š t ŧ z ž ae æ oe ø ao å a¨ ä o¨ ö g ǥ h ħ u ʉ i ɨ That is, the text from the contract comes through just fine, but text coming from a standard Forrest v2 document gets garbled. I have attached a picture of the page as it renders. The box comes from the document, the text at the bottom is from the contract. > further can you open a terminal and tell me what the output of "locale" are? $ locale LANG="no_NO.UTF-8" LC_COLLATE="no_NO.UTF-8" LC_CTYPE="no_NO.UTF-8" LC_MESSAGES="no_NO.UTF-8" LC_MONETARY="no_NO.UTF-8" LC_NUMERIC="no_NO.UTF-8" LC_TIME="no_NO.UTF-8" LC_ALL="no_NO.UTF-8" Sjur
Re: Latin1 character problems in dispatcher
Den 20. mai. 2010 kl. 13.56 skrev Thorsten Scherler: > Are you using the latest head revision, because I had a similar usecase and > after the fix it works fine. > > Make sure you did a clean before building again. Just to double check, I did the following in $FORREST_HOME: $ svn up $ cd main/ $ ./build.sh clean $ ./build.sh I then switched to my project, and did: $ forrest clean $ forrest run -Dforrest.jvmargs="-Dfile.encoding=utf-8" I also tried with regular 'forrest run'. The result is still the same - Latin1 chars are not rendered. Sjur
Re: Latin1 character problems in dispatcher
Den 20. mai. 2010 kl. 12.48 skrev Thorsten Scherler: > On 20/05/2010, at 11:30, Sjur Moshagen wrote: > >> Hi all, >> >> There seems to be certain problems with Dispatcher and the non-ascii >> characters in the Latin 1 range. The following two screenshots illustrate >> the problem: >> >> Skins-based site: >> >> >> Dispatcher-based site: >> >> >> As you can see, it is not generally UTF-8 characters, it seems to effect >> only those characters that are in the Latin1 set. >> >> This is with the latest Forrest trunk, I haven't yet checked which revision >> introduced this bug. >> > > that should be fixed with FOR-1194. Make sure your contract and the > structurer is utf-8. They should be utf-8 all of them, they have the xml declaration: > How are you producing the boxes? I'm using the following Forrest-doc v2 code: http://forrest.apache.org/dtd/document-v20.dtd";> Divvun - Sámi proofing tools project There seems to be problems with certain characters, but only in Dispatcher: a á c č d đ n ŋ s š t ŧ z ž ae æ oe ø ao å a¨ ä o¨ ö g ǥ h ħ u ʉ i ɨ stored in an utf-8 encoded file. >> MacOS X 10.6.3 >> > > I had the same problem on a mac, our company blog is utf-8 and has some > characters like ¿ñ so in FOR-1194 I forced the use of UTF-8. ok. despite this, I still get the bug, after having checked the contract and structurer files. Sjur
Latin1 character problems in dispatcher
Hi all, There seems to be certain problems with Dispatcher and the non-ascii characters in the Latin 1 range. The following two screenshots illustrate the problem: Skins-based site: <> Dispatcher-based site: <> As you can see, it is not generally UTF-8 characters, it seems to effect only those characters that are in the Latin1 set. This is with the latest Forrest trunk, I haven't yet checked which revision introduced this bug. MacOS X 10.6.3 java version "1.6.0_20" Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode) Best, Sjur
Re: ElemTemplateElement error: carry-body-attribs caused by r887050
Den 13. mai. 2010 kl. 15.36 skrev Sjur Moshagen: > Den 13. mai. 2010 kl. 11.50 skrev David Crossley: >> In default sites, "linkmap.html" is the first document to >> be processed. >> >> Remember that "linkmap" is a special pipeline. >> >> To help isolate the problem, try setting the "start-uri" >> to be something else (in forrest.properties) >> e.g. project.start-uri=index.html > > I will try that as soon as I have some more time. Now I got the time, and here is the result: X [0] index.htmlBROKEN: ElemTemplateElement error: carry-body-attribs I tried with a couple of other start pages as well, and they all gave the same result. >> Don't know if that is of any help. >> >> ---oOo--- >> >> Sjur, you are talking about a Dispatcher-based site, correct? > > Yes, but the bug is showing up whether or not I have dispatcher enabled. I > stripped the plugins down to only pdf, and I still got that bug. > >> Are you sure that r887050 is the cause? >> Remember that the svn merge of the new Dispatcher branch >> happened one day prior to that date, 03 December 2009. > > I know, and that was what I suspected as well. But so far r887050 is the one > that triggers the bug. That doesn't mean that the bug hasn't been introduced > earlier, but somehow was hidden until this revision. I found the bug - it is on our side. It turned out that at some point the default skin directory tree was copied from the forrest code to our project code, and perhaps slightly modified. This local skin copy of course was not kept in sync with the improvements and bug fixes made to the common skin files were transfered to our local copy. After I updated all local files to be in sync with the Forrest ones, the bug disappeared. I guess that before that specific commit, only parts of the local skin files were used, as the pre-lm solution probably didn't as thoroughly ckeck for local overrides of all files. That would explain why the site had worked before, and why not after this commit. Anyway - this is a lession to our group, and perhaps a relief regarding the Forrest code: there was no bug in Forrest:) Best regards, Sjur
Re: ElemTemplateElement error: carry-body-attribs caused by r887050
Den 13. mai. 2010 kl. 11.50 skrev David Crossley: > Brian M Dube wrote: >> Sjur Moshagen wrote: >>> >>> I'm not able to build my site anymore, due to the following error: >>> >>> X [0] linkmap.html BROKEN: >>> ElemTemplateElement error: carry-body-attribs >>> >>> I was finally able to track down the cause of the error being the commit >>> r887050. I haven't identified this earlier since I hadn't been updating my >>> Forrest instance in a while, and then didn't have time to track down the >>> error earlier. >>> >>> Tracking down ... that's kind of an overstatement, since the actual bug is >>> not found. The thing is, this bug does NOT display using a regular seed. I >>> can only trigger this bug using my own site. >> >> How is the bug triggered? > > I presume just by running 'forrest' (i.e. 'forrest site'). Yes. > In default sites, "linkmap.html" is the first document to > be processed. > > Remember that "linkmap" is a special pipeline. > > To help isolate the problem, try setting the "start-uri" > to be something else (in forrest.properties) > e.g. project.start-uri=index.html I will try that as soon as I have some more time. > Don't know if that is of any help. > > ---oOo--- > > Sjur, you are talking about a Dispatcher-based site, correct? Yes, but the bug is showing up whether or not I have dispatcher enabled. I stripped the plugins down to only pdf, and I still got that bug. > Are you sure that r887050 is the cause? > Remember that the svn merge of the new Dispatcher branch > happened one day prior to that date, 03 December 2009. I know, and that was what I suspected as well. But so far r887050 is the one that triggers the bug. That doesn't mean that the bug hasn't been introduced earlier, but somehow was hidden until this revision. Thansk for following up on this, both of you. Best regards, Sjur
ElemTemplateElement error: carry-body-attribs caused by r887050
Hello all, I'm not able to build my site anymore, due to the following error: X [0] linkmap.html BROKEN: ElemTemplateElement error: carry-body-attribs I was finally able to track down the cause of the error being the commit r887050. I haven't identified this earlier since I hadn't been updating my Forrest instance in a while, and then didn't have time to track down the error earlier. Tracking down ... that's kind of an overstatement, since the actual bug is not found. The thing is, this bug does NOT display using a regular seed. I can only trigger this bug using my own site. And this commit was a massive one, with 47 files being modified. But grepping for carry-body-attribs, there are only two matches among the modified files: a83-245-189-120:main sjur$ grep -r 'carry-body-attribs' * | grep -v '\.svn' | cut -d':' -f1 | sort -u webapp/skins/common/xslt/html/document-to-html.xsl <--- not modified webapp/skins/common/xslt/html/site-to-xhtml.xsl <--- not modified webapp/skins/pelt/xslt/html/document-to-html.xsl webapp/skins/pelt/xslt/html/site-to-xhtml.xsl and the only changes to these two files are: a83-245-189-120:main sjur$ svn diff -c 887050 webapp/skins/pelt/xslt/html/document-to-html.xsl Index: webapp/skins/pelt/xslt/html/document-to-html.xsl === --- webapp/skins/pelt/xslt/html/document-to-html.xsl(revision 887049) +++ webapp/skins/pelt/xslt/html/document-to-html.xsl(revision 887050) @@ -20,7 +20,7 @@ imported document-to-html.xsl for details. --> http://www.w3.org/1999/XSL/Transform";> - + a83-245-189-120:main sjur$ svn diff -c 887050 webapp/skins/pelt/xslt/html/site-to-xhtml.xsl Index: webapp/skins/pelt/xslt/html/site-to-xhtml.xsl === --- webapp/skins/pelt/xslt/html/site-to-xhtml.xsl (revision 887049) +++ webapp/skins/pelt/xslt/html/site-to-xhtml.xsl (revision 887050) @@ -35,7 +35,7 @@ --> http://www.w3.org/1999/XSL/Transform"; xmlns:i18n="http://apache.org/cocoon/i18n/2.1"; exclude-result-prefixes="i18n"> - + That is, using LM instead of relative paths. It seems pretty harmless, so this error puzzles me. The only explanation I can think of is that by changing to using LM refs instead of path refs, that the included file is somehow changed, ie the LM resolves differently than the previous path reference, and the new file somehow cause the bug. I also assume that the bug is related to https://issues.apache.org/jira/browse/FOR-1167 which introduced this attribute. Any comments or insights would be very appreciated. Sjur
Re: [VOTE] - Upgrade Java Version to 1.5
Den 4. mar. 2010 kl. 02.02 skrev Gav...: > This vote is to move 'trunk' to using java version 1.5. +1 Sjur
Re: ical output plugin - sitemap feedback wanted
Den 30. okt. 2009 kl. 06.43 skrev David Crossley: Sjur Moshagen wrote: skrev David Crossley: Sjur Moshagen wrote: General note: This is an excellent example of the flexibility and usefulness of Forrest. We (a project team geographically distributed) have regular meetings using voicechat software + a collaborative editor (usually SubEthaEdit because we are on Macs, but Gobby will do fine), we write in jspwiki format, ie structured, plain text (the KISS principle), which is transformed by Forrest to online meeting memos (pdf, html) and task lists in iCal format using the plugin described above. This is very interesting. Thanks so much for sharing a situation for how you use Forrest. That should encourage. :) Many thanks for adding the initial iCal output plugin Sjur. :) I had a quick look and it works for me. Nice to hear. I did a few minor tweaks and house-keeping stuff. I saw that, thanks a lot for cleaning the bits I didn't notice. There are some strange unreadable characters next to links in the *.jspwiki sample files. Those are UTF-8 encoded non-breaking spaces (NBSP). The wiki parser has some interesting whitespace processing - in some cases spaces are inserted where there were none in the source (e.g. around boldface or italic), in some cases spaces are removed, like after URL's, which makes the following text run into the URL. NBSP is treated as a regular character, and isn't touched, making the final output look like intended. We use only UTF-8, so I had forgotten to change it to Latin-1. It is changed now. I know the NBSP trick is really a hack, but I haven't had time to dig into the wiki parser code. I'm not sure the present behaviour is easily fixed. By the way, this new proposal at Apache Incubator might be of interest. [PROPOSAL] Apache OpenMeetings incubator for Web Conferencing http://markmail.org/message/aahmijcb5dsjlxiv Thanks for the pointer. Best, Sjur
Re: svn commit: r830831 - /forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.iCal/resources/stylesheets/date.add.template.xsl
Den 29. okt. 2009 kl. 05.06 skrev cross...@apache.org: Log: Removed an old copy of EXSLT file. Removed: forrest/trunk/whiteboard/plugins/ org.apache.forrest.plugin.output.iCal/resources/stylesheets/ date.add.template.xsl Thanks, David, for cleaning up the things I forgot before I committed the iCal plugin. Best regards, Sjur
Re: [jira] Commented: (FOR-1176) enable plugins to utilise stylesheets from exslt.org
Den 19. aug. 2009 kl. 16.04 skrev Thorsten Scherler: On Wed, 2009-08-19 at 10:50 +0300, Sjur Moshagen wrote: Den 19. aug. 2009 kl. 09.23 skrev Brian M Dube: Any idea on how to make the protocol 'known' to the xsl processor in Cocoon? I've been down this path once before. There is a Jira issue (somewhere; sorry, I'm just on the way to sleep) about rewriting the imports. I never had success with it. I'll look for that issue and any notes I may have. It is in: https://issues.apache.org/jira/browse/FOR-1000 But according to: http://www.mail-archive.com/u...@forrest.apache.org/msg02743.html (Thorsten Scherler) it should work. I'll continue the investigation. The puppy is in the xconf file: Source Factories section: class = "org .apache.forrest.locationmap.source.impl.LocationmapSourceFactory" name="lm"/> so that SHOULD be enough. It is defined exactly like that in main/webapp/WEB-INF/cocoon.xconf It is *not* defined in any of the cli.xconf files, nor in any other xconf files. But since it is working fine in dispatcher, the xconf file has to be ok. The problem has to be elsewhere. Best regards, Sjur
Re: [jira] Commented: (FOR-1176) enable plugins to utilise stylesheets from exslt.org
Den 19. aug. 2009 kl. 17.15 skrev David Crossley: Thorsten Scherler wrote: It should work fine everywhere. Make sure the resources are exposed via the locationmap. So Sjur, you would have an entry in main/webapp/locationmap- transforms.xml Yes. This is what I have added: Do I need a double star ** to capture also subdirs, ie following the original suggestion on using the subdir organisation of exslt.org? Best regards, Sjur
Re: ical output plugin - sitemap feedback wanted
Den 19. aug. 2009 kl. 23.25 skrev Ross Gardler: 2009/8/19 David Crossley : Comments on the URL or filename patterns? Other comments? This is exiting. That seems like a fine approach to me. I agree that it's great to see some new work here. :) I don't quite agree that the URL patterns is a "fine approach" though. But don't worry, it's a small change I am going to propose and it is backward compatible with your current scheme. :) input.xmap: forrest.properties.xml: ... Now the project can override these properties in its local forrest.properties.xml if it needs to do so, or it can leave them at their defaults for the same behaviour as your existing sitemap. Thanks for the suggestion and reminder about the xml properties, Ross. I had completely forgotten about them, even though I used them extensively in the work I did on the pdf output plugin. This will also make it easy to add other properties for more flexibility in other areas. Best regards, Sjur
Re: ical output plugin - sitemap feedback wanted
Den 19. aug. 2009 kl. 16.30 skrev David Crossley: General note: This is an excellent example of the flexibility and usefulness of Forrest. We (a project team geographically distributed) have regular meetings using voicechat software + a collaborative editor (usually SubEthaEdit because we are on Macs, but Gobby will do fine), we write in jspwiki format, ie structured, plain text (the KISS principle), which is transformed by Forrest to online meeting memos (pdf, html) and task lists in iCal format using the plugin described above. This is very interesting. Thanks so much for sharing a situation for how you use Forrest. That should encourage. :) This is very timely for me. I need to help with forming a co-operative and they will need to conduct their first meeting of distributed members. I did a net search and found some of your explanations at divvun.no ... Nice to know that our documentation is being read by someone:) will see what tips i can glean. Thanks. You are welcome:) One reason I'm turning this local adaption of Forrest into a plugin is that it needs improvements. I had hoped that the improvement process would benefit from feedback from the community - and this has already happened in the form of the suggestion from Ross about using our xml properties system (see the other reply in this thread). Also the encouragement I get from the above comments helps a lot:) Presently the ical plugin presupposes that all tasks are summarised in the last section of the document. This makes it easy to parse, xml- wise, but it has turned out to not work that well in the meetings. We basically have to maintain a status of each task at two places: under each topic we discuss, and at the end of the document. I will try to enhance the plugin to be able to automacially extract and collect all tasks for the relevant person directly from the topics' todo lists. This will make the task summary at the end superfluous - it is really only a reflection of my xsl capabilities (and time constraints) at the time when I wrote the original code. This enhancement will of course make the xsl code more complicated, but it will support a more logical meeting flow, and also encourage the use of the ical task lists by the team members. Up until now several team members have just copied the list at the end of the document, instead of using the ical feature. When there is no list to copy, they *have to* use the ical task list;) Another enhancement I plan is to add support for explicit deadlines for each task. At the moment each task is given a default execution time of one week, ie until the next meeting, which isn't very flexible. Finally, I would like to be able to generate some sort of stable ID, to make it possible to update tasks imported into calendaring apps. As it is now, each time an ical task list is imported, all tasks are added as new tasks, even though the majority of them are only updates (or even copies) of already existing tasks. I'll see what is possible within the limits of of the ical format. Best regards, Sjur
Re: [jira] Commented: (FOR-1176) enable plugins to utilise stylesheets from exslt.org
Den 19. aug. 2009 kl. 10.50 skrev Sjur Moshagen: Den 19. aug. 2009 kl. 09.23 skrev Brian M Dube: Any idea on how to make the protocol 'known' to the xsl processor in Cocoon? I've been down this path once before. There is a Jira issue (somewhere; sorry, I'm just on the way to sleep) about rewriting the imports. I never had success with it. I'll look for that issue and any notes I may have. It is in: https://issues.apache.org/jira/browse/FOR-1000 But according to: http://www.mail-archive.com/u...@forrest.apache.org/msg02743.html (Thorsten Scherler) it should work. I'll continue the investigation. It seems to be used in dispatcher, in at least the following file: whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/ resources/stylesheets/helper/variable.helper.xsl: http://apache.org/forrest/properties/1.0"; xmlns:xsl="http://www.w3.org/1999/XSL/Transform";> ... The dotdots LM string matches in one of the main locationmaps, and should resolve just fine. That is, when using dispatcher, using an lm: protocol in an xsl import seems to work just fine. The question is then: why doesn't it work in all other cases? Best regards, Sjur
Re: [jira] Commented: (FOR-1176) enable plugins to utilise stylesheets from exslt.org
Den 19. aug. 2009 kl. 09.23 skrev Brian M Dube: Any idea on how to make the protocol 'known' to the xsl processor in Cocoon? I've been down this path once before. There is a Jira issue (somewhere; sorry, I'm just on the way to sleep) about rewriting the imports. I never had success with it. I'll look for that issue and any notes I may have. It is in: https://issues.apache.org/jira/browse/FOR-1000 But according to: http://www.mail-archive.com/u...@forrest.apache.org/msg02743.html (Thorsten Scherler) it should work. I'll continue the investigation. Best regards, Sjur
Re: [jira] Commented: (FOR-1176) enable plugins to utilise stylesheets from exslt.org
Den 19. aug. 2009 kl. 09.00 skrev Sina Khakbaz Heshmati: "Sjur Moshagen" said: Den 18. aug. 2009 kl. 17.07 skrev Sjur Moshagen: Den 18. aug. 2009 kl. 16.24 skrev Thorsten Scherler: the way you call it is not correct. the above should read href="lm:/exslt-extensions/date.add.template.xsl" /> Internal Server Error Message: null ... cause unknown protocol: lm Any idea on how to make the protocol 'known' to the xsl processor in Cocoon? As far as such references are concerned in XSLT stylesheets, how about using fully qualified URLs and resolve those URLs using XML Catalogs. *At least* two reasons why this is worth considering: (1) Results in more natural XSLT stylesheets for those reading -- debugging-- the stylesheet. No-one knows what the lm: is but almost everyone knows HTTP. (2) Most XSLT stylesheets are likely to be used in alternate environments where locationmap is not necessarily present. This is not about using stylesheets, only about finding a way to look up a file that both is understandable by the xslt processor (from Cocoon, on which Forrest is built) and fits reasonably well within the existing forrest infrastructure. Best regards, Sjur
Re: [jira] Commented: (FOR-1176) enable plugins to utilise stylesheets from exslt.org
Den 18. aug. 2009 kl. 17.07 skrev Sjur Moshagen: Den 18. aug. 2009 kl. 16.24 skrev Thorsten Scherler: On Tue, 2009-08-18 at 03:42 -0700, Sjur N. Moshagen (JIRA) wrote: the way you call it is not correct. the above should read Since input modules are not available in xsl. Thanks for the clarification. That answers my question. Not fully, now that I have tested it. Here is what I get as response from Forrest with the lm:/... style import: Internal Server Error Message: null ... cause unknown protocol: lm Any idea on how to make the protocol 'known' to the xsl processor in Cocoon? Best regards, Sjur
Re: [jira] Commented: (FOR-1176) enable plugins to utilise stylesheets from exslt.org
Den 18. aug. 2009 kl. 16.24 skrev Thorsten Scherler: On Tue, 2009-08-18 at 03:42 -0700, Sjur N. Moshagen (JIRA) wrote: the way you call it is not correct. the above should read Since input modules are not available in xsl. Thanks for the clarification. That answers my question. Best regards, Sjur
ical output plugin - sitemap feedback wanted
Hello all,
For a long time our project group has been using an ical output
project module that I'm now converting to a real plugin, which I
intend to add to the whiteboard. For historical reasons, the url
pattern matched against presupposes a certain file naming scheme, as
follows:
That is, the meeting date is encoded in the filename, and the person
for which the ical file should be created is encoded in the URL in
addition to the date. Also, the filename is fixed to the pattern
"Meeting_{DATE}.xml (or actually *.jspwiki in our case). Is this ok,
or should I change to a more general pattern? One reasoning is that it
doesn't make sense to create an ical file for a non-meeting document,
and this dependency is expressed in the URL and filename patterns. But
then again, the whole plugin depends on certain conventions in the
source document, so you can anyway add non-working links (ie link to
meeting documents that do not follow these conventions).
Comments on the URL or filename patterns? Other comments?
General note:
This is an excellent example of the flexibility and usefulness of
Forrest. We (a project team geographically distributed) have regular
meetings using voicechat software + a collaborative editor (usually
SubEthaEdit because we are on Macs, but Gobby will do fine), we write
in jspwiki format, ie structured, plain text (the KISS principle),
which is transformed by Forrest to online meeting memos (pdf, html)
and task lists in iCal format using the plugin described above.
Best regards,
Sjur
Re: local-deploy on project-internal plugin
Den 24. mar. 2009 kl. 01.14 skrev Ross Gardler: The code to allow a customisable local directory is much newer than that. So you probably want to look there. Do you have any idea where that code is located? The build.xml files seemed the relevant place, and I could not find anything new and relevant there. Sjur
Re: local-deploy on project-internal plugin
Replying to myself:
Den 23. mar. 2009 kl. 14.59 skrev Sjur Moshagen:
The action on line 117 in that build file reads:
If I change this to the following:
it works ok (cf the second line, where I removed the ${plugin-name}
variable). But this would probably break the regular plugin
deployment. This file has not been touched since end of April 2007,
and bugs here would certainly have been found much earlier.
Thus it seems to me that there is inconsisten behaviour between local-
deploy of regular plugins (and whiteboard ones) and project plugins.
Can anynoe confirm this? Or am I on the wrong track?
Sjur
local-deploy on project-internal plugin
Hello all, I've started to make a new plugin for our documetation needs. I wanted to keep it in the project documentation tree (ie outside of the forrest sources), at least for the moment, so I made a 'plugins' folder in the project root dir, and started from there. So far so well. The problem came when I wanted to deploy the plugin. Here's the error message I received: local-deploy: [echo] Locally deploying MultilingualOOoDraw BUILD FAILED /usr/local/forrest/plugins/build.xml:117: /Users/sjur/gtsvn/xtdoc/sd/ plugins/MultilingualOOoDraw/MultilingualOOoDraw not found. The action on line 117 in that build file reads: What I do not understand is how I got the plugin name twice in the path. I have done this local-deploy many times from the regular plugin dirs, and have had no problems. But something seems to be going wrong when deploying from a project dir. Does anyone have any clue as to what could go on? Best regards, Sjur PS. The plugin will aggregate several language versions of the same document, and turn it into an OpenOffice Draw document, to create a multilingual brochure with pictures etc. The purpose is rather project specific, but if it can be generalised (and there is interest), I'm happy to move the code into Forrest at some more finished point in time. DS.
Re: Changes to tidy-config.txt
Den 9. mar. 2009 kl. 14.35 skrev Thorsten Scherler: I propose the following change: Index: etc/tidy-config.txt === --- etc/tidy-config.txt (revision 748122) +++ etc/tidy-config.txt (working copy) @@ -1,8 +1,9 @@ add-xml-decl: yes +char-encoding: utf8 input-xml: yes output-xml:yes indent: auto -indent-attributes: yes +indent-attributes: no indent-spaces: 2 write-back: yes preserve-entities: yes wdyt? +1 Sjur
Re: ODT template file
Hi Gavin, Sorry it took so long to answer. Den 3. okt. 2008 kl. 08.56 skrev Gavin: -Original Message- From: Sjur Moshagen [mailto:[EMAIL PROTECTED] Sent: Friday, 3 October 2008 3:22 PM To: dev@forrest.apache.org Subject: ODT template file (Was: Use of 3rd party template) Den 26. sep. 2008 kl. 14.23 skrev Gavin: I have an OSSWatch ODT file to be used as a template to use for our OOo output plugin. Can I get appropriate permissions to use the contents of this file ? Where did you put this file? I'm not able to find it. $ find . -name "*.odt" only gives: ./whiteboard/plugins/org.apache.forrest.plugin.input.odt ./whiteboard/plugins/org.apache.forrest.plugin.input.odt/src/ documentation/content/xdocs/samples/opendocument-writer.odt Hi Sjur, The 'contents' of the template which was approved I have used are the background image and styles which make up the final look and feel of the output odt file. So all this is in the odt output resources directories and is brought in to use with the xdoc-to-odt.xsl. Ok. I hoped it would be possible to override the styles and template by just adding a properly named odt template file in my project tree, but this is not the way it works, no? No, not currently, that would be nice to do and I can think of various ways in which we can move forward along that goal. :) [...] Like I say, happy to work with you on it as I know the current implementation is restrictive, but I'm on an agenda. So if you can take the lead on it I'll jump in where I can. Sorry, it was a one-time use-case, which was more easily solved in other ways. Which means that I have no direct use for it anymore, and I'm short of time (as most people, admittedly). But your notes are important for future work, if somebody would like to pick up the thread. Thanks for your effort in the thorough reply:) Best regards, Sjur
ODT template file (Was: Use of 3rd party template)
Den 26. sep. 2008 kl. 14.23 skrev Gavin: I have an OSSWatch ODT file to be used as a template to use for our OOo output plugin. Can I get appropriate permissions to use the contents of this file ? Where did you put this file? I'm not able to find it. $ find . -name "*.odt" only gives: ./whiteboard/plugins/org.apache.forrest.plugin.input.odt ./whiteboard/plugins/org.apache.forrest.plugin.input.odt/src/ documentation/content/xdocs/samples/opendocument-writer.odt I hoped it would be possible to override the styles and template by just adding a properly named odt template file in my project tree, but this is not the way it works, no? Best regards, Sjur
Re: Conditional locations and i18n
Den 23. sep. 2008 kl. 18.58 skrev Ross Gardler: I recently reverted a patch by Sjur because I broke backwards compatibility. See [1] I just found myself searching for that in the archives so I could point a colleague to it. I discovered that Sjur had made a proposal for an alternative patch as follows: [snip] Sjur, sorry I have not responded. I can't find the email anywhere on my machine. Not sure what happened to it. The problem I see with this is that a site with i18n turned on and the desire to retrieve content remotely will still fail. Agree. This will not affect my sites (non have i18n turned on) but it may affect other peoples sites. I'm happy to reduce my -1 to a -0 for your proposed solution. I can't help thinking there is a better way though, perhaps a property local to the wiki plugin telling it whether it should allow i18n requests. The default would be no i18n to maintain backward compatibility. :D It is as if you read my mind - this is exactly what I have been thinking myself: A double condition, where the i18n property alone is not enough. Only when specifically requested for (using a plug-in specific property) in an otherwise i18n site would my modification/ i18n-based page serving be used. A long time ago I looked at using the locationmap to handle internationalisation. It never happened because I had no use case for it and it seems the current i18n solution was sufficient. I wonder if this is the first use case we have where it is not sufficient. What would be the benefit compared to the i18n matcher already available in Cocoon (and thus Forrest)? Ross [1] http://markmail.org/message/orpwr7kfivdi7iso Best regards, Sjur
Re: overrides of forrest:properties/forrest:propery in contracts
Den 18. sep. 2008 kl. 14.48 skrev Gavin: But that didn't work, the one in the panel came through. What am I doing wrong? I could not find any relevant info on the forrest site or in the mail archives. Usually to override them, recreate the tree in your project and just copy and change the files you want to there. so yourproject/src/documentation/resources/themes/common/panels/common- fo.panel .xml In the old skins-based system you would modify skinconfig.xml, and in dispatcher you would copy and change this panel file. To me this looks like overkill in both case, but more so in the dispatcher. What would it take to actually make it possible to do what I did, ie just set the properties I want in the forrest.properties.xml file? Best regards, Sjur
Re: overrides of forrest:properties/forrest:property in contracts
Den 18. sep. 2008 kl. 14.28 skrev Sjur Moshagen: [...] put in the following in my forrest.properties.xml file: 2004 Divvun http://Divvun.no Atterhald om alle rettar. © That should of course be: ... (no namespace). But that didn't work, the one in the panel came through. What am I doing wrong? Still no luck after removing the namespace. Sjur
overrides of forrest:properties/forrest:propery in contracts
Hello all, In whiteboard/plugins/org.apache.forrest.themes.core/themes/common/panels/ common-fo.panel.xml (and elsewhere) there are several contracts with properties like: 2002 ACME http://ACME.org Tous droits réservés. Now, I would like to override this, and I thought I could just put in the following in my forrest.properties.xml file: 2004 Divvun http://Divvun.no Atterhald om alle rettar. © But that didn't work, the one in the panel came through. What am I doing wrong? I could not find any relevant info on the forrest site or in the mail archives. Best regards, Sjur
Re: svn commit: r691518 - /forrest/trunk/plugins/org.apache.forrest.plugin.input.wiki/input.xmap
Den 12. sep. 2008 kl. 00.24 skrev Ross Gardler: [EMAIL PROTECTED] wrote: Author: sjur Date: Tue Sep 2 22:35:58 2008 New Revision: 691518 URL: http://svn.apache.org/viewvc?rev=691518&view=rev Log: Added i18n matching to the source file lookup, thus allowing l10n of page content for wiki-format pages: somedoc.en.jspwiki somedoc.es.jspwiki etc can be used to serve localised content using the simple markup format of wikis. Also added some comments. We have used this setup for jspwiki for months at our site, so should work without problems. But it is not tested for the other wiki formats. -1 This causes problems when pulling content from a live wiki rather from a local server. I'm reverting this change until we find a workaround for this as it just broke about a dozen sites for me. I'm very sorry for that :( I strongly suspect this was the problem Pablo was desribing on the user list as well in which he reported it worked with local files but not remote files. (NB Pablo is with our team for a few months so I'll try this with him tomorrow) Apologies to Pablo as well. Would a conditional sitemap along the lines of the following be a possible solution? That is, do as before unless i18n has been turned on in forrest.properties. WDYT? Best regards, Sjur
Re: i18n message catalogue filename convention
Den 11. sep. 2008 kl. 12.53 skrev Thorsten Scherler: On Thu, 2008-09-11 at 12:48 +0300, Sjur Moshagen wrote: Any comments to the proposed naming scheme before I proceed? Looks good, we need to document this naming convention. I'll try to do that as soon as the new i18n convention is implemented. Best regards, Sjur
Re: [STATUS] [heads-up] merging our branch Cocoon-2.1
Den 11. sep. 2008 kl. 12.40 skrev David Crossley: The new trunk using Cocoon-2.1 is working fine on these systems: Ubuntu - okay Mac OS X Tiger - okay Solaris10 - okay forrest run tested on MacOS X Leopard - okay (can't test forrest site in my project, because of known i18n issues with the CLI, but I would be surprised if the results differ from Tiger) Sjur
i18n message catalogue filename convention
Hello all, So far the built-in support for i18n is only done for HTML output. The files are called CommonMessages_LOCALE.xml. The problem is that the name is misleading, since the messages/strings in those files are really not common to other output formats than HTML. Also, all string translation there is is now done in core. I suggest that the string translations of plugins will be moved into each plugin, which necessitates that the translation files get unique names to avoid clashes (for example in a project translation override/ enhancement). I would therefore like to propose the following naming scheme for string translation files: [Output/Internal/Theme][PluginName]Messages_LOCALE.xml That will give filenames of the type: OutputHTMLMessages_en.xml OutputPDFMessages_en.xml etc. i18n is most relevant for the output, but I wouldn't like to exclude other types of plugins in the naming convention, just in case. HTML output is strictly speaking not produced by a plugin (except in the case of dispatcher), but it is nevertheless treated like that in this naming scheme. Any comments to the proposed naming scheme before I proceed? Best regards, Sjur
i18n message catalogue in dispatcher and skins
Hello all,
I'm starting on the next step to make the pdf plugin fully i18n -
support for i18n text.
To that extent I have a couple of questions:
1.
In $FORREST_HOME/main/webapp/sitemap.xmap, the following lines are
found:
src="org.apache.cocoon.transformation.I18nTransformer">
location="{properties:skins-dir}common/translations"/>
true
Why is the path to the message catalogue "soft-coded" to the project
instead of using a LM?
2.
Dispatcher has its own set of translations in
$FORREST_HOME/whiteboard/plugins/o.a.f.plugin.internal.dispatcher/
resources/stylesheets/common/translations/
The files there seem to be exact copies of the ones in
$FORREST_HOME/main/webapp/skins/common/translations/
Any reason for the duplication? Why not use the skins catalogue?
3. Both dispatcher and skins seem to prefer translations in the
project tree. Why is that? To ease setup for new languages for new
users (understandable)? It would still be quite easy to use some LM to
fall back to a message catalogue in forrest if not found in the
project, and just tell users to copy the files into the proper project
folder if needed (ie when needing support for a language not yet
included in Forrest).
Basic point for all these questions:
now we have copies of the same info all over the place, and most is
not used - I would like to remove all the unnecessary ones, and use LM
in all cases - and remove the messages from the seed. As part of that
I would like to update the user documentation for i18n as well, to
make sure it reflects the current state and how to set up proper i18n
support, as well as how to add new languages to the translation
catalogue.
WDYT?
Best regards,
Sjur
Re: [Vote] Move output.inputModule into core
Den 10. sep. 2008 kl. 01.09 skrev Thorsten Scherler: Please vote if you are in favor to move the code into core. +1 Sjur
Re: PDF plugin update
Den 9. sep. 2008 kl. 14.47 skrev David Crossley: Adding the output.inputModule to the list of required plugins should fix it. That is it. Fixed now. So that will be problematic, as everyone will need to add that. IIRC there was talk of deploying that plugin by default. Need to raise an issue to remind us. The idea we discussed was to move the plugin functionality into core, the sooner the better, and at latest before the 0.9 release. I have created FOR-1103[1] to capture that. Best regards, Sjur [1] https://issues.apache.org/jira/browse/FOR-1103
Re: PDF plugin update
Den 9. sep. 2008 kl. 12.12 skrev David Crossley: Sjur Moshagen wrote: Otherwise, pdf generation in dispatcher is working fine again, and now with full user control over the font families used :D Thanks for your efforts. It works for me in skins-mode and dispatcher-mode for the 'forrest seed' site. So shall i switch the cron job back on our our zones server? As soon as the below problem is gone, yes:) However there is something wrong in our "site-author". I get the following for any PDF ... See my other reply. Best regards, Sjur
Re: PDF plugin update
Den 9. sep. 2008 kl. 12.49 skrev Jeremias Maerki: More specifically, removing the line: in output.xmap makes the problem go away. But then, the font customizatinos don't make it into the FO. Don't know how to deal with this. Removing that line - OR: add the following to forrest.properties, project.required.plugins: org.apache.forrest.plugin.output.inputModule On 09.09.2008 11:12:36 David Crossley wrote: Sjur Moshagen wrote: Otherwise, pdf generation in dispatcher is working fine again, and now with full user control over the font families used :D Thanks for your efforts. It works for me in skins-mode and dispatcher-mode for the 'forrest seed' site. So shall i switch the cron job back on our our zones server? However there is something wrong in our "site-author". I get the following for any PDF ... ... Caused by: org.apache.fop.fo.ValidationException: Error(Unknown location): fo:page-sequence is missing child elements. Required Content Model: (title?,static-content*,flow) ... I did 'svn update -r ##' backwards until i found a working version. The break came with r691220, which was your main recent commit. The problem is that localhost:/index.fo for example just gives "Resource Not Found". All is fine doing that in a "seed site". Strange. I updated the seed-site to contain the required plugin, but forgot to change other sites. Adding the output.inputModule to the list of required plugins should fix it. Best regards, Sjur
PDF plugin update
Hello all, The dispatcher work on the pdf plugin update is almost completed, almost all templates have now been updated to use the new font family properties. There are still two issues: $rootFontFamily - I have found no counterpart to this in the dispatcher. The variable is used on the fo:root element, and sets the default font family for the whole pdf document $versionFontFamily - the version info found in the skins are not available in dispatcher as far as I could see. Perhaps this needs a new template/contract? Otherwise, pdf generation in dispatcher is working fine again, and now with full user control over the font families used :D Best regards, Sjur
Re: FOPNGSerializer and utf-8
Den 5. sep. 2008 kl. 08.34 skrev Sjur Moshagen: BTW the thread is pointing out FOR-132, are they related? I didn't know about that bug, but yes, that is it. I'll comment on that bug. I know see that I have commented myself in that bug - but that was over 4 years ago. My memory is much shorter than that :) Sjur
Re: FOPNGSerializer and utf-8
Den 5. sep. 2008 kl. 00.53 skrev Thorsten Scherler: Hi all, I stumbled over an old problem on the solr mailing list: http://solr.markmail.org/search/?q=forrest#query:forrest+page:1 +mid:ufocogvqrvrrg75c+state:results To pin down the problem: http://lucene.apache.org/solr/who.html shows Otis Gospodnetić http://lucene.apache.org/solr/who.pdf shows Otis Gospodneti# Have a look at http://forrest.apache.org/who.pdf there you will find "Brian M. Dubé" which is perfectly preserved. I guess it is because the different character set It is rather because of the glyph repertoir in the font being used by the FOPNGSerializer - if there is no glyph for the requested character in the font, it will come out as #, a square, a question mark, or nothing (# in the case above). and the solution probably is the work that Sjur is currently conducting. Yes :) BTW the thread is pointing out FOR-132, are they related? I didn't know about that bug, but yes, that is it. I'll comment on that bug. Has somebody a tip how I can fix it? Use the latest SVN version of Forrest, and use the pdf plugin coming with the sources (not the one on the web). This will work for Skins- based sites, and basic pages will now also work in dispatcher-based sites (the dispatcher work isn't finished yet, but the seed-site front page renders fine in pdf at least). I have documented the new features in the pdf plugin documentation, but last time I checked, it was not yet visible on the Forrest site. Perhaps we need to release a new version of the pdf plugin? Best regards, Sjur
Re: Content-notice
Den 3. sep. 2008 kl. 15.57 skrev Thorsten Scherler: On Wed, 2008-09-03 at 15:54 +0300, Sjur Moshagen wrote: Hello all, In whiteboard/plugins/o.a.f.themes.core/themes/common/fo/ there is a contract called content-notice.ft Its description reads: "content-notice will output the notice of the content." ... The content of this document doesn't make any sense at all. as seen in main/fresh-site/src/documentation/content/xdocs/samples-b/sample.xml Thanks! Best regards, Sjur
Content-notice
Hello all, In whiteboard/plugins/o.a.f.themes.core/themes/common/fo/ there is a contract called content-notice.ft Its description reads: "content-notice will output the notice of the content." What exactly is this? What is the notice? Where does the notice come from? It is not the same as "Note", and I can't remember any element like this from the skins-based fo-processing. The contract contains a hard-coded font family which I would like to replace with a variable with a descriptive name, but then I need to understand what this is all about:) Best regards, Sjur
Re: FOPNGSerializer, user-config and locationmaps
Den 2. sep. 2008 kl. 03.17 skrev David Crossley: I switched that cron job off now. The skins-based one will still be operating. Thanks. I will start committing now, first some small preparatory commits, and then one big commit that will update the pdf plugin in one step. This large update is needed not to risk breaking pdf functionality. As noted, pdf functionality in dispatcher will be broken after this commit, but hopefully it can be restored within short. Best regards, Sjur
Re: FOPNGSerializer, user-config and locationmaps
Den 1. sep. 2008 kl. 14.36 skrev Thorsten Scherler: But it does NOT work if I DON'T add it manually there, even though the entity is now defined both in core and in project within $FORREST_HOME. Hmm that is weird. I have to admit unless like David I am not the expert in the entity config, but it should work in editing vim main/webapp/resources/schema/entity/symbols-core-v10.ent and then in your sitemap like in the dispatcher plugin: vim whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/ internal.xmap %symbols-project; %symbols-core; ]> It *should* work, AFAICU. it should work as described above, it is hard to comment on it without a commit. Thanks for the patience. For some reason I had forgot to add the symbols-core entity def. in the output.xmap file in the pdf plugin. That made all the difference:) Best regards, Sjur
Re: FOPNGSerializer, user-config and locationmaps
Den 22. aug. 2008 kl. 11.53 skrev Thorsten Scherler: On Fri, 2008-08-22 at 11:44 +0300, Sjur Moshagen wrote: Den 22. aug. 2008 kl. 11.29 skrev Sjur Moshagen: But when I start up Forrest again, I get the following error: CAUSE: The entity "pdf-config-file" was referenced, but not declared. Forget about that, I didn't notice that Forrest had already copied in an entity file in my $PROJECT_HOME folder, which of course did not contain the entity declaration :/ That is why I wrote in the other mail that best is to implement the default in the core. I did that now, but... Now it is working as a charm:) That was a little exaggerated. It does work as a charm IFF I add it manually in the $PROJECT_HOME/src/ documentation/resources/schema/symbols-project-v10.ent But it does NOT work if I DON'T add it manually there, even though the entity is now defined both in core and in project within $FORREST_HOME. It *should* work, AFAICU. A possible workaround is to add it to the symbols-project-v10.ent file in the seeded site - that way it will always be defined. It is still somehow broken since it will break existing projects/sites until they manually add the entity def. to their own symbols-project-v10.ent file. Suggestions? Ideas about the cause? Best regards, Sjur
Re: FOPNGSerializer, user-config and locationmaps
Den 27. aug. 2008 kl. 12.47 skrev Thorsten Scherler: But the basic issue is that I don't want to commit, because I know I would break PDF functionality in dispatcher - but I won't get any feedback if I don't commit. A separate branch could be overkill, and dispatcher is in the whiteboard... Would broken PDF functionality for dispatcher be ok through a short period of time? (some days or so)? That estimate might be optimistic, but I'll try to keep the period short. Having more eyes and coding fingers might as well help to resolve the issues quicker:) If is not possible to do the commit without breaking the dispatcher it seems acceptable. However we need to make sure that we disable the forrestbot on zones for the dispatcher site meanwhile otherwise we will get again a flood of build fail messages. Yes, we will. Could you turn off the relevant zones for the time being? After that I should soon be able to commit what I have (an impmroved, working, skins-based pdf plugin). Best regards, Sjur
Re: output.inputModule Plugin dependency (was: Plugin dependencies)
Ross Gardler wrote: Thorsten Scherler wrote: On Fri, 2008-08-22 at 08:26 +0300, Sjur Moshagen wrote: What it looks like to me, is that the o.a.f.p.output.inputModule is turning into core functionality of Forrest (and necessarily so if we do away with skinconfig), cf the comments from Thorsten earlier in this thread. IMO this observation is correct. +1 I have seen no other comments on this, thus I take it that we agree that this is core functionality. -> end of this point of the discussion. Either we accept this fact, but leave the functionality as a (required) plugin, or we move the functionality of the o.a.f.p.output.inputModule into the Forrest core. Then we would have no dependency anymore, since core is allways there. The problem I have to drop this functionality as plugin and move it directly into the core is that cannot build it anymore by itself and use the resulting jar. However I agree that this plugin represents core functionality (that is why I called it infrastructure code). I don't get it? Why is this a problem? Forrest needs the code to go into core. If it builds as a plugin it will build as part of the core. If you mean that you, as an individual, need to use the code independently of Forrest then I don't think that is a problem for us as a community. On the other hand, if you are saying that this code is useful to many other projects as a standalone peice of code then it should be a project (or more likely a Cocoon block) in its own right. Forrest can then include the block (or jar) from there. I'm +1 for the code going into core if it resolves the plugin dependencies in dispatcher and the new PDF work quickly and easily. One day we will need a plugin dependency mechanism (as we always say), but I don't think this is it. Thorsten has not commented upon this, which means that his problems with the plugin code going into core is still unclarified. I agree with Ross that the easiest solution would be to just move the code to core. We accepted plugin dependencies for dispatcher whilst it was in whiteboard, however, we have always rejected them in the past for very good reasons. Those reasons are in the archives and are not limited to version issues. Unless I've misunderstood the problem with moving the inpuModule code into either core or a cocoon block then I'm -1 on using a solution that contradicts a previous design decision. Accepted. However, whilst this -1 is resolved I thin it is clear that Sjur should proceed with the work using the inputModule - we'll agree a way to get it into the next release in parallel with that work. Ok, thanks, I'll try to continue this week:) (last week was too busy for me) Best regards, Sjur
Re: [VOTE] use Cocoon-2.1
Den 28. aug. 2008 kl. 05.44 skrev David Crossley: We intend to "update" the version of Cocoon used by Forrest to be Cocoon-2.1 branch. Please vote. +1 Sjur
Re: FOPNGSerializer, user-config and locationmaps
Den 26. aug. 2008 kl. 12.49 skrev Thorsten Scherler: I need to review your commit. ... I had a quick look on the weekend but I am not sure. Many featured you described in this thread seems to be not commited yet. Is that correct, because you wrote that you have some stack of changes on your local box. Yes, I do. Right now I'm travelling, and don't have time for any commits. But the basic issue is that I don't want to commit, because I know I would break PDF functionality in dispatcher - but I won't get any feedback if I don't commit. A separate branch could be overkill, and dispatcher is in the whiteboard... Would broken PDF functionality for dispatcher be ok through a short period of time? (some days or so)? Best regards, Sjur
Re: How to seed a new plugin
Den 25. aug. 2008 kl. 13.08 skrev Tim Williams: On Mon, Aug 25, 2008 at 6:05 AM, Sjur Moshagen <[EMAIL PROTECTED]> wrote: Hello all, I would like to develop a new plugin - is there a way to "seed" a fresh framework for plugins, or do I have to populate it manually? I could not find anything about this in the docs. Is this not what you mean? http://forrest.apache.org/docs_0_80/howto/howto-buildPlugin.html#seed [blush - I should have been able to find that myself:( ] Thanks a lot - exactly what I need! Best regards, Sjur
How to seed a new plugin
Hello all, I would like to develop a new plugin - is there a way to "seed" a fresh framework for plugins, or do I have to populate it manually? I could not find anything about this in the docs. Best regards, Sjur
Re: To lm or not to lm - pdf
Den 23. aug. 2008 kl. 00.03 skrev Ross Gardler: Thorsten Scherler wrote: On Tue, 2008-08-19 at 15:48 +0300, Sjur Moshagen wrote: Hello all, In the main stylesheet for the transformation to fo, the following lines caught my attention: Only the third inclusion is using the locationmap. Is there any reason for this (no-)use of lm lookups, or could I rewrite the rest of the inclusions to use locationmap lookups? I would say yes we should use the locationmap since that makes it easy overwritable. I reckon nobody came around to implement the corresponding matches, feel free to do so if you want. As I'm (probably) the one who did the transfer to LM in the first place I can't think of any reason why I did not do it using the LM. Quite possibly these were added after the LM tranfer and done by someone who didn't know how it worked. It is very easy to change for all helper-* files, the LM match is already defined. I have changed it locally, but since the same stylesheet is now full of changes related to the ongoing work of making the pdf plugin fully user configurable and i18n-ed, I haven't commited the change yet. (Hm, I know, it is usually much better to check in small amounts of edits than one gigantuous, but most of the changes are interdependent, and checking in only some of them would make the plugin non-functional in one or more areas; perhaps a separate branch would have been better) Best regards, Sjur
Re: FOPNGSerializer, user-config and locationmaps
Den 22. aug. 2008 kl. 12.12 skrev Sjur Moshagen: That is why I wrote in the other mail that best is to implement the default in the core. Ok, I'll add it there as well. Done as of r688036. This case is closed, as soon as I commit all my changes to the pdf plugin (still some work left todo on the dispatcher side). Best regards, Sjur
Re: FOPNGSerializer, user-config and locationmaps
Den 22. aug. 2008 kl. 11.53 skrev Thorsten Scherler: On Fri, 2008-08-22 at 11:44 +0300, Sjur Moshagen wrote: Den 22. aug. 2008 kl. 11.29 skrev Sjur Moshagen: But when I start up Forrest again, I get the following error: CAUSE: The entity "pdf-config-file" was referenced, but not declared. Forget about that, I didn't notice that Forrest had already copied in an entity file in my $PROJECT_HOME folder, which of course did not contain the entity declaration :/ That is why I wrote in the other mail that best is to implement the default in the core. Ok, I'll add it there as well. Best regards, Sjur
Re: FOPNGSerializer, user-config and locationmaps
Den 22. aug. 2008 kl. 11.29 skrev Sjur Moshagen: But when I start up Forrest again, I get the following error: CAUSE: The entity "pdf-config-file" was referenced, but not declared. Forget about that, I didn't notice that Forrest had already copied in an entity file in my $PROJECT_HOME folder, which of course did not contain the entity declaration :/ Now it is working as a charm:) Best regards, Sjur
Re: FOPNGSerializer, user-config and locationmaps
Den 22. aug. 2008 kl. 09.54 skrev Thorsten Scherler: Actually a similar problem that you are trying to solve has been solved by David a while back. I remember because while updating I stumble over the solution again. Have a look in the main sitemap or the internal.xmap of the dispatcher. There we use entities to make the serializer configurable. First we define the entities file: %symbols-project; %symbols-core; ]> and later on we use it: name="xhtml" pool-grow="2" pool-max="64" pool-min="2" src="org.apache.cocoon.serialization.XMLSerializer"> &serializer-xhtml-doctype-public; &serializer-xhtml-doctype-system; &serializer-xhtml-encoding; yes yes As you can see each project can provide a symbols-project-v10.ent which can override the configuration. By default we have e.g. for the dispatcher: I have now added the following to o.a.f.o.pdf/output.xmap: %symbols-project; ]> ... src="org.apache.cocoon.blocks.fop.FOPNGSerializer" mime- type="application/pdf"> &pdf-config-file; and in the file $FORREST_HOME/main/webapp/resources/schema/entity/symbols-project- v10.ent I added the following: (That is, the entity should resolve to the empty string by default). But when I start up Forrest again, I get the following error: CAUSE: The entity "pdf-config-file" was referenced, but not declared. I then tried to copy the dummy symbols-project-v10.ent found in main/ webapp/ into the root of the pdf plugin, but that did not help. I then tried to copy the real entity file into the root of the plugin, but I still got the same error. Any ideas? Best regards, Sjur
Re: FOPNGSerializer, user-config and locationmaps
Den 22. aug. 2008 kl. 09.54 skrev Thorsten Scherler: ... As you can see each project can provide a symbols-project-v10.ent which can override the configuration. ... I think that is a quite elegant solution to our problem without the need for an extended debugging session. Absolutely - elegant indeed:) Thanks for the suggestion. Best regards, Sjur
Re: FOPNGSerializer, user-config and locationmaps
I think I will leave it as it is then, at least for the moment. Eclipse has turned out to be a steep learning thing for me (I have tried a couple of times, but I don't grasp the idea of the interface - it is just confusing to me), and setting this up would take more time than I have at the moment. I'll see if I can get someone else in my team to have a look at the code. Best regards, Sjur Den 20. aug. 2008 kl. 11.37 skrev Thorsten Scherler: On Wed, 2008-08-20 at 11:05 +0300, Sjur Moshagen wrote: Den 20. aug. 2008 kl. 09.33 skrev Thorsten Scherler: ... If the link rewriter is screwing things up you could debug LinkRewriterTransformer. Anyway this transformer normally never should rewrite anything in the sitemap.xmap. Whatever the problem, I'm on unknown territory here (I'm not really into Java). Any suggestions for how to debug this? Using Eclipse that is not that hard but you would need some basic knowledge of eclipse. First add the following to your forrest.properties: forrest.jvmargs=-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n That will force forrest to start in debug mode. Now you need both cocoon and forrest in your eclipse workspace (I think cocoon 2.1.x should be fine). Add a breakpoint to LinkRewriterTransformer in the linkrewrite block. I recommend somewhere in configure(Configuration conf). Another in public void startTransformingElement(String uri,...) HTH salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: Plugin dependencies (Was: pdf plugin config locations)
Den 21. aug. 2008 kl. 13.09 skrev Tim Williams: On Thu, Aug 21, 2008 at 4:01 AM, Sjur Moshagen <[EMAIL PROTECTED]> wrote: Den 21. aug. 2008 kl. 10.06 skrev Thorsten Scherler: Is this dependency acceptable? IMO yes, since the plugin is very small and thought a infrastructure code. Like you describe the alternative to implement it in the sitemap is cumbersome to maintain. Are there other opinions? Do we need a vote before we tie ourselves to this dependency? In the past I think we've consistently decided against having dependent plugins until we have a facility built in that will manage them properly. I reckon this is due to version incompatibility problems between plugins, etc. The dispatcher plugin is already dependent upon the o.a.f.p.output.inputModule, although dispatcher is in the whiteboard. Would this dependency stop it from being released from whiteboard? What it looks like to me, is that the o.a.f.p.output.inputModule is turning into core functionality of Forrest (and necessarily so if we do away with skinconfig), cf the comments from Thorsten earlier in this thread. Either we accept this fact, but leave the functionality as a (required) plugin, or we move the functionality of the o.a.f.p.output.inputModule into the Forrest core. Then we would have no dependency anymore, since core is allways there. How should it/can it be formalised? Not sure what you mean? Whether it is possible to formalize the dependency, such that if the pdf plugin is specified, forrest will automatically also include other plugins the pdf plugin is dependent on. But if I remember past discussions correctly, this isn't possible yet. It is not and I believe this is the issue. There's no way for plugin A to say I require version N of plugin B, for example. Complicating matters, if you have two plugins with dependencies on differing versions of the same plugin, strange things are likely to happen. I believe it's this complication (the devils in the details) that has kept us from having such a capability for so long. Understandable, and I have no real solution to this. I'm not saying we shouldn't change the status quo but I think it's worthy of some discussion first. Having said that, you seem to be on a good roll and I don't want long discussion to slow you down either:) :D I have now done the basic work for skins-based sites, but I will have to do the same for dispatcher-based sites as well (otherwise the pdf plugin would be broken in dispatcher), which means there is still some time to discuss this before I commit. If we decide against the dependency, my changes will still work, but forwarding the user settings to the xsl stylesheet will be much more clumsier and hard to maintain. Best regards, Sjur
Re: Plugin dependencies (Was: pdf plugin config locations)
Den 21. aug. 2008 kl. 10.06 skrev Thorsten Scherler: QUESTIONS: Is this dependency acceptable? IMO yes, since the plugin is very small and thought a infrastructure code. Like you describe the alternative to implement it in the sitemap is cumbersome to maintain. Are there other opinions? Do we need a vote before we tie ourselves to this dependency? How should it/can it be formalised? Not sure what you mean? Whether it is possible to formalize the dependency, such that if the pdf plugin is specified, forrest will automatically also include other plugins the pdf plugin is dependent on. But if I remember past discussions correctly, this isn't possible yet. At least we need to update the seeds to include the o.a.f.p.output.inputModule as well as the pdf plugin (new seeds only include the pdf plugin). As I understand it you commit to the fresh-site forrest.properties files (skins/dispatcher) and the cron is doing the rest. Ok, I'll update the fresh-site file. Comments? Thanks for looking into this Sjur. Thanks for the feedback. Best regards, Sjur
