Open issues for the next release

http://issues.apache.org/jira/browse/FOR-681

See <a href="http://marc.theaimsgroup.com/?l=forrest-dev&m=112781600212715&w=2">http://marc.theaimsgroup.com/?l=forrest-dev&amp;m=112781600212715&amp;w=2</a><br/> <br/> &gt; I was excited to see the addition of xconf capability into plugins. See<br/> &gt; <a href="http://svn.apache.org/viewcvs?rev=227190&view=rev">http://svn.apache.org/viewcvs?rev=227190&amp;view=rev</a>.<br/> &gt; <br/> &gt; I rebuild cocoon with authentication and session blocks, and added the jars<br/> &gt; to 'plugin/lib' and the xconf files from the<br/> &gt; 'cocoon-2.2.0-dev\build\webapp\WEB-INF\xconf' to 'plugin/conf'.<br/> <br/> ...<br/> <br/> &gt; So am bit confused, on two counts:<br/> &gt; 1. if xpatch is required, how do I generate this file?<br/> &gt; 2. why are we using xpatch, when the current cocoon.xconf uses includes,<br/> &gt; can't we do the same here?<br/> <br/> This was a rather hasty commit of mine that I have not yet fixed, even <br/> though David spotted it as soon as I committed. Sorry that it has stung you.<br/> <br/> My original solution for including config files for plugins was to use <br/> the XPatch utility. This sat on my hard drive for some time because I <br/> had a few minor issues to iron out before committing. Then somebody <br/> needed some functionlaity from my local &quot;branch&quot; that also contained the <br/> XConf code. I committed in a hurry, not noticing that I still used the <br/> XPatch method.<br/> <br/> The good news is that I have also enabled the XConf includes <br/> functionality. But this has not yet been leveraged for plugins.<br/> <br/> There are two short term workarounds for you:<br/> <br/> 1) Use the XPatch facility (see Cocoon docs on XPatch)<br/> 2) is to edit the main/webapp/cocoon.xconf and add the include you need, <br/> it will work ust fine.<br/> <br/> If you opt for one be aware that we will be removing this in favour of <br/> using the includes at some point before the 0.8 release.<br/> <br/> The long term solution to the problem is to create a plugin.xconf file <br/> that s built each time Forrest is run, much the same as we do with the <br/> sitemap mounts for plugins. We would welcome a patch for this, I can <br/> help point you in the right direction if you fancy tackling it.<br/> <br/> Could you please create an issue for this and point to this thread in <br/> the archives so I do not forget again.<br/>

http://issues.apache.org/jira/browse/FOR-796

This is the global issue to keep track on the merging effort

http://issues.apache.org/jira/browse/FOR-911

For past releases we have essentially done a &quot;source&quot; release, i.e. pack everything found in svn trunk including a pre-built forrest binary jar file.<br/> <br/> Here is one recent discussion:<br/> &nbsp;content of release [was: Re: review list of scheduled issues for 0.8 release]<br/> &nbsp;<a href="http://marc.theaimsgroup.com/?t=115257903800001">http://marc.theaimsgroup.com/?t=115257903800001</a>

http://issues.apache.org/jira/browse/FOR-868

We need to add some notes to the upgrading_0*.html doc for the upcoming release. This would most easily be done after attending to <a href="http://issues.apache.org/jira/browse/FOR-865" title="Add missing entries to status.xml to generate the changes list"><strike>FOR-865</strike></a> &quot;Add missing entries to status.xml to generate the changes list&quot;.

http://issues.apache.org/jira/browse/FOR-1108

Since the update to Cocoon 2.1 Forrest and Dispatcher have broken on windows.

http://issues.apache.org/jira/browse/FOR-591

Since the docs restructuring for the 0.7 release it has become necessary to increase the maxmemory to be able to build the Forrest site. We gained three copies of the documents so suddenly have a large document set to trigger memory leakage issues.<br/> <br/> Possibly <a href="http://issues.apache.org/jira/browse/COCOON-1574" title="Memory Leak with XMLFileModule">COCOON-1574</a> &quot;Memory Leak with XMLFileModule&quot;.<br/> <br/> Does someone have the tools to run some diagnostics?<br/> <br/> (NB maxmemory has been increased in our site-author/forrest.properties, if we resolve this issue it should be reduced again)

http://issues.apache.org/jira/browse/FOR-855

This should be continually happening anyway, but immediately prior to each release we need to verify that our license situation is in order. This issue should not ever be closed, rather just move the &quot;Fix for Version&quot; on to the next release.<br/> <br/> Here are some of the tasks:<br/> <br/> A) Ensure that all supporting libraries have a corresponding license. Basically every jar file or other external package needs to have a *.license.txt file. Ensure that any license conditions are met, e.g. for some we must add an entry to NOTICE.txt, while for some others we must not. Remember to abide by the ASF guidelines (e.g. nothing more restrictive than the Apache License).<br/> <br/> B) Scan the whole trunk repository to add missing ASF license headers to source files and to ensure that the ASF license headers have not been accidently added to external files. See etc/relicense.txt<br/> <br/> C) Remove any author tags.

http://issues.apache.org/jira/browse/FOR-1177

While assessing the license situation for <a href="http://issues.apache.org/jira/browse/FOR-855" title="verify the license situation prior to each release">FOR-855</a> and <a href="http://issues.apache.org/jira/browse/FOR-857" title="append license files to the top-level LICENSE.txt">FOR-857</a> ... one of the difficult cases is &quot;Rhino&quot;. <br/> <br/> Does someone know why we use Rhino and which part of Forrest? Did it just come along by accident with our addition of Cocoon, or is it actually being used? <br/> <br/> See: <br/> lib/core/rhino-1.6R2.jar <br/> and prior to that <br/> lib/core/rhino-1.6R1.jar

http://issues.apache.org/jira/browse/FOR-812

The dispatcher will remove the file skinconf.xml. However, the projectInfo plugin uses it to get the URL for the issue tracker.<br/> <br/> We should chage the projectInfo plugin so that this value is provided by a plugin property.

http://issues.apache.org/jira/browse/FOR-572

We need to run a memory profiler while forrest is operating.

http://issues.apache.org/jira/browse/FOR-986

A dispatcher based site does not need a skinconf.xml file. However, if one is not present then the &quot;forrest war&quot; target fails with:<br/> <br/> BUILD FAILED<br/> C:\projects\apache-forrest-0.8\main\targets\webapp.xml:48: The following error occurred while executing this line:<br/> C:\projects\apache-forrest-0.8\main\forrest.build.xml:256: input file C:\projects\apache-forrest-0.8\main\webapp\skinconf.xml does not exist<br/> <br/> To work around this issue just put a skinconf.xml in place

http://issues.apache.org/jira/browse/FOR-1081

All available contracts should be enabled in Panels and working so that they may be used as examples and also as a test to ensure they work; and as a warning when they don't.<br/> So , in the style of document-v20 this should be created in seed-sample2 so that forrestbot can let us know when any contracts break.

http://issues.apache.org/jira/browse/FOR-922

There are various documents that explain parts of the sitemaps. Some of these mention pathnames, some have actual fragments of code copied from sitemaps. All of this needs to be updated to reflect the current sitemaps. <br/> <br/> The sitemaps were recently updated to use locationmap, some sitemaps were simplified, filenames were changed, e.g. document2html.xsl to document-to-html.xsl <br/> <br/> These changes need to be reflected in the current docs.

http://issues.apache.org/jira/browse/FOR-210

The &quot;fresh-site&quot; build from 'forrest seed site' reports some failures for faq.html and various missing images. Wonder if sitemap issue?<br/> <br/>

http://issues.apache.org/jira/browse/FOR-721

In our forrest/site-author/content/xdocs/site.xml there are two entries without &quot;label&quot; attributes. Previously these documents were not being generated. Not sure if this change in behaviour is good or bad. Needs investigation.<br/> <br/> This is most likely a side-effect of the workaround for issue <a href="http://issues.apache.org/jira/browse/FOR-675" title="upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.">FOR-675</a>

http://issues.apache.org/jira/browse/FOR-675

upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc. This happens in both modes: 'forret run' and 'forrest'.

http://issues.apache.org/jira/browse/FOR-677

Doing 'forrest' starts at the virtual document called linkmap.html where the Cocoon crawler gathers the initial set of links, then starts crawling and generating pages. Any new links are pushed onto the linkmap. However, for some sites, such as our own &quot;seed-sample&quot; and our &quot;site-author&quot;, there is a sudden jump in the number of URIs remaining to be processed.<br/> <br/> This is due to a URI with a leading slash (e.g. /samples/faq.html). When that URI is processed, it gains a whole new set of links all with leading slashes, and so the list of URIs is potentially doubled.<br/> <br/> This issue could be due to a user error, i.e. adding a link that deliberately begins with a slash. Sometimes, that is unavoidable.<br/> <br/> However, we do have a sitemap transformer to &quot;relativize&quot; and &quot;absolutize&quot; the links. Should it always trim the leading slash? Or are there cases where that should not happen, so cannot generalise?

http://issues.apache.org/jira/browse/FOR-705

Build fails when given target URL of rewriteDemo is not available (site down, no longer exists, incorrect URL typing etc).<br/> <br/> For various reasons given in [1] and [2] this default feature should remain but alternative options should be made available. Possible solutions given in [3]<br/> <br/> [1] <a href="http://marc.theaimsgroup.com/?l=forrest-dev&m=112826350500282">http://marc.theaimsgroup.com/?l=forrest-dev&amp;m=112826350500282</a><br/> <br/> [2] <a href="http://marc.theaimsgroup.com/?l=forrest-dev&m=11270994920771">http://marc.theaimsgroup.com/?l=forrest-dev&amp;m=11270994920771</a><br/> <br/> [3] <a href="http://marc.theaimsgroup.com/?l=forrest-dev&m=112859428219336&w=2">http://marc.theaimsgroup.com/?l=forrest-dev&amp;m=112859428219336&amp;w=2</a><br/> <br/>

http://issues.apache.org/jira/browse/FOR-785

Recently i split the skinconf.xml for each plugin to refer to common stuff via an external entity. Works nicely.<br/> <br/> Okay, i admit it ... forgot to do 'build test' :-) and it doesn't validate. The DTD insists on having the elements in a specific order.

http://issues.apache.org/jira/browse/FOR-857

The license files for accompanying external products needs to be appended after the Apache License in the top-level $FORREST_HOME/LICENSE.txt file. <br/> <br/> Perhaps the current discussion on the legal-discuss mailing list will clarify <br/> <a href="http://www.apache.org/foundation/mailinglists.html#foundation-legal">http://www.apache.org/foundation/mailinglists.html#foundation-legal</a>

http://issues.apache.org/jira/browse/FOR-1073

In <a href="http://issues.apache.org/jira/browse/FOR-1072" title="[PATCH] Bugfixes and improvements for PDF output plugin"><strike>FOR-1072</strike></a> Jeremias said:<br/> &quot;Filtered out link elements with no href (which are created by html-to-document.xsl for &quot;&lt;a name=...&quot;). Forrest 0.7 didn't generate them as links at all but trunk does. Maybe that's wrong in the first place. &quot;<br/> <br/> There was also a mention of it previously on the dev list surrounding the recent FOP update branch work.

http://issues.apache.org/jira/browse/FOR-936

When moving from one page to another and switching locales in between, the chosen locale is lost when entering the new page. To reproduce:<br/> <br/> 1) set up and run forrest with i18n ON<br/> 2) open a localized page<br/> 3) switch locale by appending '?locale=XY' in the address field<br/> 4) open another page available in both the original locale (before the switch) and the new locale XY<br/> 5) notice how the new page is displayed in the original locale, NOT the expected XY locale<br/> <br/> Although one could argue that the described behaviour is wanted in some cases, I believe that to most users it would be natural that the locale is &quot;sticky&quot; once changed - it should not change back by itself. Thus, the &quot;sticky&quot; behaviour should be default in Forrest.<br/> <br/> The fix is simple, patch to come soon.

http://issues.apache.org/jira/browse/FOR-971

I would like to align the table columns with percentage CSS like 20-60-20 to improve the look and readability.

http://issues.apache.org/jira/browse/FOR-644

We have much inconsistent whitespace in all of our files. This is known to cause trouble in a collaborative environment. See discussion at: <a href="http://marc.theaimsgroup.com/?t=112450901100001">http://marc.theaimsgroup.com/?t=112450901100001</a> and <a href="http://marc.theaimsgroup.com/?t=112495618800002">http://marc.theaimsgroup.com/?t=112495618800002</a> and various linked discussions.<br/>

http://issues.apache.org/jira/browse/FOR-250

Currently the compliance logos are only applied to any page called &quot;index.html&quot;. It would be nice if we could automatically determine if the final output was valid and apply the compliance logos accordingly.