Re: versioned plugin docs (Was: svn commit: r190111)
Summarising ... http://f.a.o/docs_0_60/ will refer to the documentation for Forrest V0.6 http://f.a.o/docs_0_70/ will refer to the documentation for Forrest V0.7 http://f.a.o/docs_0_80/ will refer to the documentation for Forrest V0.8 There will no longer be the current version at f.a.o/docs/ Assuming that FOR-544 goes ahead: http://f.a.o/pluginDocs/plugins_0_70/index.html will be the index of valid plugins for the 0.7 version of Forrest http://f.a.o/pluginDocs/plugins_0_80/index.html will be the index of valid plugins for the 0.8 version of Forrest http://f.a.o/pluginDocs/plugins_0_70/PLUGINNAME will be the latest docs for the most recent release of the indicated plugin for version 0.7 of Forrest http://f.a.o/pluginDocs/plugins_0_80/PLUGINNAME will be the latest docs for the most recent release of the indicated plugin for version 0.8 of Forrest
Re: svn commit: r190796 - in /forrest/trunk: main/fresh-site/forrest.properties main/webapp/sitemap.xmap site-author/status.xml
David Crossley wrote:
Ross Gardler wrote:
Author: cheche
Date: Wed Jun 15 12:53:39 2005
New Revision: 190796
URL: http://svn.apache.org/viewcvs?rev=190796view=rev
Log:
Add a config selector so the i18n transformer only works whrn i18n is true
We are in a code freeze. This looks like a non-essential commit to me.
Should it be reverted?
I don't profess to know anything about i18n, but part of this commit
looks like a bugfix (skins/common/messages/ = /translations/).
The remainder looks like an efficiency issue, which might be relevant.
Please explain a bit more Cheche.
sure,
there are two issues:
1) (skins/common/messages/ = /translations/)
The new directory to keep the commomMessages_{language}.xml is under
skins/commons/translations so it the same as the project language files
that are under {project.home}/src/documentation/translations
2) I18nTransformer that was added for the skins messages did not check
if a i18n property was set to true, so in the case that you are building
a English site within a foreigner locale, then the messages would be
translated which is wrong.
Cheers,
cheche
Re: Versioned Plugins
Monday, June 13, 2005, 5:33:36 PM, Ross Gardler wrote: Ron Blaschke wrote: Sunday, June 12, 2005, 11:38:26 PM, Ross Gardler wrote: Ron Blaschke wrote: I am wondering if I made a mistake, and the URL should refer to the directory only, like the others do, i.e. url=http://www.rblasch.org/projects/pod-input/; Yes, I should have spotted that when I applied your patch. It will actually break the install of your plugin. I'm sorry to cause inconvenience, but would you please be so kind and correct it for me? Yes, of course, I should have said I will do that in the original reply. Thanks a lot! Ron
Re: svn commit: r190796 - in /forrest/trunk: main/fresh-site/forrest.properties main/webapp/sitemap.xmap site-author/status.xml
Ross Gardler wrote: [EMAIL PROTECTED] wrote: Author: cheche Date: Wed Jun 15 12:53:39 2005 New Revision: 190796 URL: http://svn.apache.org/viewcvs?rev=190796view=rev Log: Add a config selector so the i18n transformer only works whrn i18n is true We are in a code freeze. This looks like a non-essential commit to me. It looks like a bugfix to me. :-) Should it be reverted? Unless you want to deploy broken funcionality, it should not been reverted.
[Testing 0.7rc1] Possible troubles with simplified-docbook plugin
I haven't had time to dig into this in detail, but I hope someone familiar with plugins will help me fill in the missing pieces. I tried to build some site with the new 0.7rc1, which contains simplified docbook documents. The site built successfully, but the pages were empty (shouldn't this fail?). Anyway, I added the simplified-docbook plugin to forrest.properties, and ran forrest init-plugins, which failed with: ... check-plugin: org.apache.forrest.plugin.input.simplified-docbook is not available in the build dir ... ERROR = Unable to retrieve the org.apache.forrest.plugin.input.simplified plugin. There may be more information about the reason for this in output ... My current guess is that the name simplified-docbook collides with the versioned plugins naming, so that docbook is interpreted as a version number, and there is no plugin simplified. Ron
Re: FOR 363
Dick Hollenbeck wrote: What are the issues that make fixing FOR 363 so difficult that it appears not be slated for fixing in the 0.7 release? Thanks, Dick Hollenbeck I personally think that this was not been review properly. yesterday I had moved all the issues with no components so they get better visibility. I have added a patch as well, it makes easier to understant the suggested fix. I would like others to have a look and vote if this change should be in the 0.7 release this is my +1 Cheers, cheche
[jira] Updated: (FOR-363) figure-elements within aggregated pdf-pages are not displayed
[ http://issues.apache.org/jira/browse/FOR-363?page=all ] Juan Jose Pablos updated FOR-363: - Attachment: for-363.patch Patch to allow other to review in a standard way. figure-elements within aggregated pdf-pages are not displayed --- Key: FOR-363 URL: http://issues.apache.org/jira/browse/FOR-363 Project: Forrest Type: Bug Components: Plugin: pdf-output Versions: 0.6 Environment: Linux Reporter: Stephan E. Schlierf Priority: Minor Attachments: for-363.patch With Forrest 0.6 I encountered a problem during the creation of a pdf-file that is aggregated from a group of documents: All my graphics are in project-dir]/src/documentation/resources/images (and its subdiretories). Now if I use figure-elements in these documents the graphics are not displayed in the aggregated pdf-file. If I use img-elements everything's ok. As far as I can see this problem is located in src/core/context/resources/stylesheets/aggregates/doc2doc-uniqueids.xsl: Around line 45 the follwoing template is defined: xsl:template match=section/document//figure|img[starts-with(@src, 'my-images')] !-- fix my-images/** links, which break as they are not relative to the site root -- ... /xsl:template If you change the match condition to match=section/document//figure[starts-with(@src, 'my-images')]| img[starts-with(@src, 'my-images')] even the figure-elements are displayed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Testing 0.7rc1] Possible troubles with simplified-docbook plugin
Ron Blaschke wrote: My current guess is that the name simplified-docbook collides with the versioned plugins naming, so that docbook is interpreted as a version number, and there is no plugin simplified. That is correct. In fact I added a warning to the docs saying plugin names cannot have a hyphen. It never occured to me that the simplified-docbook has a hyphen in it. Doh! I will fix tonight. Ross
Re: svn commit: r190796 - in /forrest/trunk: main/fresh-site/forrest.properties main/webapp/sitemap.xmap site-author/status.xml
Juan Jose Pablos wrote: Ross Gardler wrote: [EMAIL PROTECTED] wrote: Author: cheche Date: Wed Jun 15 12:53:39 2005 New Revision: 190796 URL: http://svn.apache.org/viewcvs?rev=190796view=rev Log: Add a config selector so the i18n transformer only works whrn i18n is true We are in a code freeze. This looks like a non-essential commit to me. It looks like a bugfix to me. :-) Should it be reverted? Unless you want to deploy broken funcionality, it should not been reverted. Fair enough Ross
Re: [Testing 0.7rc1] Possible troubles with simplified-docbook plugin
Ross Gardler wrote: Ron Blaschke wrote: My current guess is that the name simplified-docbook collides with the versioned plugins naming, so that docbook is interpreted as a version number, and there is no plugin simplified. That is correct. In fact I added a warning to the docs saying plugin names cannot have a hyphen. It never occured to me that the simplified-docbook has a hyphen in it. Doh! should we change that to sdocbook ?
Re: [Testing 0.7rc1] Possible troubles with simplified-docbook plugin
Ross Gardler wrote: Ron Blaschke wrote: My current guess is that the name simplified-docbook collides with the versioned plugins naming, so that docbook is interpreted as a version number, and there is no plugin simplified. That is correct. In fact I added a warning to the docs saying plugin names cannot have a hyphen. It never occured to me that the simplified-docbook has a hyphen in it. Doh! should be change that to sdocbook ?
[VOTE] build patch Re: testing 0.7rc1 - build failed
Thread moved to dev list, please direct replies there.
Ross Gardler wrote:
David Crossley wrote:
David Crossley wrote:
Roland Becker wrote:
system: w2ksp4
java: jdk1.5.0_03
1. download 0.7rc1
2. unpack
3. set environment
4. cd mysite
5. forrest seed
6. forrest
X [0]
docs/plugins/index.html BROKEN:
C:\usr\apache-forrest-0.7\whiteboard\plugins\whiteboard-plugins.xml
(Das System
kann den angegebenen Pfad nicht finden)
Thanks for testing. Yes i get that too.
I don't see that behaviour in today's trunk (r190851).
So i presume that it is fixed.
No it is not fixed. The plugins/index.html file is generated from the
plugins.xml file in the plugins directory. This has not been included in
the build and so it is missing. It works with trunk because you have it
checked out.
I will alter the build file so that the plugins subdirectory, the
plugins.xml, the build.xml and the plugin-template are all present in
the distribution. This will allow users to build plugins.
Hmmm... correction (I had guessed this was the problem)...
In actual fact *all* plugins files *except* the ones needed were being
copied into the distribution.
The plugin source files should not be in the distribution, but instead
should be downloaded on demand by Forrest.
I've created a small patch (see attached) for the build file that
exludes all plugins except the PDF output plugin (since ths is enabled
by default on a new site) and includes the missing files that caused the
above problem.
I will apply this patch tomorrow AM (GMT) assuming that nobody casts a -1
Ross
Index: main/build.xml
===
--- main/build.xml (revision 190903)
+++ main/build.xml (working copy)
@@ -199,19 +199,32 @@
delete dir=${dist-shbat.dir} /
mkdir dir=${dist-shbat.dir} /
-!-- copy all Forrest --
+echoCopy Forrest core files from ${forrest.home}/echo
copy todir=${dist-shbat.dir}
fileset dir=${forrest.home}
exclude name=build/**/
exclude name=whiteboard/**/
+exclude name=plugins/**/
/fileset
/copy
- copy todir=${dist-shbat.dir}
+
+echoCopy plugin related files from ${plugins.dir}/echo
+copy todir=${dist-shbat.dir}/plugins
+ fileset dir=${plugins.dir}
+include name=plugins.xml/
+include name=build.xml/
+include name=pluginTemplate/**/
+include name=org.apache.forrest.plugin.output.pdf/**/
+ /fileset
+/copy
+
+echoCopy forrest.jar/echo
+copy todir=${dist-shbat.dir}
fileset dir=${forrest.home}
include name=build/xml-forrest.jar/
/fileset
/copy
-
+
!-- Fix bin/ permissions --
fixcrlf eol=crlf srcdir=${dist-shbat.dir}/bin includes=*.bat/
fixcrlf eol=lf srcdir=${dist-shbat.dir}/bin excludes=*.bat/
Re: [Testing 0.7rc1] Possible troubles with simplified-docbook plugin
Juan Jose Pablos wrote: Ross Gardler wrote: Ron Blaschke wrote: My current guess is that the name simplified-docbook collides with the versioned plugins naming, so that docbook is interpreted as a version number, and there is no plugin simplified. That is correct. In fact I added a warning to the docs saying plugin names cannot have a hyphen. It never occured to me that the simplified-docbook has a hyphen in it. Doh! should we change that to sdocbook ? I just changed to simplifiedDocbook, hope that is OK with everyone. I've redeployed the plugin and plugins.xml file so that 'forrest availablePlugins' reports the correct name. Ross
Re: FOR 363
Juan Jose Pablos wrote: Dick Hollenbeck wrote: What are the issues that make fixing FOR 363 so difficult that it appears not be slated for fixing in the 0.7 release? Thanks, Dick Hollenbeck I personally think that this was not been review properly. yesterday I had moved all the issues with no components so they get better visibility. I have added a patch as well, it makes easier to understant the suggested fix. I would like others to have a look and vote if this change should be in the 0.7 release this is my +1 There is a typo in the patch: match=section/document//figure[starts-with(@src, 'my-images')]|img[starts-with(@src, 'my-images')] . /|\ | I've not tested the solution, but it looks sensible. Ross
rc2 and vote soon (Was: [Important] code-freeze commenced)
Ross Gardler wrote: David Crossley wrote: Next important milestones are: * Create release candidate #2 if there have been changes on Friday 2005-06-17 at 22:00 UTC [2] [2] http://www.timeanddate.com/worldclock/meetingtime.html?day=18month=06year=2005p1=48p2=176p3=240p4=224p5=213 With respect to me building this release for windows. I said in another reply in another thread I may not be able to do it in the afternoon UTC, I now see it is scheduled for the evening UTC. No problem I will be at home by then. Great, so we have a bit over one day to go. This note is a reminder that we need to vote that the second release candidate is suitable for release. We will call a vote when it is ready. -David
Re: FOR 363
Ross Gardler wrote: There is a typo in the patch: match=section/document//figure[starts-with(@src, 'my-images')]|img[starts-with(@src, 'my-images')] . /|\ | fixed thanks! I've not tested the solution, but it looks sensible. if no one has other objection i will apply it tonight. Cheers, cheche
Re: [Testing 0.7rc1] Possible troubles with simplified-docbook plugin
Ross Gardler wrote: Juan Jose Pablos wrote: Ross Gardler wrote: Ron Blaschke wrote: My current guess is that the name simplified-docbook collides with the versioned plugins naming, so that docbook is interpreted as a version number, and there is no plugin simplified. That is correct. In fact I added a warning to the docs saying plugin names cannot have a hyphen. It never occured to me that the simplified-docbook has a hyphen in it. Doh! should we change that to sdocbook ? I just changed to simplifiedDocbook, hope that is OK with everyone. well, sdocbook is shorter and that is used already on the stylesheet: sdocbook2document.xsl I've redeployed the plugin and plugins.xml file so that 'forrest availablePlugins' reports the correct name.
[jira] Updated: (FOR-363) figure-elements within aggregated pdf-pages are not displayed
[ http://issues.apache.org/jira/browse/FOR-363?page=all ] Juan Jose Pablos updated FOR-363: - Attachment: for-363.patch added proper patch. figure-elements within aggregated pdf-pages are not displayed --- Key: FOR-363 URL: http://issues.apache.org/jira/browse/FOR-363 Project: Forrest Type: Bug Components: Plugin: pdf-output Versions: 0.6 Environment: Linux Reporter: Stephan E. Schlierf Priority: Minor Attachments: for-363.patch With Forrest 0.6 I encountered a problem during the creation of a pdf-file that is aggregated from a group of documents: All my graphics are in project-dir]/src/documentation/resources/images (and its subdiretories). Now if I use figure-elements in these documents the graphics are not displayed in the aggregated pdf-file. If I use img-elements everything's ok. As far as I can see this problem is located in src/core/context/resources/stylesheets/aggregates/doc2doc-uniqueids.xsl: Around line 45 the follwoing template is defined: xsl:template match=section/document//figure|img[starts-with(@src, 'my-images')] !-- fix my-images/** links, which break as they are not relative to the site root -- ... /xsl:template If you change the match condition to match=section/document//figure[starts-with(@src, 'my-images')]| img[starts-with(@src, 'my-images')] even the figure-elements are displayed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r190919 - /forrest/trunk/whiteboard/plugins/whiteboard-plugins.xml
On Thu, 2005-06-16 at 14:01 +, [EMAIL PROTECTED] wrote: @@ -110,7 +110,7 @@ plugin name=org.apache.forrest.plugin.internal.view type=internal author=Apache Forrest Project - website=http://forrest.apache.org/docs/plugins/org.apache.forrest.plugin.view; + website=http://forrest.apache.org/pluginDocs/plugins_0_70/org.apache.forrest.plugin.view; url=http://forrest.apache.org/plugins/; version=0.1-dev description Actually not all whiteboard plugins are listed in your commit nor in the docu. e.g. viewHelper is missing. Can it be that we have to publish (ant build) whiteboard plugins as well? TIA salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
[jira] Commented: (FOR-363) figure-elements within aggregated pdf-pages are not displayed
[ http://issues.apache.org/jira/browse/FOR-363?page=comments#action_12313841 ] Dick Hollenbeck commented on FOR-363: - I applied the Jun/05 5:03 PM patch to current 0.7 (snap shotted via svn update as of yesterday), and it does not seem to fix this issue. I still do not see a PNG image in the wholesite.pdf file, yet is is displayed in the HTML output. I suggest you enable wholesite.pdf in the forrest seed example, and try it yourself. figure-elements within aggregated pdf-pages are not displayed --- Key: FOR-363 URL: http://issues.apache.org/jira/browse/FOR-363 Project: Forrest Type: Bug Components: Plugin: pdf-output Versions: 0.6 Environment: Linux Reporter: Stephan E. Schlierf Priority: Minor Attachments: for-363.patch With Forrest 0.6 I encountered a problem during the creation of a pdf-file that is aggregated from a group of documents: All my graphics are in project-dir]/src/documentation/resources/images (and its subdiretories). Now if I use figure-elements in these documents the graphics are not displayed in the aggregated pdf-file. If I use img-elements everything's ok. As far as I can see this problem is located in src/core/context/resources/stylesheets/aggregates/doc2doc-uniqueids.xsl: Around line 45 the follwoing template is defined: xsl:template match=section/document//figure|img[starts-with(@src, 'my-images')] !-- fix my-images/** links, which break as they are not relative to the site root -- ... /xsl:template If you change the match condition to match=section/document//figure[starts-with(@src, 'my-images')]| img[starts-with(@src, 'my-images')] even the figure-elements are displayed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FOR-545) PDFs for the generated DTD documentation is going haywire
[ http://issues.apache.org/jira/browse/FOR-545?page=comments#action_12313880 ] David Crossley commented on FOR-545: The six documents are generated twice (for docs_0_70 and docs_0_60) so that is 12 extra minutes on the build time. I will move these docs up to the top-level at /dtdx/ because they don't need to be versioned. As a workaround for this PDF issue, created a project sitemap and added generated PDFs to the /dtdx/ directory. The project sitemap will serve these pre-prepared PDFs using the new technique for raw un-processed files. PDFs for the generated DTD documentation is going haywire - Key: FOR-545 URL: http://issues.apache.org/jira/browse/FOR-545 Project: Forrest Type: Bug Components: Documentation and website Versions: 0.7-dev Reporter: David Crossley Fix For: 0.7-dev We generate documentation for DTDs using the dtdx plugin. When the PDFs for this documentation are generated, it takes a long time to build them (about one minute each). Occasionally we see java.lang.OutOfMemoryError. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [testing] RC1 testing results
On 6/16/05, Tim Williams [EMAIL PROTECTED] wrote: I've tested the RC1 and found no major issues. Some trivial things I saw were: -- Tab not highlighting I'm not sure if this qualifies as a bug but I found it odd that clicking on the Versioned Docs tab doesn't highlight that tab -- meaning you click on it and essentially lose context of where the subtabs are. This appears to be the case in both Firefox and IE. Perhaps it's always existed and just struck me as odd this time I do not know. This one is documented in FOR-209 -- sorry should have looked prior to making my comments. --tim
Re: [testing] RC1 testing results
Tim Williams wrote: Tim Williams wrote: I've tested the RC1 and found no major issues. Some trivial things I saw were: -- Tab not highlighting I'm not sure if this qualifies as a bug but I found it odd that clicking on the Versioned Docs tab doesn't highlight that tab -- meaning you click on it and essentially lose context of where the subtabs are. This appears to be the case in both Firefox and IE. Perhaps it's always existed and just struck me as odd this time I do not know. This one is documented in FOR-209 -- sorry should have looked prior to making my comments. Hmmm, Tim i don't see your original email. The archives don't show it either. http://marc.theaimsgroup.com/?a=11134261192 Would you either point me to it or send it again please. -David
Re: [testing] RC1 testing results
Tim Williams wrote: I've tested the RC1 and found no major issues. Some trivial things I saw were: -- Tab not highlighting I'm not sure if this qualifies as a bug but I found it odd that clicking on the Versioned Docs tab doesn't highlight that tab -- meaning you click on it and essentially lose context of where the subtabs are. This appears to be the case in both Firefox and IE. Perhaps it's always existed and just struck me as odd this time I do not know. -- FOR 537 It does bug me that the docs regarding plugin sitemaps aren't consistent with the release but I'm not sure if it's too late to fix this or not? If someone can send a patch to the docs in the current trunk, then we can add it before packing rc2 (about 17 hours remain). Note: do 'svn update' first because the docs have moved to xdocs/pluginDocs/plugins_0_70/ -- Tools tab This (XXE) was kind of strange. Why is this particular xml editor singled out? I've never seen this tool before and it comes across (my perception at least) as if it's endorsed by Forrest some how. Maybe I'm missing something but this seem weird to me. No favouritism or endorsement. Just that that tool has ways to configure it to improve the editing of our xml docs. If anyone has supporting bits-and-pieces for other tools, then we can add them too. I added a note to xxe.xml to try to explain that. Anyway, great job on the RC guys... Thank you, Thanks for the testing and feedback. -David
monitoring ASF service status
If ever you wonder that ASF services might not be responding, then browse to http://www.apache.org/dev/ and see the link Public Host Service Status. This is particularly useful if ever the mail servers are in trouble. The ASF infrastructure@ people know about any issues, through alerts to IRC, etc. So there is no need to tell people that something is down. This is a service for your benefit. -David
