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-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-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-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-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-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-588

We need a new config system for Forrest for various reasons: the initial config system was known to be limited; to enable the specification of multiple Forrest sites within a single instance of Forrest; to accommodate the changes brought about by forrest:views, themes, and plugins.

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

It would be nice if plugins could be a little more independent of core skins and themes for plugin specific styling.<br/> This could be CSS, or something else, I have only identified CSS needs at present.

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-1117

Brian M Dube wrote: <br/> &gt; Brian M Dube wrote: <br/> &gt; &gt; What are module.date.properties and module.properties.properties? <br/> &gt; <br/> &gt; They come from links in <br/> &gt; site-author/content/xdocs/docs_0_90/properties.xml. See <br/> &gt; <a href="http://svn.apache.org/viewvc?view=rev&revision=696589">http://svn.apache.org/viewvc?view=rev&amp;revision=696589</a> <br/> <br/> They would be useful for debugging aids, but we cannot <br/> publish them on our website. They reveal local system info. <br/> They also will change back-and-forth as each different <br/> committer publishes the Forrest website. <br/> <br/> Need to replace those links with text instructions. <br/> <br/> Also add these resources to &quot;/howto-dev.html&quot;. <br/> <br/> Also add to Forrestbar &quot;Devs&quot; menu, not &quot;Dispatcher-dev&quot; <br/> menu, because it is relevant to both. <br/>

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-388

At present Forrest will attempt to download plugins even if they are available in src form in the local filesystem as part of an SVN checkout.<br/> <br/> Have Forrest mount plugins from designated directories in preference to downloading them wherever possible (need more than posible location for src plugins as some people may be developing their own plugins outside of Forrest)<br/> <br/>

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-217

Users are prevented from using certain filenames because those patterns are claimed by the default sitemaps for special processing. These include: site, changes, todo, faq, images, my-images, skinconf, cprofile<br/>

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

tools/eclipse/plugins/org.apache.forrest.eclipse.servletEngine/lib contains some duplicate jars to those in the main Forrest trunk. We should find a way of reusing the jars from their existing location.

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-676

Raising loglevels in main/webapp/WEB-INF/logkit.xconf has no effect when doing 'forrest'. All okay when doing 'forrest run'.

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-699

These are a whole group of HowTos that I wrote for my local users (probably a tutorial would be a better format). They are not complete, nor tidied at this point, but they cover a lot of basic step-by-step stuff specifically geared towards Linux with Gnome desktop and Windows XP. Figured I would put them out there so we can pull out bits we may want to use.