Open issues for the next release
- [FOR-681] Include xconf files in plugins using includes, not XPatch
- [FOR-796] Merge all view/dispatcher work into org.apache.forrest.plugin.internal.dispatcher and org.apache.forrest.themes.core
- [FOR-591] MaxMemory needs increasing for large document sets: Memory Leak with XMLFileModule
- [FOR-911] decide content of release
- [FOR-868] add relevant notes to the "Upgrading" xdoc
- [FOR-812] Remove dependency of projectInfo on skinconf.xml
- [FOR-855] verify the license situation prior to each release
- [FOR-1108] Dispatcher, Cocoon 2.1 and Windows
- [FOR-572] run a memory profiler while forrest is operating
- [FOR-986] Dispatcher war fails to build if no skinconf.xml is in place
- [FOR-707] Document i18n features of Forrest
- [FOR-588] Design new configuration system
- [FOR-970] Add a way to have plugin specific resources, such as its own CSS styling, independent of skin or theme
- [FOR-388] Use plugins in-place if src available
- [FOR-210] whole-site html and pdf: broken link faq, broken image links
- [FOR-217] Certain patterns are claimed by the default sitemaps
- [FOR-560] Remove duplicate jars from eclipse plugins
- [FOR-721] entries without labels in site.xml are now being crawled and generated
- [FOR-676] logkit.xconf has no effect on configuration when in commandline mode
- [FOR-677] leading slash in gathered URIs causes double the number of links to be processed
- [FOR-675] upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.
- [FOR-699] Beginner HowTos for installing Forrest
- [FOR-705] Target of LocationMap rewriteDemo causes build failure when target not available
- [FOR-785] plugins/*/skinconf.xml does not validate since using entity to ease management
- [FOR-936] Forrest "looses" the locale when switching pages
[FOR-681] Include xconf files in plugins using includes, not XPatch
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&m=112781600212715&w=2</a><br/> <br/> > I was excited to see the addition of xconf capability into plugins. See<br/> > <a href="http://svn.apache.org/viewcvs?rev=227190&view=rev">http://svn.apache.org/viewcvs?rev=227190&view=rev</a>.<br/> > <br/> > I rebuild cocoon with authentication and session blocks, and added the jars<br/> > to 'plugin/lib' and the xconf files from the<br/> > 'cocoon-2.2.0-dev\build\webapp\WEB-INF\xconf' to 'plugin/conf'.<br/> <br/> ...<br/> <br/> > So am bit confused, on two counts:<br/> > 1. if xpatch is required, how do I generate this file?<br/> > 2. why are we using xpatch, when the current cocoon.xconf uses includes,<br/> > 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 "branch" 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/>
[FOR-796] Merge all view/dispatcher work into org.apache.forrest.plugin.internal.dispatcher and org.apache.forrest.themes.core
http://issues.apache.org/jira/browse/FOR-796
This is the global issue to keep track on the merging effort
[FOR-591] MaxMemory needs increasing for large document sets: Memory Leak with XMLFileModule
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> "Memory Leak with XMLFileModule".<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)
[FOR-911] decide content of release
http://issues.apache.org/jira/browse/FOR-911
For past releases we have essentially done a "source" 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/> content of release [was: Re: review list of scheduled issues for 0.8 release]<br/> <a href="http://marc.theaimsgroup.com/?t=115257903800001">http://marc.theaimsgroup.com/?t=115257903800001</a>
[FOR-868] add relevant notes to the "Upgrading" xdoc
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> "Add missing entries to status.xml to generate the changes list".
[FOR-812] Remove dependency of projectInfo on skinconf.xml
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.
[FOR-855] verify the license situation prior to each release
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 "Fix for Version" 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.
[FOR-1108] Dispatcher, Cocoon 2.1 and Windows
http://issues.apache.org/jira/browse/FOR-1108
Since the update to Cocoon 2.1 Forrest and Dispatcher have broken on windows.
[FOR-572] run a memory profiler while forrest is operating
http://issues.apache.org/jira/browse/FOR-572
We need to run a memory profiler while forrest is operating.
[FOR-986] Dispatcher war fails to build if no skinconf.xml is in place
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 "forrest war" 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
[FOR-707] Document i18n features of Forrest
http://issues.apache.org/jira/browse/FOR-707
There is next to no documentation about i18n, just a pretty poor FAQ entry that points at an issue that has now been closed. <br/> <br/> Cheche wrote a blog entry on his work: <br/> <br/> <a href="http://casa.che-che.com/blog/2005/05/10/internalization-a-site-using-forrest-07-dev/">http://casa.che-che.com/blog/2005/05/10/internalization-a-site-using-forrest-07-dev/</a> <br/> <br/> We could, at the very least use the locationmap to pull this content into our site [OT: I wonder if this could be a way to generate more documentation?)
[FOR-588] Design new configuration system
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.
[FOR-970] Add a way to have plugin specific resources, such as its own CSS styling, independent of skin or theme
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.
[FOR-388] Use plugins in-place if src available
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/>
[FOR-210] whole-site html and pdf: broken link faq, broken image links
http://issues.apache.org/jira/browse/FOR-210
The "fresh-site" build from 'forrest seed site' reports some failures for faq.html and various missing images. Wonder if sitemap issue?<br/> <br/>
[FOR-217] Certain patterns are claimed by the default sitemaps
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/>
[FOR-560] Remove duplicate jars from eclipse plugins
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.
[FOR-721] entries without labels in site.xml are now being crawled and generated
http://issues.apache.org/jira/browse/FOR-721
In our forrest/site-author/content/xdocs/site.xml there are two entries without "label" 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>
[FOR-676] logkit.xconf has no effect on configuration when in commandline mode
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'.
[FOR-677] leading slash in gathered URIs causes double the number of links to be processed
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 "seed-sample" and our "site-author", 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 "relativize" and "absolutize" the links. Should it always trim the leading slash? Or are there cases where that should not happen, so cannot generalise?
[FOR-675] upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.
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'.
[FOR-699] Beginner HowTos for installing Forrest
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.
[FOR-705] Target of LocationMap rewriteDemo causes build failure when target not available
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&m=112826350500282</a><br/> <br/> [2] <a href="http://marc.theaimsgroup.com/?l=forrest-dev&m=11270994920771">http://marc.theaimsgroup.com/?l=forrest-dev&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&m=112859428219336&w=2</a><br/> <br/>
[FOR-785] plugins/*/skinconf.xml does not validate since using entity to ease management
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.
[FOR-936] Forrest "looses" the locale when switching pages
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 "sticky" once changed - it should not change back by itself. Thus, the "sticky" behaviour should be default in Forrest.<br/> <br/> The fix is simple, patch to come soon.