Re: [RT] Serving Apache Forrest site from live Forrest
Ross Gardler wrote: > > I agree with David that we should use the forthcoming zones to do these > experiments. David, will we be able to do load testing in this zone? I presume so, but we should ask at ASF Infrastructure. > Another problem I see with live hosting is that all the error reporting > that Forrest does is done when we build the site. That is, documents are > not validated before a Forrest run and we don't check for broken links. The Forrestbot webapp interface provides access to the logfiles. > For the live hosting environment I would like to see these checks being > run on a periodic basis and reports being generated for the admin. > Perhaps this could be a part of the fallover recovery. For example, we > could build a static version of the site every X hours and deploy this > (using Forrestbot) to a static server which will be used should the live > one fail. Yes, that is the solution that i see too. --David
Re: SVN Inconsitent Line Endings
Ross Gardler wrote: > David Crossley wrote: > > > >I presume that this does not happen when you do 'forrest' to > >build the plugin's docs, rather than doing 'ant docs'. > > I had also assumed that, however it turns our to be incorrect. > > In fact doing "forrest site" on any site, including site-author, results > in the same error. > > I can only assume that it has not raised it's head before because I have > not been the first person to commit generated sites to SVN with the eol > settings set to "native". Sorry, i can't parse that. Too many "nots". :-) All text files should have line-endings appropriate for the local system OS and should always be 'svn propset svn:eol-style native'. > Given the above observation that the XSL generated comments ahve > different line endings to other XSL generated files I can only assume it > is something to do with the XSLT parser. What happens when you do a simple test with Xalan on the commandline. > For now I have put a workaround in place in the buildfile (uses an ant > task to fix the line endings). I'll also place an issue on the issue > tracker to remind us of this. I saw that. However i couldn't understand why it was converting them to UNIX line-endings regardless of which OS the user is on. Do we need to detect the OS? I have not heard of this problem before. At Cocoon and Incubator, people on various operating systems generate the website and commit the result to SVN, with no problems. --David
[JIRA] Updated: (FOR-145) Make Forrest able to be imported by Ant
The following issue has been updated: Updater: Ross Gardler (mailto:[EMAIL PROTECTED]) Date: Fri, 6 May 2005 10:08 AM Changes: Version changed to 0.7-dev Version changed from 0.8 Fix Version changed to 0.8 Fix Version changed from 0.7-dev - For a full history of the issue, see: http://issues.cocoondev.org//browse/FOR-145?page=history - View the issue: http://issues.cocoondev.org//browse/FOR-145 Here is an overview of the issue: - Key: FOR-145 Summary: Make Forrest able to be imported by Ant Type: Bug Status: Unassigned Priority: Minor Project: Forrest Components: Compile Fix Fors: 0.8 Versions: 0.7-dev Assignee: Reporter: Nick Chalko Created: Thu, 6 May 2004 8:31 PM Updated: Fri, 6 May 2005 10:08 AM Description: I use an ant build system called antworks, http://antworks.sourceforge.net/ which includes an antlet for forrest. Antlets are included into a projects build file with a ant task. However forrest has many common target names and properties. Please prefix all targets and properties with "forrest." to support using ant import of the entire forrest.build.xml - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[JIRA] Updated: (FOR-492) Inconsistent Line Endings in generated sites
The following issue has been updated: Updater: Ross Gardler (mailto:[EMAIL PROTECTED]) Date: Fri, 6 May 2005 10:07 AM Changes: summary changed from Inconsitent Line Endings in generated sites to Inconsistent Line Endings in generated sites description changed from Sites generated by Forrest have inconsitent line endings when created on a Windows platform. I did a little testing, here's what I have discovered so far: - any file that is processed by XSLT has the line endings problem - on investigating one such file (index.html) I discovered that the generated comments from site2xhtml.xsl (such as breadtrail comment) have CRLF endings whilst most other lines have LF endings. I'm running on Windows, and get the same results whether I run under CYGWIN or DOS. To reproduce cd into any plugin directory, do "ant docs" and check out the generated docs in build/site. This appears to a result of the XSLT transformations. xsl:comments retain the line endings contained in the XSL file, whilst other line endings are set to the environment default. Is there a way to tell the XSLT transformer what line endings to use? to Sites generated by Forrest have inconsistent line endings when created on a Windows platform. I did a little testing, here's what I have discovered so far: - any file that is processed by XSLT has the line endings problem - on investigating one such file (index.html) I discovered that the generated comments from site2xhtml.xsl (such as breadtrail comment) have CRLF endings whilst most other lines have LF endings. I'm running on Windows, and get the same results whether I run under CYGWIN or DOS. To reproduce run "forrest site" in any site and check out the generated docs in build/site. This appears to a result of the XSLT transformations. xsl:comments retain the line endings contained in the XSL file, whilst other line endings are set to the environment default. Is there a way to tell the XSLT transformer what line endings to use? Fix Version changed to 0.8 - For a full history of the issue, see: http://issues.cocoondev.org//browse/FOR-492?page=history - View the issue: http://issues.cocoondev.org//browse/FOR-492 Here is an overview of the issue: - Key: FOR-492 Summary: Inconsistent Line Endings in generated sites Type: Bug Status: Unassigned Priority: Minor Project: Forrest Components: Core operations Fix Fors: 0.8 Versions: 0.7-dev Assignee: Reporter: Ross Gardler Created: Fri, 6 May 2005 10:04 AM Updated: Fri, 6 May 2005 10:07 AM Environment: Windows (with or without CYGWIN) Description: Sites generated by Forrest have inconsistent line endings when created on a Windows platform. I did a little testing, here's what I have discovered so far: - any file that is processed by XSLT has the line endings problem - on investigating one such file (index.html) I discovered that the generated comments from site2xhtml.xsl (such as breadtrail comment) have CRLF endings whilst most other lines have LF endings. I'm running on Windows, and get the same results whether I run under CYGWIN or DOS. To reproduce run "forrest site" in any site and check out the generated docs in build/site. This appears to a result of the XSLT transformations. xsl:comments retain the line endings contained in the XSL file, whilst other line endings are set to the environment default. Is there a way to tell the XSLT transformer what line endings to use? - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[JIRA] Created: (FOR-492) Inconsitent Line Endings in generated sites
Message: A new issue has been created in JIRA. - View the issue: http://issues.cocoondev.org//browse/FOR-492 Here is an overview of the issue: - Key: FOR-492 Summary: Inconsitent Line Endings in generated sites Type: Bug Status: Unassigned Priority: Minor Project: Forrest Components: Core operations Versions: 0.7-dev Assignee: Reporter: Ross Gardler Created: Fri, 6 May 2005 10:04 AM Updated: Fri, 6 May 2005 10:04 AM Environment: Windows (with or without CYGWIN) Description: Sites generated by Forrest have inconsitent line endings when created on a Windows platform. I did a little testing, here's what I have discovered so far: - any file that is processed by XSLT has the line endings problem - on investigating one such file (index.html) I discovered that the generated comments from site2xhtml.xsl (such as breadtrail comment) have CRLF endings whilst most other lines have LF endings. I'm running on Windows, and get the same results whether I run under CYGWIN or DOS. To reproduce cd into any plugin directory, do "ant docs" and check out the generated docs in build/site. This appears to a result of the XSLT transformations. xsl:comments retain the line endings contained in the XSL file, whilst other line endings are set to the environment default. Is there a way to tell the XSLT transformer what line endings to use? - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: SVN Inconsitent Line Endings
David Crossley wrote: Ross Gardler wrote: Dave Brondsema wrote: I'd say we should find out why the HTML is generated with inconsistent line endings in the first place. True. I did a little testing, here's what I have discovered so far: - any file that is processed by XSLT has the line endings problem - on investigating one such file (index.html) I discovered that the generated comments from site2xhtml.xsl (such as breadtrail comment) have CRLF endings whilst most other lines have LF endings. I'm running on Windows, and get the same results whether I run under CYGWIN or DOS. To reproduce cd into any plugin directory, do "ant docs" and check out the generated docs in build/site. Does the same behaviour happen if you use Forrest's packaged Ant? i.e. $FORREST_HOME/tools/ant/bin/ant docs Also 'unset ANT_HOME' to make it uses Forrest's lib/*.jar Yes I presume that this does not happen when you do 'forrest' to build the plugin's docs, rather than doing 'ant docs'. I had also assumed that, however it turns our to be incorrect. In fact doing "forrest site" on any site, including site-author, results in the same error. I can only assume that it has not raised it's head before because I have not been the first person to commit generated sites to SVN with the eol settings set to "native". Given the above observation that the XSL generated comments ahve different line endings to other XSL generated files I can only assume it is something to do with the XSLT parser. For now I have put a workaround in place in the buildfile (uses an ant task to fix the line endings). I'll also place an issue on the issue tracker to remind us of this. Ross
Re: [RT] Serving Apache Forrest site from live Forrest
Torsten Schlabach wrote: ATM I am only concerned about making Forrest genuinely useful as a live server, which IMO is a blocker for any serious request to infra. Are you saying Forrest is not up to performing as a serious live server right now? If I understood that right, why would that be the case? I don't think that is the point, rather there is no proven case of Forrest being used as a live server. That is we cannot currently answer questions such as: - Can Forrest be safely left running on a server without consuming all resources? - What is the minimum recomended specification for a Forrest server? - can a Forrest site, hosted live on ABC server, handle a load of x page requests in a minute? and so on. No admin will entrust their critical services to a server that cannot provide these answers. They need to see it proven in a test environment first. I agree with David that we should use the forthcoming zones to do these experiments. David, will we be able to do load testing in this zone? Another problem I see with live hosting is that all the error reporting that Forrest does is done when we build the site. That is, documents are not validated before a Forrest run and we don't check for broken links. For the live hosting environment I would like to see these checks being run on a periodic basis and reports being generated for the admin. Perhaps this could be a part of the fallover recovery. For example, we could build a static version of the site every X hours and deploy this (using Forrestbot) to a static server which will be used should the live one fail. Ross
Re: Forrest sites google ranking
David Crossley wrote: Ross Gardler wrote: I just noticed that the changes in the Forrest site have resulted in a complete loss of our google ranking. That is we currently have a rank of "n/a". Prior to the redirects we had a very healthy 7. Would you please explain how you find this "ranking". https://addons.update.mozilla.org/extensions/moreinfo.php?application=firefox&id=262 Ross
Re: [RT] Serving Apache Forrest site from live Forrest
>> ATM I am only concerned about making Forrest >> genuinely useful as a live server, which IMO is a blocker for any >> serious request to infra. Are you saying Forrest is not up to performing as a serious live server right now? If I understood that right, why would that be the case? Regards, Torsten > David Crossley wrote: >> Torsten Schlabach wrote: >> >>>Nicola, >>> My goal is to put a live Forrest on ASF infrastructure instead of the bot and have that serve all Forrest-based sites in Apache, comprising Lenya. >>> >>>Sounds good. Let me know if you need any help or input from us. >>> >>>Are you subsribed to [EMAIL PROTECTED] There is a rush for >>>Solaris zones on the new v40z machine. Hurry up if you need one. > > I am not subscribed to infra and, given my time constraints, will not be > in the near future. ATM I am only concerned about making Forrest > genuinely useful as a live server, which IMO is a blocker for any > serious request to infra. > >> That is not true. Justin at Infrastructure was asking for a few >> projects to help test the initial setup. Yes there was a rush! >> However, there is no need to rush. Each PMC is to eventually have >> a zone. > > This is very nice :-) > > -- > Nicola Ken Barozzi [EMAIL PROTECTED] > - verba volant, scripta manent - > (discussions get forgotten, just code remains) > - > >
Re: [RT] Serving Apache Forrest site from live Forrest
Nicola Ken Barozzi wrote: > > One thing I like about Forrest is that it's not only a static site > generation engine, but it's capable of serving the site live. Changes > are instantaneous, bandwith is perserved, and dynamic content can be > employed. > > IMHO every Apache project that produces something it can use for itself > *should* actually use it, like HTTPD does. This gives the team something > to work collectively on, and a base that keeps the project adherent to > actual needs. > > IOW, I would like to see the Forrest website served of a live Forrest > instance. > > To do this, even before talking about logistics and permissions, we have > to be sure that it's not going to cause problems, even in high load, and > be able to administer it. > Before we can seriously start to consider using it live, we should at > least have the following: > > 1 - knowledge of the memory it's going to need and use > 2 - have no known memory leakage (to be tested) > 3 - have caching turned on > 4 - know what to do when upgrading the version > 5 - decide where it's going to get the site from > 6 - other? > > After that, it would be beneficial to be able to serve multiple sites on > a single Forrest instance, so that we can have other projects join and > have their site served. > > Thoughts, comments, opinions? This is a RT thread so let us all throw our Random Thoughts into the mix. We can later develop that into a plan. I see various different issues. Some are separate, and some are entwined ... building our website (static, dynamic, both); a place to experiment with our own software; a testing environment; a way to stage the website so that we can review our changes before publishing; running a Forrestbot to build static websites for various ASF projects; etc. We will have a place to experiment soon. Each PMC will get $pmc.zones.apache.org ... they are still testing the setup, so there is no rush. That would be our space to experiment with our various versions of Forrest. We could have the release version, the head of trunk, and a "known good trunk". I am not talking about versions of the docs, this is about versions of the software. We will need to experiment there, until we are happy to use it in production. We don't don't need to worry too much about memory usage at this stage. In fact, that zone will give us a place to do proper tests to determine the memory aspects. For our actual website, there are many things that we need to consider. For example, ASF Infrastructure has certain requirements to enable easy recovery of websites and a way to fail-over to another server to enable OS upgrades etc. I think that the main thing is to do it in steps. Start with the demo servers in forrest.zones.apache.org and work up to doing more ambitious things like the website. There is another related issue. Over the past years, a plan has come together to have a "staging" server, i.e. a place where static sites are built and previewed before going into production. That is now a lot closer to happening. See the threads at [EMAIL PROTECTED] about "Site Build Zone", and also http://forrest.apache.org/0.7/proposal-asf-publish.html Of course, the Forrestbot is a part of that infrastructure and they want Forrest committers to be involved in that. Anyway, the zone is not ready yet, so i will keep us informed. --David
[EMAIL PROTECTED]: Project forrest-forrestbar (in module forrest) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project forrest-forrestbar has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 5 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - forrest-forrestbar : Apache Forrest is an XML standards-oriented documentation fr... Full details are available at: http://brutus.apache.org/gump/public/forrest/forrest-forrestbar/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/forrest/forrest-forrestbar/gump_work/build_forrest_forrest-forrestbar.html Work Name: build_forrest_forrest-forrestbar (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dversion=06052005 forrestbar [Working Directory: /usr/local/gump/public/workspace/forrest/tools/forrestbar] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar - Buildfile: build.xml BUILD FAILED java.lang.NoClassDefFoundError: org/xml/sax/ext/Attributes2 at org.apache.xerces.parsers.AbstractSAXParser.(Unknown Source) at org.apache.xerces.parsers.SAXParser.(Unknown Source) at org.apache.xerces.parsers.SAXParser.(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.(Unknown Source) at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source) at org.apache.tools.ant.util.JAXPUtils.newSAXParser(JAXPUtils.java:212) at org.apache.tools.ant.util.JAXPUtils.getNamespaceXMLReader(JAXPUtils.java:169) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:187) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:140) at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:90) at org.apache.tools.ant.Main.runBuild(Main.java:653) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.Main.start(Main.java:150) at org.apache.tools.ant.Main.main(Main.java:240) Total time: 0 seconds java.lang.NoClassDefFoundError: org/xml/sax/ext/Attributes2 at org.apache.xerces.parsers.AbstractSAXParser.(Unknown Source) at org.apache.xerces.parsers.SAXParser.(Unknown Source) at org.apache.xerces.parsers.SAXParser.(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.(Unknown Source) at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source) at org.apache.tools.ant.util.JAXPUtils.newSAXParser(JAXPUtils.java:212) at org.apache.tools.ant.util.JAXPUtils.getNamespaceXMLReader(JAXPUtils.java:169) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:187) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:140) at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:90) at org.apache.tools.ant.Main.runBuild(Main.java:653) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.Main.start(Main.java:150) at org.apache.tools.ant.Main.main(Main.java:240) org/xml/sax/ext/Attributes2 - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/forrest/forrest-forrestbar/rss.xml - Atom: http://brutus.apache.org/gump/public/forrest/forrest-forrestbar/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2306052005, brutus:brutus-public:2306052005 Gump E-mail Identifier (unique within run) #26. -- Apache Gump http://gump.apache.org/ [Instance: brutus]
Re: whitespace changes (Was: svn commit: r167890)
Ferdinand Soethe wrote: > David Crossley wrote: > > DC> It seemed to also do other reformatting. Be sure to do 'svn diff' > DC> before committing. > > Should I revert it back to the original whitespaceing and insert my > changes again? No. I was just making sure that people knew the problems that it causes. --David
Re: whitespace changes (Was: svn commit: r167890)
David Crossley wrote: DC> It seemed to also do other reformatting. Be sure to do 'svn diff' DC> before committing. Should I revert it back to the original whitespaceing and insert my changes again? -- Ferdinand Soethe
