The Forrest feels like home
It's been many many years since I was in the Forrest, but it feels like home. Hello folks :) I'm re-evaluating Forrest for a small project I have. After searching far and wide there still isn't a solution for my use case other than Forrest. So I've re-subscribed to the dev list, more out fond memories than any intention to contribute again - though if I do use it on this project who knows... My first comment - damn this community documented Forrest well :-D Ross
Re: s5 output plugin for Forrest
Forgive the terse response, I'm travelling but want to give a quick reply. I created an SF site for project for Forrest plugins that couldn't be apache licensed. Was never used significantly. May have put code there. However, consider moving it to a new project at www.apache-extras.org (discuss with Forrest community, I'm no longer active) With respect to my code, it's all open source do as you will, would be good to see someone improve it. Just make sure you respect the s5 license. Good luck Sent from my mobile device. On 27 Jan 2011, at 23:30, Sjur Moshagen sju...@mac.com wrote: Hello Ross, In the thread [1] the issue of moving the s5 plugin somewhere else was mentioned. The Forrest whiteboard is blocked due to licensing issues, but I could probably find a home for it at work - we have an open repository at https://victorio.uit.no/langtech/. If someone has other suggestions, that is of course all very well (our svn repository is probably not the best place since getting commit access requires manual set-up). Would moving it to a new home be ok with you? (I see that the burrokeet sf site you mentioned in an old discussion as a possible home hasn't been active for over 500 days - that site is probably not the best one either, anymore - if it is still a possibility, my sf username is 'moshagen'). Also, the s5 plugin as it stands does not fit my needs that well, and I would like to rewrite it from the bottom, more or less. In practice, I would probably create a new plugin, but based on your work (yes, I am aware of the w3c slides vs s5 discussions), with proper credits of course. Would that be ok as well? Best regards, Sjur N. Moshagen Samediggi · Sametinget Project Manager for the Divvun project http://www.divvun.no/ http://www.samediggi.no/ +358-9-49 75 29 (w) +358-505 634 319 (m) [1]: http://marc.info/?l=forrest-devm=129591307420205w=2
Re: Merging back the dispatcher
On 26/04/2010 13:14, Tim Williams wrote: I think there's another consideration that I didn't mention too. I feel irresponsible releasing software that we can't support and I'm concerned that this would be the case with the dispatcher. This is a valid comment and one the Forrest committers should all think about. On the flip side, the dispatcher is pretty much the only part of Forrest that has received any attention in recent years. It may be irresponsible to not release it (from a community development perspective). Ross
Re: Merging back the dispatcher
On 22/04/2010 00:54, Tim Williams wrote: On Mon, Dec 7, 2009 at 6:19 PM, Tim Williamswilliam...@gmail.com wrote: On Sun, Dec 6, 2009 at 9:38 PM, David Crossleycross...@apache.org wrote: Tim Williams wrote: reason I ask, is that we have FOR-1198 and FOR-796 both as blockers No such issue. Rather FOR-1108 and FOR-796. Arghh, typo, Thanks David. So, are we leaving dispatcher in the whiteboard for now? Hate to be a nag, but... are we leaving dispatcher in the whiteboard for the 0.9 release? It's complicated b/c we have [at least] two things working at odds here: 1) dispatcher has come to be in popular use despite its status and 2) being in the whiteboard, it wouldn't make it in the actual release. So, thoughts? I've wanted dispatcher in core since the 0.8 release for this very reason. However, now I'm only an observer here I'll refrain from arguing for or against, just settle with pointing out that I think it would be a mistake to leave it out of 0.9 unless it were to delay the release unreasonably (ahem). If it doesn't go in I would want to see a 0.10 within months with dispatcher in. Ross
Re: Using 0.9 for a new project?
On 06/04/2010 12:36, Tobias Neef wrote: In general I like to participate as much as possible from future Cocoon developments, also the 1.5/1.6 Java compatibility is a pro for the 0.9 version. I haven't used Forrest prior to this so I rely on your help. - Is the 0.9 version stable enough to be used? Hi Tobias, There are quite a few sites using Forrest 0.9-dev in production. It is stable. In fact, it should really have been released some time ago. Of course, like all development versions there can be hiccups. The dispatcher is still not fully stable as we found in a recent merge of the dispatcher branch. The main problem with using 0.9-dev in production right now is the lack of active development that it is undergoing. There are still quite a few of the old devs around (like me for example), but in most cases we are not too active on Forrest. However, you will find your queries answered and pointers provided, so you will not be on your own. - Is there a release timeframe for the stable 0.9 version? There isn't want really. As I mention above, 0.9 is well overdue a release. There is a little housework to be done, but it is pretty much ready to go. - What is the upgrade path between 0.8 to 0.9? see http://forrest.apache.org/docs_0_90/upgrading_09.html In summary I would say that since you indicate that you want to get invovled with development now is a perfect time for Forrest. There are enough old hands still around to help you solve the problems whilst there is plenty of scope for you to achieve whatever you need to achieve for your project. Ross
Re: Blocking Issues
2009/11/24 David Crossley cross...@apache.org: Ross Gardler wrote: David Crossley wrote: Ross Gardler wrote: David Crossley wrote: Ross Gardler wrote: Tim Williams wrote: FOR-855 verify the license situation prior to each release - housekeeping I believe Davids work with RAT fixes this issue. No it does not. There is much more to the job that that. I meant that running RAT shows all licence headers are in place. we still need to do the housekeeping work that is normal due diligence on a release, of course. I meant that FOR-855 has much more than just the license header situation. I have been working on it steadily for a long time now, and there is more to do. OK, I should have reviewed the issue. I have no opinion on whether this is a blocker or not. I assumed that previous releases were legally sound (which I believe they were since we voted them through). We have cut corners on previous releases. Our top-level LICENSE.txt file is not in line with agreed ASF best practice. It is supposed to display relevant licenses for supporting products. Hmm not good. I wonder if this has occured as things have crept into plugins. Perhaps each plugin should have a licence.txt file and the build system should merge them together at build time. Also all supporting product licenses need to be systematically reviewed. Since the last release some things have been haphazardly added to SVN. Also last time we could easily have missed some. I've tried to review every commit for such things. I hope others have been doing the same to catch the ones I miss. I'm pretty sure that a review of licences is already in the release workflow - if not it should be, for the reasons you give. Tim indicated that this was housekeeping which I took to mean the normal due diligence on a release. Yes, but i marked it as Blocker (same process as i did for the previous releases) because a release should not be rolled until the situation is suitable. I'm not saying it is not a blocker, I'm agreeing it is part of the required housekeeping of a release. In other words we are in agreement ;-) I will plod along with FOR-855 and FOR-857 while other people attend to other things. Thank you. I'd like to say I'd help, but to be honest I doubt I'll find the time. Ross
Re: Blocking Issues
2009/11/23 David Crossley cross...@apache.org: Ross Gardler wrote: David Crossley wrote: Ross Gardler wrote: Tim Williams wrote: FOR-855 verify the license situation prior to each release - housekeeping I believe Davids work with RAT fixes this issue. No it does not. There is much more to the job that that. I meant that running RAT shows all licence headers are in place. we still need to do the housekeeping work that is normal due diligence on a release, of course. I meant that FOR-855 has much more than just the license header situation. I have been working on it steadily for a long time now, and there is more to do. OK, I should have reviewed the issue. I have no opinion on whether this is a blocker or not. I assumed that previous releases were legally sound (which I believe they were since we voted them through). Tim indicated that this was housekeeping which I took to mean the normal due diligence on a release. FOR-1177 where does forrest use Rhino Not a blocker Yes it is. At the moment i think that it might be using an unsuitable license. Why? Rhino is dual licensed under GPL and MPL. MPL is compatible, as long as we have the relevant NOTICE file. What am I missing that you are seeing? I will try to clarify it at FOR-1177. When our packaged version of Rhino was prepared, it was probably the old NPL-licensed one. OK, so that's probably a blocker then - we need to update to the MPL version. Ross
Re: Blocking Issues
2009/11/21 David Crossley cross...@apache.org: Ross Gardler wrote: Tim Williams wrote: FOR-855 verify the license situation prior to each release - housekeeping I believe Davids work with RAT fixes this issue. No it does not. There is much more to the job that that. I meant that running RAT shows all licence headers are in place. we still need to do the housekeeping work that is normal due diligence on a release, of course. FOR-1177 ? ? ? ?where does forrest use Rhino Not a blocker Yes it is. At the moment i think that it might be using an unsuitable license. Why? Rhino is dual licensed under GPL and MPL. MPL is compatible, as long as we have the relevant NOTICE file. What am I missing that you are seeing? Ross
Re: Blocking Issues
2009/11/20 Tim Williams william...@gmail.com: Devs, The following are the issues considered blockers. I feel comfortable moving others under lazy consensus to the next release, but I felt there was a higher burden for these. I figure if someone thought they blocked at the time, then I reckon they should get a say... Anyway, can you peruse these issues and comment on any that you feel strongly about? FOR-681 Include xconf files in plugins using includes, not XPatch - I don't know, a blocker? It was reported in 2005 and has not been worked on. I don't see how this can be a blocker for the next release. Is it even relevant anymore? FOR-796 Merge all view/dispatcher work into org.apache.forrest.plugin.internal.dispatcher and org.apache.forrest.themes.core - Thorsten's looking at this now. Not a blocker if the goal is to get a release out. Dispatcher has been holding back Forrest releases since 0.7, it should not block 0.9 too, it's a whiteboard plugin. If it is ready in time then brilliant, if not just get a release out the door since you clearly have some momentum going here. Don't let a nice to have stop that momentum. There's nothing stopping a 0.10 release a few weeks after the 0.9 if someone wants this plugin to go into core soon (highly unlikely given how long this has sat around unfinished but in use on peoples sites). FOR-911 decide content of release - I recommend punting on this one, we can do what we've always done. +1 FOR-868 add relevant notes to the Upgrading xdoc - housekeeping +1 FOR-1108 Dispatcher, Cocoon 2.1 and Windows - I dunno Since dispatcher is a whiteboard plugin I'd say go with it anyway and test/document that dispatcher is broken on windows. This is blocker for dispatcher going into core, not a blocker on a 0.9 release. FOR-591 MaxMemory needs increasing for large document sets: Memory Leak with XMLFileModule - I'll give this another yet another attempt. Sufficient to document for a 0.9 release, the same problem exists in the 0.8 release. FOR-855 verify the license situation prior to each release - housekeeping I believe Davids work with RAT fixes this issue. FOR-1177 where does forrest use Rhino Not a blocker FOR-812 Remove dependency of projectInfo on skinconf.xml - maybe I don't understand it fully, but it doesn't seem like it should block us from a release +1 Thanks for doing all this Tim (and others). I'm afraid this kind of feedback is about all I will be doing towards the release - keep up the great work. Ross
[jira] Commented: (FOR-993) Plugins not finding the optional plugin specific Locationmap causes Errors instead of warnings.
[ https://issues.apache.org/jira/browse/FOR-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12780350#action_12780350 ] Ross Gardler commented on FOR-993: -- See my most recent comment. It ends with: This issue is about reporting an error that is actually a warning. There are two ways to avoid this: 1) report as a warning not an error or 2) force all projects to have a default locationmap (that would normally be empty) This issue is non-issue in my opinion. If it is an issue it is nothing to do with plugins. Gavin appears to have spotted this problem whilst working with plugins, but the behaviour would be the same in any content built with Forrest. Project can OPTIONALLY provide a locationmap, there is no requirement for that to be present. The code reports this as an error, but it should be a warning (see 1. above) If we don't want to see such a warning then we could require projects to have an empty locationmap as a minimum. Personally I think reporting it as a warning not an error is just fine. You could add an optional mount to the locationmap grammar, but why bother? Under what circumstances would it be required and what would you do if it were? If a required match is not provided the build will fail anyway and a warning would have been recorded against the missing locationmap. Adding the extra attribute would just add complexity for the user that brings no value other than reducing some logging information. If I were to spend cycles fxing this I would simply change the error log to a warning. Plugins not finding the optional plugin specific Locationmap causes Errors instead of warnings. --- Key: FOR-993 URL: https://issues.apache.org/jira/browse/FOR-993 Project: Forrest Issue Type: Bug Components: Plugins (general issues) Affects Versions: 0.8 Reporter: Gavin Priority: Minor Fix For: 0.9-dev Whilst checking error logs for another issue, I spotted that the locationmap was not being found. So I tried it in serveral plugins, all with the same result, the locationmap is not being found. The locationmap is normally found in %PROJECT_HOME%/src/documentation/content/ directory Our own site docs it can be found in site-author/content. However for Plugins all the locationmap.xml files are located in %pluginHome%/ root directory. The locationmap.xml file for plugins is not being looked for in root but in the content directory. Example :- ERROR (2007-04-16) 19:13.27:578 [core.modules.mapper.lm] (/index.html) PoolThread-4/SelectNode: Ignoring locationmap config exception: Unable to build LocationMap. org.apache.avalon.framework.configuration.ConfigurationException: Unable to build LocationMap. at org.apache.forrest.locationmap.lm.MountNode.loadConfiguration(MountNode.java:129) at org.apache.forrest.locationmap.lm.MountNode.getLocationMap(MountNode.java:87) at org.apache.forrest.locationmap.lm.MountNode.locate(MountNode.java:157) at org.apache.forrest.locationmap.lm.SelectNode.locate(SelectNode.java:110) at org.apache.forrest.locationmap.lm.LocatorNode.locate(LocatorNode.java:122) at org.apache.forrest.locationmap.lm.LocationMap.locate(LocationMap.java:276) at org.apache.forrest.locationmap.LocationMapModule.getAttribute(LocationMapModule.java:203) at org.apache.cocoon.components.treeprocessor.variables.PreparedVariableResolver.processModule(PreparedVariableResolver.java:246) at org.apache.cocoon.components.treeprocessor.variables.PreparedVariableResolver.resolve(PreparedVariableResolver.java:197) at org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.invoke(SelectNode.java:77) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:155) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:95) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:292) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:223) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:289) at org.apache.cocoon.Cocoon.process(Cocoon.java:557) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:364) at javax.servlet.http.HttpServlet.service
[jira] Commented: (FOR-993) Plugins not finding the optional plugin specific Locationmap causes Errors instead of warnings.
[ https://issues.apache.org/jira/browse/FOR-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12780361#action_12780361 ] Ross Gardler commented on FOR-993: -- Ahhh yes Now I understand your chicken and egg dilemma. I'd still switch it to a warning though. If a locationmap is missing a later processing will throw an error about unfound resources. Plugins not finding the optional plugin specific Locationmap causes Errors instead of warnings. --- Key: FOR-993 URL: https://issues.apache.org/jira/browse/FOR-993 Project: Forrest Issue Type: Bug Components: Plugins (general issues) Affects Versions: 0.8 Reporter: Gavin Priority: Minor Fix For: 0.9-dev Whilst checking error logs for another issue, I spotted that the locationmap was not being found. So I tried it in serveral plugins, all with the same result, the locationmap is not being found. The locationmap is normally found in %PROJECT_HOME%/src/documentation/content/ directory Our own site docs it can be found in site-author/content. However for Plugins all the locationmap.xml files are located in %pluginHome%/ root directory. The locationmap.xml file for plugins is not being looked for in root but in the content directory. Example :- ERROR (2007-04-16) 19:13.27:578 [core.modules.mapper.lm] (/index.html) PoolThread-4/SelectNode: Ignoring locationmap config exception: Unable to build LocationMap. org.apache.avalon.framework.configuration.ConfigurationException: Unable to build LocationMap. at org.apache.forrest.locationmap.lm.MountNode.loadConfiguration(MountNode.java:129) at org.apache.forrest.locationmap.lm.MountNode.getLocationMap(MountNode.java:87) at org.apache.forrest.locationmap.lm.MountNode.locate(MountNode.java:157) at org.apache.forrest.locationmap.lm.SelectNode.locate(SelectNode.java:110) at org.apache.forrest.locationmap.lm.LocatorNode.locate(LocatorNode.java:122) at org.apache.forrest.locationmap.lm.LocationMap.locate(LocationMap.java:276) at org.apache.forrest.locationmap.LocationMapModule.getAttribute(LocationMapModule.java:203) at org.apache.cocoon.components.treeprocessor.variables.PreparedVariableResolver.processModule(PreparedVariableResolver.java:246) at org.apache.cocoon.components.treeprocessor.variables.PreparedVariableResolver.resolve(PreparedVariableResolver.java:197) at org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.invoke(SelectNode.java:77) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:155) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:95) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:292) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:223) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:289) at org.apache.cocoon.Cocoon.process(Cocoon.java:557) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:364) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:354) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) at org.mortbay.http.HttpContext.handle(HttpContext.java:1808) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) at org.mortbay.http.HttpContext.handle(HttpContext.java:1758) at org.mortbay.http.HttpServer.service(HttpServer.java:879) at org.mortbay.http.HttpConnection.service(HttpConnection.java:790) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:952) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:807) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:197) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:501) Caused by: org.apache.excalibur.source.SourceNotFoundException: Exception during processing of cocoon://locationmap-project.xml
Re: problem with feeder plugin
2009/11/2 Vicent Mas uve...@gmail.com: ... This was wrong. The file has not xdoc format. Simply feedDescriptor feed id=BBCSport_UK urlhttp://news.bbc.co.uk/rss/sportonline_uk_edition/front_page/rss.xml/url /feed /feedDescriptor in a file named feedDescriptor.xml works. You mean exactly as documented in http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.input.feeder/samples/singleFeed.html (which you linked to) Thanks for following up onlist, this makes it easier for those coming after you. Clearly the documentation is not very clear, if you can provide a patch for the plugins documentation that would be very much appreciated. Ross
Re: New website using dispatcher
2009/10/25 Vicent Mas uve...@gmail.com: Hi, although I'm worried about the Forrest future (I'm a reader of the Status and future direction thread) Please let me reassure you. Whatever happens Forrest as it exists today is not going away. If it serves your needs today you have nothing to worry about. Ross
Re: svn commit: r825833 - /forrest/trunk/etc/rat-avoid.txt
2009/10/16 cross...@apache.org: Author: crossley Date: Fri Oct 16 10:11:32 2009 New Revision: 825833 URL: http://svn.apache.org/viewvc?rev=825833view=rev Log: More patterns. Issue: FOR-1180 Modified: forrest/trunk/etc/rat-avoid.txt Modified: forrest/trunk/etc/rat-avoid.txt URL: http://svn.apache.org/viewvc/forrest/trunk/etc/rat-avoid.txt?rev=825833r1=825832r2=825833view=diff == --- forrest/trunk/etc/rat-avoid.txt (original) +++ forrest/trunk/etc/rat-avoid.txt Fri Oct 16 10:11:32 2009 @@ -12,6 +12,7 @@ **/jtidy-config.txt **/mime.types **/note.txt +**/notes.txt **/uris.txt I'm pretty sure you can just do things like **/*.txt Ross
Re: svn commit: r826147 - /forrest/trunk/etc/rat-avoid.txt
2009/10/17 cross...@apache.org: Author: crossley Date: Sat Oct 17 00:34:38 2009 New Revision: 826147 URL: http://svn.apache.org/viewvc?rev=826147view=rev Log: More patterns. Issue: FOR-1180 Modified: forrest/trunk/etc/rat-avoid.txt Modified: forrest/trunk/etc/rat-avoid.txt URL: http://svn.apache.org/viewvc/forrest/trunk/etc/rat-avoid.txt?rev=826147r1=826146r2=826147view=diff == --- forrest/trunk/etc/rat-avoid.txt (original) +++ forrest/trunk/etc/rat-avoid.txt Sat Oct 17 00:34:38 2009 @@ -5,8 +5,11 @@ etc/ main/var/*.txt **/.classpath +**/.mymetadata **/.project -**/.settings +**/.settings** +**/.springBeans +**/.wicketprops and **/.* Ross
Re: [Important] Status and future direction
2009/10/16 Gavin ga...@16degrees.com.au: -Original Message- From: Ross Gardler [mailto:ross.gard...@googlemail.com] Sent: Friday, 9 October 2009 5:08 AM To: dev@forrest.apache.org Cc: dev@forrest.apache.org Subject: Re: [Important] Status and future direction I agree with Tim here, especially the bit where he can't agree with me more ;-) I don't know a great deal about Cocoon 3, but I have no personal interest in using it here - sledgehammer to crack a nut. Since I'm not active here my opinion doesn't count for much in that respect though. If someone wanted to look at and validate my evening hacks on Forrest 2 I might be drawn back in, I do have a need for such a lightweight and embeddable solution. However, I don't have the time or resources to drive forward alone on this. I seem to be in the same camp as Ross and Tim. When it comes to the Cocoon side of things, even after all this time it is a maze [/haze] to me. I would like to take a look at Forrest2 more before deciding if that could be a possible future or not. A couple of questions on Forrest2 How usable is it right now? It isn't usable at all. I merely hacked together a very rough prototype to illustrate what I was talking about. It works in a very small number of test cases that are designed to demonstrate rather than implement. Does it depend on our current core in any way or can the Forrest2 directory tree be moved away and still work independently? It is fully independent. How far off do you think it is in terms of the tools that our current Forrest offers? (can you drop an odt file in from our current plugin system and get a tei output for example) See above - it is a long way off. This is *not* the right route if people are not fully supportive of the idea. Ross
Re: [Important] Status and future direction
2009/10/16 David Crossley cross...@apache.org: Gavin wrote: Either way, it looks like we should be voting soon on this, ... I disagree. We need to hear from more people. There are more Forrest PMC members, and there are over 100 people subscribed to this dev list. Yes, there is no need to rush this. It's a very important decision to make and we need to be sure to make the right one. So far there have been two opposing views expressed, but I still see nobody actually stepping up to do the work. Opinions (like mine) are irrlevent unless they are followed through on. Ross
Re: [Important] Status and future direction
2009/10/12 David Crossley cross...@apache.org: What is development and developer in the context of Forrest? IMO every person who creates a documentation presentation system using Forrest is a developer. A developer in the context of an open source project is someone who is contributing to the ongoing sustainability of the project itself. SOmeone who makes sure their own use of the tool is helping others. IMO if the requirement is for a basic website, then Forrest is not the correct tool. Agreed - but that is what most users are using it for. On the other hand, if the content needs to be drawn from various different places, and integrated, and perhaps some specific content handled and presented in different ways. Then Forrest is relevant. I disagree, Forrest *used* to be relevant. In my opinion it is too hard to get anyting done these days. That's why I no longer use it in new projects. It's easier to do per site systems now, at least it is for me. You may have different views. One needs to be a developer to enhance the current set of plugins or to create new, perhaps private, plugins. For example i have an on-line store plugin for one of our websites. Sure, but *you* have it. Why doesn't Forrest? That's the difference between a user and a developer here. For Forrest to survive the people who are still finding it useful need to step forward and move the project onwards and stop relying on people like me who used to find it useful but no longer do so. Configuring sitemaps and stuff requires a developer. IMO the sitemap and locationmap are fantastic. I agree to an extend, that's why I spent so many thousands of hourse working on those features (along with many others). Who is working on it now? Ross
Re: [Important] Status and future direction
2009/10/12 Johannes Schaefer johannes.schae...@uid.com: Hello from a lurking user and committer! I'm top-posting because I just want to add our use case to the discussion which is different from producing a web site and maybe closer to the original vision of Forrest. Thanks... There's much room for Forrest to improve, we always have some hassles when a new project starts and a long wish list. We don't have the resources to add substantially to Forrest beyond our internal hacks :-( That, in my opinion is the problem. I find it easier to do internal hacks of non-Forrest solutions than to work with Forrest now. Technology has moved on since we started Forrest and Forrest has not done so. We got bedded down chasing our own tales for a long time and we never came out of it. If Forrest was simpler and could be used as a library rather than as a monolithic system I think we would have some realy developers rather than real users. If been involved with Forrest since day one, if even I find it easier to hack around than to build decent reusable code then I think that is a symptom of a problem. What I'm reading in this thread from those other than the usual suspects is that the symptoms are seen elsewehere too. How do we solve that? Ross
Re: release process
2009/10/12 David Crossley cross...@apache.org: Thorsten Scherler wrote: IMO A should be the way to wrap up current development. Like pointed out by David we need to have a release that contains the work of the last years since the release. It may require two releases in reasonably quick succession. Otherwise we risk holding up the release for more ages. Or even a release every 2-3 months regardless of the state of development. I think one of our mistakes has been to wait for features to be finished before releasing. Then they've been redesigned, rejigged and broken. Look at Locationmap - it took us three years to get that code in, once in it was tidied up and polished. The XML config system was put into the last release as an undocumented feature and, as a result has seen significant work and is now ready for official release (yet there has been no release). It used to be just David doing releases. We discussed and agreed more frequent releases. So I an Ferdinand cut a release. From memory I think that was the last release Forrest had. All good intentions, but no action. The last release was much easier with those notes. +1000 - the process isn't actually that hard. It only looks complex because it is well documented. Ironically, as David says, it is this documentation that makes the process easier. Ross Ross -- Ross Gardler OSS Watch - supporting open source in education and research http://www.oss-watch.ac.uk
Re: [Important] Status and future direction
2009/10/9 Thorsten Scherler thors...@apache.org: On 08/10/2009, at 21:07, Ross Gardler wrote: I agree with Tim here, especially the bit where he can't agree with me more ;-) I don't know a great deal about Cocoon 3, but I have no personal interest in using it here - sledgehammer to crack a nut. Since I'm not active here my opinion doesn't count for much in that respect though. I am still developing mostly with cocoon in different versions. Just a couple of days back I had a chance to use cocoon 3 within droids and I have to say it is not sledgehammer anymore. You can use it without any sitemap if you want. ... When the work on Cocoon 3 started I was excited that many of the concepts and ideas were what I was calling for in Forrest 2 (embeddability, simplicty, programmatic control etc.) I've not kept up with it, if you have and you say it is not a sledgehammer then I'm happy to listen. On 8 Oct 2009, at 13:35, Tim Williams william...@gmail.com wrote: ... I have to admit that I am not sure about whole discussion about the future of forrest. We have a working product with a small committer community behind it. Our user base however is I guess larger then we imagine however we do not know them since forrest seems to just work. So no problems = no mails = no traffic. I think this is true. Forrest is great for knocking together web sites. If that's all you want then plain vanilla Forrest is great, presents no problems and therefore no traffic. Regarding the traffic on our commit lists is similar, we do not add any new functionality to forrest for a while now and more or less maintain the code we have with the feedback from the list and individual test cases. Here I disagree though. Forrest was originally created as a way of combining content from multiple sources in a single output format. However, the only well supported output format is HTML, so if you want to create web pages it's great. There are some well supported input formats, but most users just use XDoc. Hence Forrest is used to create web pages and nothing more. At its height we had developers who needed the more advanced features of merging data formats. However, we live in a different world today, most data is available in some kind of syndicated feed that can be passed through a simple XSL sheet and we're done. We don't need complex pipelining anymore - if we do then there are a number of simple GUI tools to provide them in a much simpler way than Forrest does. The world has moved on and the original vision of Forrest, IMHO, is no longer relevant. It is for this reason that we are not seeing new features - it is not feature complete with respect to the original vision (where's version 1?) The fear that I have that we will replace one complex beast with another. This is a legitimate fear. If that's where this discussion took us then you can count me out. Does our framework of input, internal and output plugins can be slimed down to a jar that I can add to my standard project where I need SOME of the functionality but not all? IMHO yes - see my weekend hacks on Forrest 2 - that's exactly what this is (in proof of concept form). If we remove the complex pipelining and focus on embeddable data translation I think there is still a space for Forrest. Whilst some people might want the pipelining features (to produce websites for example) this should not be a part of core Forrest. I'd not object, in fact I proposed, that Forrest translations should be embeddable in Cocoon to provide these pipelining features. If we did it this way round we would remove the dependency on Cocoon, thus allowing us to proceed independently of that (or any other project). In which programming language do we want to develop to start with? At this stage I don't care. I think that would be a diversion from the important topic of whether it should be done at all. I do not see forrest in the attic neither. There are still quite a bunch of code in our rep that attracts people with certain usecase. The attic is for code that is not being maintained. It does not mean it has no users. The fact that this conversation is happening shows that there is some oversight, but how many of us have done anything really useful for Forrest in the last 18 months? (not me) Can those who have kept the project alive continue to do so? If so why hasn't there been a release? I know I have grown tired of answering questions for a project I no longer use in new projects and is not under active development. There have been two people in this thread say they think the right route is X - so who is going to actually do it? If someone leads, others may follow. Ross -- Ross Gardler OSS Watch - supporting open source in education and research http://www.oss-watch.ac.uk
Re: [Important] Status and future direction
I agree with Sent from my mobile device. On 8 Oct 2009, at 13:35, Tim Williams william...@gmail.com wrote: Thanks David, this is a tough, but necessary, conversation. I snipped A and B because I don't consider them fruitful options at all. C) Try to upgrade to Cocoon-3 version. I don't know whether Cocoon-3 is ready or possible for Forrest. Would someone else comment. Cocoon-3 seems ready from what I can tell, though it is already suffering from the same things that drove me away from enjoying regular Cocoon. It's overly complex. There was a time when the return on the steep Cocoon learning curve was worth it but that time, for me, has passed. I now have minimum amount of spare time to hack at Forrest and when I've tried lately, it's no longer a pleasure primarily because I spend much of that time re-learning Cocoon complexity instead of being productive. I must admit that when I was at the height of my Cocoon knowledge I was unempathetic to Ross' pleas, but now, I probably couldn't agree with his sentiments more. Anyway, I think this is a long way of saying that i honestly don't see there being a future in a Cocoon-based Forrest. D) Develop some other core. See past discussion in our dev mail archives. I think it's ultimately going to be this or the Attic. Implementing something that's intuitive, prefers convention, and doesn't attempt to solve all problems could very well bring the fun back. I think we'd have a much easier time attracting new devs too since we wouldn't have the problem of yeah, forrest is easy to understand *after* you understand this other ridiculously complex beast over there. E) Cease Forrest and move to the Apache Attic. http://attic.apache.org/ I think there is a niche out there for Forrest. I've got a need now, for example, for a simple documentation site but, unfortunately, forrest is too much of a burden to use for it - documentation is a side-show that people don't want to have to spend hours/days coming up to speed. So I sincerely hope this option isn't where we end up. ---oOo--- Whatever happens, we still need to make a release. Agreed, I've been poking around at JIRA lately seeing what I can tackle - as i mentioned the Cocoon (re)-learning curve has kept me pretty unproductive though. Whatever happens, more people need to assist with the project management tasks. Agreed, since I haven't contributed much lately to the coding, I haven't been compelled to contribute at all. That's not good, I know. ---oOo--- My opinion is that Forrest needs to make a decision about which direction, and stick with it, developers get involved to start Forrest moving again, and build the community. Options A to D have previous discussion in the dev mail archives. Again, I think D or E are the only viable long-term options. --tim
Re: [Important] Status and future direction
I agree with Tim here, especially the bit where he can't agree with me more ;-) I don't know a great deal about Cocoon 3, but I have no personal interest in using it here - sledgehammer to crack a nut. Since I'm not active here my opinion doesn't count for much in that respect though. If someone wanted to look at and validate my evening hacks on Forrest 2 I might be drawn back in, I do have a need for such a lightweight and embeddable solution. However, I don't have the time or resources to drive forward alone on thIs. David, thank you for raising this issue. Sorry about top posting... Sent from my mobile device. On 8 Oct 2009, at 13:35, Tim Williams william...@gmail.com wrote: Thanks David, this is a tough, but necessary, conversation. I snipped A and B because I don't consider them fruitful options at all. C) Try to upgrade to Cocoon-3 version. I don't know whether Cocoon-3 is ready or possible for Forrest. Would someone else comment. Cocoon-3 seems ready from what I can tell, though it is already suffering from the same things that drove me away from enjoying regular Cocoon. It's overly complex. There was a time when the return on the steep Cocoon learning curve was worth it but that time, for me, has passed. I now have minimum amount of spare time to hack at Forrest and when I've tried lately, it's no longer a pleasure primarily because I spend much of that time re-learning Cocoon complexity instead of being productive. I must admit that when I was at the height of my Cocoon knowledge I was unempathetic to Ross' pleas, but now, I probably couldn't agree with his sentiments more. Anyway, I think this is a long way of saying that i honestly don't see there being a future in a Cocoon-based Forrest. D) Develop some other core. See past discussion in our dev mail archives. I think it's ultimately going to be this or the Attic. Implementing something that's intuitive, prefers convention, and doesn't attempt to solve all problems could very well bring the fun back. I think we'd have a much easier time attracting new devs too since we wouldn't have the problem of yeah, forrest is easy to understand *after* you understand this other ridiculously complex beast over there. E) Cease Forrest and move to the Apache Attic. http://attic.apache.org/ I think there is a niche out there for Forrest. I've got a need now, for example, for a simple documentation site but, unfortunately, forrest is too much of a burden to use for it - documentation is a side-show that people don't want to have to spend hours/days coming up to speed. So I sincerely hope this option isn't where we end up. ---oOo--- Whatever happens, we still need to make a release. Agreed, I've been poking around at JIRA lately seeing what I can tackle - as i mentioned the Cocoon (re)-learning curve has kept me pretty unproductive though. Whatever happens, more people need to assist with the project management tasks. Agreed, since I haven't contributed much lately to the coding, I haven't been compelled to contribute at all. That's not good, I know. ---oOo--- My opinion is that Forrest needs to make a decision about which direction, and stick with it, developers get involved to start Forrest moving again, and build the community. Options A to D have previous discussion in the dev mail archives. Again, I think D or E are the only viable long-term options. --tim
Fwd: board: r19010 - /foundation/board/board_agenda_2009_08_19.txt
I just noticed this addition to the board report for Forrest and have not noticed a copy of it going to our developer list. I totally agree with this addition and thank David for adding it. My purpose for forwarding here is to highlight this issue to the widest possible community. In short we would welcome someone building a release for Forrest - anyone can do it and as David says it is well documented (and I'm sure people will come out of the woodwork to help in the odd spare minute). Ross -- Forwarded message -- From: cross...@apache.org Date: 2009/8/19 Subject: board: r19010 - /foundation/board/board_agenda_2009_08_19.txt To: board-...@apache.org Author: crossley Date: Wed Aug 19 08:03:49 2009 New Revision: 19010 Log: Reply to Forrest comment from rf. Modified: foundation/board/board_agenda_2009_08_19.txt Modified: foundation/board/board_agenda_2009_08_19.txt == --- foundation/board/board_agenda_2009_08_19.txt (original) +++ foundation/board/board_agenda_2009_08_19.txt Wed Aug 19 08:03:49 2009 @@ -435,6 +435,12 @@ [ approved: jj, dc, rf comments: rf: no releases in 2.33 years? why not? + crossley: One reason is that no one has stepped forward to be the Release + Manager. As we all know, that takes some effort. Also as our + past board reports indicate, the developers seem busy with other + things. It could release now as-is, the process is well-defined. + There are some improvements that developers have hoped to + integrate, but not yet managed to do. ] L. Apache HTTP Server Project [William A. Rowe Jr. / Brett] -- Ross Gardler OSS Watch - supporting open source in education and research http://www.oss-watch.ac.uk
Re: prompting a release (Was: r19010 ... board_agenda_2009_08_19.txt
2009/8/19 David Crossley cross...@apache.org: Ross Gardler wrote: I just noticed this addition to the board report for Forrest and have not noticed a copy of it going to our developer list. They are unpublished agenda items, so the dev list is not usually copied. Yes, you are right, I should have repurposed your text. However, there is nothing private in what I posted so no harm done. In short we would welcome someone building a release for Forrest - anyone can do it and as David says it is well documented (and I'm sure people will come out of the woodwork to help in the odd spare minute). Thanks. (just leving the key message in). Ross
Re: ical output plugin - sitemap feedback wanted
2009/8/19 David Crossley cross...@apache.org:
Sjur Moshagen wrote:
Hello all,
For a long time our project group has been using an ical output
project module that I'm now converting to a real plugin, which I
intend to add to the whiteboard. For historical reasons, the url
pattern matched against presupposes a certain file naming scheme, as
follows:
!-- Will match weekly meeting files {2}, and extract the tasks for
the
person in {3}, returning the task list as an iCal TODO list --
map:match pattern=**/Tasks_*_*.ics
map:generate src=cocoon://{1}/Meeting_{2}.xml /
map:transform src={lm:ical.transform.document.ics}
map:parameter name=date value={2} /
map:parameter name=person value={3} /
/map:transform
map:serialize type=ical /
/map:match
That is, the meeting date is encoded in the filename, and the person
for which the ical file should be created is encoded in the URL in
addition to the date. Also, the filename is fixed to the pattern
Meeting_{DATE}.xml (or actually *.jspwiki in our case). Is this ok,
or should I change to a more general pattern? One reasoning is that it
doesn't make sense to create an ical file for a non-meeting document,
and this dependency is expressed in the URL and filename patterns. But
then again, the whole plugin depends on certain conventions in the
source document, so you can anyway add non-working links (ie link to
meeting documents that do not follow these conventions).
Comments on the URL or filename patterns? Other comments?
This is exiting. That seems like a fine approach to me.
I agree that it's great to see some new work here. I don't quite agree
that the URL patterns is a fine approach though. But don't worry,
it's a small change I am going to propose and it is backward
compatible with your current scheme.
Basically, some time ago we decided that fixed url patterns were a bad
idea since it creates potential clashes in peoples applications. We
therefore implemented the new (although not officially released) XML
properties system to allow the sitemap to be easily configured without
having to edit the plugin files (actually that was a side effect, but
that's not relevant right now).
You can see an example of this approach in use in the Daisy input
plugin (whiteboard):
input.xmap:
map:match
pattern={properties:daisy.pathPrefix}*{properties:daisy.fileExt}.xml
map:call resource=daisy-to-document
map:parameter name=docID value={1}/
map:parameter name=path value={0}/
/map:call
/map:match
forrest.properties.xml:
property name=daisy.pathPrefix value=/
...
property name=daisy.fileExt value=.daisy/
Now the project can override these properties in its local
forrest.properties.xml if it needs to do so, or it can leave them at
their defaults for the same behaviour as your existing sitemap.
Ross
Re: missing license headers
2009/7/20 David Crossley cross...@apache.org: While doing the scan to ensure that our licensing is in order, i found some anomalies. ... Ross: whiteboard/plugins/org.apache.forrest.plugin.input.tei/resources/stylesheets/tei-to-document.xsl whiteboard/plugins/org.apache.forrest.plugin.output.tei/resources/stylesheets/document-to-teiLite.xsl Thanks David. Sorry about that. I can confirm that each of these has been contributed with the intent to licence to the ASF. I don't have a checkout of Forrest at present. I'll add these ASAP (as it happens I need to do some Forrest work this afternoon if I get time). Ross
Re: svn commit: r782008 - /forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.input.skos/src/documentation/content/xdocs/index.xml
2009/6/5 s...@apache.org: Author: sina Date: Fri Jun 5 13:11:58 2009 Welcome Sina. Ross
Re: How can I use class lists with XDocs?
2009/5/14 Brolin Empey bro...@brolin.be: 2009/5/13 David Crossley cross...@apache.org That is what i thought too. Done now. Thanks! I can use class lists in XDocs after updating my working copy of Forrest. I should have asked about this limitation earlier because I had resorted to a kludge by hacking the generated HTML to add the additional class. By asking early we can also help you come up with more efficienct workarounds. before you know it you'll be submitting simple patches and beoming a committer ;-) Welcome to Apache Forrest. Ross -- Ross Gardler OSS Watch - supporting open source in education and research http://www.oss-watch.ac.uk
Re: reducing duplication in menus with pelt skin
2009/5/5 Brolin Empey bro...@brolin.be: Hello, See the Products menu on the left side of http://medallionsystem.com/. Currently, clicking on either the triangular bullet to the left of Products or on Products expands and collapses the Products menu. The first child in the menu is Products. Is it possible to make the top-level Products a link so that Products is not duplicated in the menu? Then the triangular bullet would have to be used to expand and collapse the Products menu. (sorry for the dealy in response) To do this you will need to hack the javascript that does the menu expansion to instruct the browser to open the index page as well as expand the menu item. This is easy enough if you know Javascript, less so if you don't. Alternatively you could make all the menu items expanded by default. I can't recall if we have a switch to do this, if this is something you want to explore let us know. Ross
Re: class attribute of body element in XDocs source is not included in generated HTML
2009/5/15 Brolin Empey bro...@brolin.be: I asked about this months ago, but will ask again because the issue still exists in the current version of Forrest. The last time I asked, I was using a release version. Here is the body element of my XDocs source file: body class=product_heading The generated HTML does not include the class attribute. Is there any way to get the class attribute included in the generated HTML? I guess this is a Cocoon issue. It is annoying because I have to hack the generated HTML to add the class attribute. This is not a Cocoon issue. It will be stripped by one of our XSLT files. The question is, which one... To narrow the possibilities request http://localhost:/foo.xml This will return the intermediate format used by forrest (i.e. what we have after all input side plugins have been executed). Does the class attribute exist? If not then it is the input side XSLT that is stripping it, since you indicate your source is in XDoc I assume you are not using an input plugin and therefore it is in the core stylesheets, see http://svn.apache.org/repos/asf/forrest/trunk/main/webapp/resources/stylesheets/ It would really help you in tracking this problem if you familiarise yourself with the Forrest processing pipelines, but brute force examination of likely looking stylesheets may get you there. If the class information appears in the intermediate format then the problem is on the output side. Since you are talking about HTML then the issue wll be somewhere in the skin stylesheets. Sorry I can't be more specific, I don't have the time to track the problem myself, I hope this info helps get you started debugging. Ross -- Sometimes I forget how to do small talk: http://xkcd.com/222/ “What if there were no hypothetical questions?” — George Carlin -- Ross Gardler OSS Watch - supporting open source in education and research http://www.oss-watch.ac.uk
Re: Simple include files?
2009/5/16 Gavin ga...@16degrees.com.au: From: Brolin Empey [mailto:bro...@brolin.be] Sent: Saturday, 16 May 2009 9:40 AM To: dev@forrest.apache.org Subject: Re: Simple include files? 2009/5/14 Gavin ga...@16degrees.com.au P.S. - It makes it easier for replies to be inline if you post as plain text instead of html ;) What is so difficult about replying inline to an HTML message? I have no trouble doing so. It depends on the clinet being used - some don't do it will (like MS Outlook) However, more importantly, many mail archives don't play well with HTML emails and they are are really nasty for those not able to use a graphical email client (i.e. Pine over and SSH tunnel whilst traveling or some text readers). Then there is the issue of bloat in the document etc. All in all it's an etiquette issue when it comes to mailing lists. Ross
Re: class attribute of body element in XDocs source is not included in generated HTML
2009/5/16 Brolin Empey bro...@brolin.be: Thanks for the quick replies! I created FOR-1167 because I do not feel like debugging this issue. I know, I am lazy, but my kludgey workaround works fine. ;) Thanks for recording the issue and linking to this thread. Now it is self-documenting up to the point we have it. Ross -- Ross Gardler OSS Watch - supporting open source in education and research http://www.oss-watch.ac.uk
Re: Simple include files?
2009/5/16 Brolin Empey bro...@brolin.be: 2009/5/15 Gavin ga...@16degrees.com.au ... Anyway, can we please get back on track? Can someone please change the XDocs DTDs so I can use xi:include/ as a child of a table (after the optional caption)? Provide a patch via our issue tracker and I'm sure someone will apply it (not me, I don't have a current checkout of Forrest right now I'm afraid). Ross -- Ross Gardler OSS Watch - supporting open source in education and research http://www.oss-watch.ac.uk
Re: problem skinning legacy html
2009/4/11 Vicent Mas uve...@gmail.com: I've searched for help in the mailing list archives with no luck. How can I fix these problems? Without specific examples of the source, output and processing pipelines it would be impossible to answer this. Ross -- Ross Gardler OSS Watch - supporting open source in education and research http://www.oss-watch.ac.uk
Re: local-deploy on project-internal plugin
2009/3/23 Sjur Moshagen sju...@mac.com:
Replying to myself:
Den 23. mar. 2009 kl. 14.59 skrev Sjur Moshagen:
The action on line 117 in that build file reads:
copy toDir=${forrest.plugins.localDeploy.dir}/${plugin-name}
fileset dir=${forrest.plugins.dir}/${plugin-name}
exclude name=lib/**/
exclude name=build/**/
/fileset
/copy
If I change this to the following:
copy toDir=${forrest.plugins.localDeploy.dir}/${plugin-name}
fileset dir=${forrest.plugins.dir}
exclude name=lib/**/
exclude name=build/**/
/fileset
/copy
it works ok (cf the second line, where I removed the ${plugin-name}
variable). But this would probably break the regular plugin deployment. This
file has not been touched since end of April 2007, and bugs here would
certainly have been found much earlier.
The code to allow a customisable local directory is much newer than
that. So you probably want to look there.
Ross
--
Ross Gardler
OSS Watch - supporting open source in education and research
http://www.oss-watch.ac.uk
Re: murmurs of a release
2009/3/18 David Crossley cross...@apache.org: Gavin wrote: Thorsten Scherler I hope that people will give me support (as they always did) when I shortly will merge back the dispatcher rewrite and volunteer to get a long overdue forrest 0.9 release out. Go Thorsten If you want to get together at ApacheCon and force me to do some testing I'd be happy to do so (if you can get hold of me for long enough). At present Tuesday AM is the only time I have pretty free in Hackathon time. Failing to trap me at ApacheCon will probably mean I don't do any testing. I don't have the cycles right now. Ross
Re: [jira] Commented: (FOR-1160) Enhanced locationmap documentation, added example and fixed some typos
2009/3/11 David Crossley cross...@apache.org: Ross Gardler wrote: EMMEL Thomas wrote Ok, next time, I keep an eye on that ;-) Thanks for your patch Emmel, it is much appreciated. Thank you David for applying it, ... Thanks Gavin instead. Sorry Gavin - Thanks Gavin ;-) Ross -- -- Ross Gardler OSS Watch - awareness and understanding of open source software development and use in education http://www.oss-watch.ac.uk
Re: [jira] Commented: (FOR-1160) Enhanced locationmap documentation, added example and fixed some typos
2009/3/3 EMMEL Thomas thomas.em...@3ds.com: Ok, next time, I keep an eye on that ;-) Thanks for your patch Emmel, it is much appreciated. Thank you David for applying it, I really should put a version of Forrest on my day job machine, but we don't use it here at present :-( Ross David Crossley (JIRA) schrieb: [ https://issues.apache.org/jira/browse/FOR-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12678295#action_12678295 ] David Crossley commented on FOR-1160: - Thanks Thomas. When reviewing, i noticed that there was extra stuff added at the bottom about LocalWords. I removed that. Also we don't use tabs in any text file. I removed those. We are gradually reviewing docs to use CDATA sections in the source elements. No need to escape etc. so easier to manage changes to such xml listing content. Enhanced locationmap documentation, added example and fixed some typos -- Key: FOR-1160 URL: https://issues.apache.org/jira/browse/FOR-1160 Project: Forrest Issue Type: Improvement Components: Documentation and website, Locationmap Affects Versions: 0.9-dev Reporter: Thomas Emmel Priority: Minor Fix For: 0.9-dev Attachments: docs_0_90-locationmap.xml.diff Hi, during the last days I investigated the way forrest uses the locationmap, which I need to enhance the output for PDF (FOP). Therefore I added some more documentation to this section which (hopefully) shed some more light into this area and give an example that might be useful for others. Thomas -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- -- Ross Gardler OSS Watch - awareness and understanding of open source software development and use in education http://www.oss-watch.ac.uk
Re: site-author - no output during forrest run
2009/3/3 Gavin ga...@16degrees.com.au: I just tried doing a forrest run on the site-author docs, although jetty runs fine, no html pages are output, and no .xml pages are available either. It has been a while since I tried building site-author directly, so this may be a windows issue not yet come up, just wanted others to confirm that site-author on trunk builds and runs fine ? The tests in our zone are working fine: http://forrest.zones.apache.org/ft/build/forrest-docs/ Last Published: 03/03/2009 12:12:22 Look slike you broke your local copy ;-) Ross -- -- Ross Gardler OSS Watch - awareness and understanding of open source software development and use in education http://www.oss-watch.ac.uk
Re: Applying patches
2009/3/3 David Crossley cross...@apache.org: Ross Gardler wrote: Further to Davids recent developers must help developers email, To be clear, i deliberately did not use the word must. Instead i chose need to. People do whatever they like. However developers do need to help each other, to keep any project happening. Yeah, sorry David. Ross
Applying patches
Further to Davids recent developers must help developers email, can I point out that recently some of us have been actively helping a new contributor. That contributor has provided a useful patch to our docs in direct response to our assistance and has identified a potential problem in our FO stylesheets. At this time I do not have a development version of Forrest on any of my machines. Someone needs to apply this patch otherwsie all our efforts are wasted. Can someone please apply the patch supplied and thank the contributor. Ross -- -- Ross Gardler OSS Watch - awareness and understanding of open source software development and use in education http://www.oss-watch.ac.uk
Re: plugin: output.pdf: a not resolved in helper-commonElements.xsl, bug or feature?
2009/2/27 EMMEL Thomas thomas.em...@3ds.com: Ross Gardler schrieb: ... Such a hole would not show up when converting to HTML as the a element is legal there and would be passed through unmodified by the internal processing. However, given that Forrest is in use in a great many places and this hasn't raised it's head before I want to check everything is in order. To that end we need an answer to my earlier question Under what circumstances do you find a document containing an a gets processed by this stylesheet? Ross Ross, I think this is connected to my own dtd, since I need some new elements and change others. For the default document-v20.dtd everything works fine. However, I never touched a inside my dtd, therefore I think it might be a general problem since it happens all the time I use an own dtd. For example I do a forrest seed, create a new dtd as described in the documentation that is only a copy to the document-v20.dtd, e.g. myown-v12.dtd: !ENTITY % common-charents PUBLIC -//APACHE//ENTITIES Common Character Entity Sets V1.0//EN common-charents-v10.mod %common-charents; !ENTITY % document PUBLIC -//APACHE//ENTITIES Documentation V2.0//EN document-v20.mod %document; and refere to it in a document like this: ?xml version=1.0 encoding=UTF-8? !DOCTYPE greeting PUBLIC -//Test//DTD myown V1.2//EN myown-v12.dtd document header titletest/title /header body ptest this link: a href=http://forrest.apache.org;Forrest/a./p /body /document I create the xcat-entry and run forrest Now, everything works fine for html-output, but fo and pdf miss the link. Any idea? How is the above document processed? you should have an input plugin that convers myown-v12.dtd to the internal XDoc v1.3, thus you would not have any a elements internally only link, jump and fork. I note that this is not clear in our docs. You can choose to proceed as you are, but you need to be aware that if you start using other output plugins you will continue to loose links. However, since it works in HTML and your proposed change is quite minor and will not affect users who are not making the kind of change you suggest I'd be OK with that change going into the release. It does not break backward compatability and would be correct if we eventually move to XHTML2 subset anyway. Feel free to provide a patch, please refer to this thread in the description so that we can see why it is provided. Ross Ross
Re: question to FOR-1136 and locationmap.xml not found
2009/2/25 EMMEL Thomas thomas.em...@3ds.com: In addition I realy like to understand how the locationmap-thing works but I cannot find enough input to understand the complete work-flow and debugging is very hard... I'm going to paste links to sections of the docs that are supposed to answer your questions. Of course, it's easy for me to understand these as I already understand the locaitonmap. Please read the docs and come back to us with more specific questions. We'll try and answer in more detail but note that we will expect you to repay our time by providing patches for the docs so that others can benefit. Start here: http://forrest.apache.org/docs_0_80/locationmap.html For example there is a locationmap.xml and maybe a locationmap-project.xml but I don't know when they are used http://forrest.apache.org/docs_0_80/locationmap.html#process and where they should be stored, due to my problems above that no local locationmap after all will be read. http://forrest.apache.org/docs_0_80/locationmap.html#overview -- -- Ross Gardler OSS Watch - awareness and understanding of open source software development and use in education http://www.oss-watch.ac.uk
Re: plugin: output.pdf: a not resolved in helper-commonElements.xsl, bug or feature?
2009/2/26 EMMEL Thomas thomas.em...@3ds.com: Hi, there is a line in plugins/org.apache.forrest.plugin.output.pdf/resources/stylesheets/helper-commonElements.xsl which I changed locally for me: @@ -368,7 +368,7 @@ xsl:apply-templates/ /fo:block /xsl:template - xsl:template match=link|fork|jump + xsl:template match=link|fork|jump|a xsl:variable name=color select=$config/colors/col...@name = 'body']/@link/ xsl:choose Is it a bug or feature that a/a is not supported here? If I add it, the links will be activated, however they might be not useful in all cases yet when generating the wholesite.pdf, where external links need to be changed to internal links... In theory it is feature. Internally Forrest does not have the a element. Under what circumstances do you find a document containing an a gets processed by this stylesheet? Ross -- -- Ross Gardler OSS Watch - awareness and understanding of open source software development and use in education http://www.oss-watch.ac.uk
Re: plugin: output.pdf: a not resolved in helper-commonElements.xsl, bug or feature?
2009/2/26 EMMEL Thomas thomas.em...@3ds.com: Ross Gardler schrieb: 2009/2/26 EMMEL Thomas thomas.em...@3ds.com: Hi, there is a line in plugins/org.apache.forrest.plugin.output.pdf/resources/stylesheets/helper-commonElements.xsl which I changed locally for me: @@ -368,7 +368,7 @@ xsl:apply-templates/ /fo:block /xsl:template - xsl:template match=link|fork|jump + xsl:template match=link|fork|jump|a xsl:variable name=color select=$config/colors/col...@name = 'body']/@link/ xsl:choose Is it a bug or feature that a/a is not supported here? If I add it, the links will be activated, however they might be not useful in all cases yet when generating the wholesite.pdf, where external links need to be changed to internal links... In theory it is feature. Internally Forrest does not have the a element. Under what circumstances do you find a document containing an a gets processed by this stylesheet? ... Confusion a is the first element documented in the document-v20.dtd and is therefore very valid element in forrest I think. http://forrest.apache.org/dtdx/document-v20.dtdx.html#a I use it everywhere I need a link since link and fork and jump are not in the DTD... Do I miss something? Forrest does not use the V2 DTD *internally*, it uses the V1.3 DTD [1]. This is because of history rather than design. Ultimately the intention is to move to a sbset of XHTML2 on the internals. XDoc V2 is pretty much this subset already (give or take a few bits and pieces). However, this has been the plan for a very long time and doesn't look like being implemented any time soon - it's a major rewrite of both input and output stylesheets. It is likely that there is no harm in adding the match that you identify. However, until we understand the circumstances in which you are managing to get that element to the output plugin it is hard to say. I'm worried that you might be doing something that bypasses the internal processing (which is bad) or that we have a hole in one of the internal processes. Such a hole would not show up when converting to HTML as the a element is legal there and would be passed through unmodified by the internal processing. However, given that Forrest is in use in a great many places and this hasn't raised it's head before I want to check everything is in order. To that end we need an answer to my earlier question Under what circumstances do you find a document containing an a gets processed by this stylesheet? Ross [1] http://forrest.apache.org/dtdx/document-v13.dtdx.html -- -- Ross Gardler OSS Watch - awareness and understanding of open source software development and use in education http://www.oss-watch.ac.uk
Re: Merge output plugins OpenOffice.org-output with OOo
Gavin wrote: Hi All, A little while back it was suggested that we remove the old OpenOffice.org-output plugin in favour of the newer OOo output plugin. There was at least one voice that said the former was still useful. Both do different jobs, one outputs in the older .xsi format whilst the newer OOo currently outputs in .odt format (2.4+) Well, what about a merger? Sensible route. Ross
Re: Piwi - Forrest in PHP
On 22 Dec 2008, at 11:44, Christian Grobmeier wrote: Hi all, sorry for my delay. My gmail account somehow skipped all the replies from my inbox. :-) Here are the answers for the first bunch of questions. - Crawler for static content generation - Forms (easy create web forms and assistants) Form Validation How do you justify the decision to implement forms support *and* static generation. We've always been of the opinion that they are mutually exclusive. Forrest does support forms, but not out of the box. What happens when forms are submitted? Where does the data go? We have a discussion about this currently. You can give an external url to your form: form action=http://www.piwiframework.de/somescript.php; method=post This is useful if you want to include some google boxes in your static site. If one does static content generation, we assume he doesn't need any dynamic features. Nothing happens. I mean, if you have PHP installed on your webserver, why should you use static content generation? If you need that, you may not need forms at all. This would be requirements creep for Forrest. We are a content framework not a web framework. Given that the goal of Forrest is to provide many output formats from many input formats (and according to the PIWI website this goal is shared) then I am struggling with the above affirmation. Either you don't need to support forms, or you need to support them in a way that is compatible with the goal of the project, i.e. give the best possible rendering of a page given the constraints of the output format. - Authentification Again, how do you justify this alongside static generation? This cannot work with static generation. Exactly, see my comments above. I feel that either the PIWI objectives are poorly stated on your website or you have a sever case of requirements creep on your hands. Don't get me wrong, I'm not trying to be difficult. I'm genuinely trying to understand the objectives of Piwi and why you believe they align nicely with Forrest. Suffice it to say, it looks like you've done great job with Piwi. First, thank you for your interest and your very helpful comments. I think I should learn more about the differences from Cocoon to Forrest. I always thought that Cocoon is a XML transformation framework (not a web framework, even if it can used in the web enviroment) and Forrest is one too, but with more specialized functions for publishing on XML basis. Reduce the complexity of Cocoon and publish your content, this is Forrest. Historically Cocoon was an XML publishing framework. Over the years it migrated into being a web framework as requirements like forms processing and authentication crept in (I carefully chose those examples for obvious reasons, but I could have provided so many more such examples). Forrest was created around the time it was clear Cocoon was more than an XML publishing framework, Forrest came along to satisfy a specific need of XML publishing (many formats in, many formats out) and stripped out most of the dynamic web framework stuff that had crept into Cocoon. Forrest was originally targeted at creating web sites and documentation for ASF projects. Over the years it has grown into more genera publishing jobs. In other words, you are right about Forrest, but Cocoon is most definitely a web framework. I consider PIWI as a xml transformation framework, which can be used in the web too. I thought it fits to Forrest cause we simply looked at the Forrest functionality and copied them over as good as it was possible in PHP. For us the concept (and its interfaces) is more important than the web features. We added those since PHP is usually a web language. Given the history of Forrest I doubt we would be interested in a project that brings back the requirements creep that resulted in the creation of Forrest in the first place. However, the idea of simplifying Forrest and making it more accessible to users is of interest to a number of Forrest devs. However, as I said in my original mail. Most of us have a great deal invested in Forrest as it is currently designed. To get traction here I expect you will need to: a) decide what the scope of PIWI is and, if necessary address the requirements creep issue b) allow Forrest plugins to be reused without modification (a script for conversion might work) Even then I'm not saying you will get traction, I'm only saying I doubt you will get traction without that. I see some synergies in PIWI and Forrest. For example, I always wanted to use Forrest but had no java host ready. But this shows the misunderstanding you have of Forrest. The idea is that you host static content, not dynamic content. If you need dynamic content you need a web framework not a publishing tool. To host static content you don't need Java (or PHP) I also remember the Forrest2 approach before a while. In fact
Re: Piwi - Forrest in PHP
On 22 Dec 2008, at 16:50, Christian Grobmeier wrote: Sure, and your work has gone further than my Forrest 2 experiments did. However, it has diverged from the goals of Forrest and is therefore, in its current form, a very different project. Totally true. Sadly - I really was excited about bringing some benefit to forrest. Instead of that, I should better visit Cocoons mailinglist. Before you do I would recommend you check out the work on Cocoon 3 - this is addressing many of the complexity issues. I doubt very much that Cocoon would be interested in Piwi for the opposite reason that I think Forrest is not interested. As a web framework Piwi offers far less features than Cocoon and the issue of requiring Java is not relevant for the Cocoon community. Furthrmore there are existing PHP frameworks for those who don't want java. Still, I don't speak for the whole community only as an individual. However, I learned much and would like to thank you for your explainations. I will not bother this list again with my ideas of contributing PIWI as a sub project of Apache Forrest - I may find a Champion in a more appropriate project :-) Indeed you may and I thank you for working with us on understanding the issues here. I'm glad I took the time to do so, I now know what Piwi is and, if it should find a champion and enter the incubator, as you seem to desire, then I will know which way to vote as an Incubator PMC member. Ross
Re: Outdated docs?
On 21 Dec 2008, at 15:38, Ferdinand Soethe wrote: I can't find the config file mentioned below. What is the new location of this file? Using Cocoon sitemap execution logger In main/webapp/WEB-INF/xconf/forrest-core.xconf search for sitemap execution and uncomment the component. For each sitemap component that is executed, a message will go to WEB-INF/logs/debug.log Extract from http://forrest.apache.org/docs_0_80/howto/howto-dev.html#debug-cocoon-profiler It looks like the move to Cocoon 2.1 lost this style of configuration. The file is now http://svn.apache.org/repos/asf/forrest/trunk/main/webapp/WEB-INF/cocoon.xconf I found this using grep - grep is your friend. Ross
Re: Piwi - Forrest in PHP
On 20 Dec 2008, at 02:13, David Crossley wrote: I don't understand what this has to do with Forrest, other than it was inspired by Forrest. Why are we talking about the design of Piwi on this list? Better on the Piwi mail list. Because the developers seem to think it is appropriate to the Forrest project. Just because we don't see why at first glance doesn't mean it isn't relevant. We have enough trouble getting people to develop Forrest, let alone develop someone else's product. The problems with Forrest, as I see them, were clearly laid out a very long time ago. Piwi is addressing the same problems (overly complex, hard to host, impossible to embed, hard to understand). -- Note for the mail archives: Regarding PHP in Forrest, see the following FAQs: How to use a different filename extension for output, e.g. *.php? http://forrest.apache.org/faq.html#output-filename-extension How to generate pages ready for serving via PHP? http://forrest.apache.org/faq.html#php Neither of those FAQs having anything to do with the motivations of Piwi. Ross
Re: Piwi - Forrest in PHP
On 18 Dec 2008, at 15:27, Christian Grobmeier wrote: Hi all, I sent an E-Mail before a while about the PIWI project. Meanwhile a lots of improvements have been done and I would like to point you to the project again. PIWI is a transformation framework written in PHP. It uses lots of ideas and concepts from Cocoon and esspecially Forrest. Its current project site can be found here: Project: http://code.google.com/p/piwi/ Docs and Demo: http://www.piwiframework.de/ Its completly implemented under the Apache License. Current features are: - Crawler for static content generation - Forms (easy create web forms and assistants) Form Validation How do you justify the decision to implement forms support *and* static generation. We've always been of the opinion that they are mutually exclusive. Forrest does support forms, but not out of the box. What happens when forms are submitted? Where does the data go? I did look at the site and found a demo, but no explanation of what is actually happening. What validation mechanism do you use? that is how do you define validation rules? - Internal PIWI-Format has been changed to a subset of XHTML Cool - that was the big problem with your previous implementation (for me at least). A move to XHTML means that the XSL in our existing plugins can be more easily reused. - Generators and Connectors (Generate XML from within other XML-Structures; Connect a Generator to Databases) I'm a little confused by your choice of names here. Looking at the demo the generator page displays data formatted in a particular way (i.e. a data table), there is no indication of what is actually happening. Is a generator the same as what we call a generator (something that creates XML for further processing, or is it a serializer (something that generates an output). - Authentification Again, how do you justify this alongside static generation? You can see most features in action at http://www.piwiframework.de/. Several things have to be done, but at the moment we consider the project as feature complete. We plan to wait a while and fix occuring bugs or feature requests and then walk towards a version 1.0. We also would like to write some more user docs. It would be great to get some feedback of you guys. I think PIWI would perfectly fit to the Forrest project and we might be interested in this. I strongly believe that Apache needs a web framework in PHP. If you guys think so, let us know. Any help or ideas here are highly appreciated. I'm really not sure. Forrest is *not* a web framework, it is an XML publishing framework. Cocoon is a web framework. I'm confused by what Piwi is. Is it a web framework or a publishing framework. If it is a web framework what does it give over the many other web frameworks out there and why would Forrest (a publishing framework) be interested? If it is a publishing framework then why does it have some web framework features? Don't get me wrong, I'm not trying to be difficult. I'm genuinely trying to understand the objectives of Piwi and why you believe they align nicely with Forrest. Suffice it to say, it looks like you've done great job with Piwi. Ross Ross
Re: [jira] Commented: (FOR-1108) Dispatcher, Cocoon 2.1 and Windows
On 2 Dec 2008, at 11:52, Gavin wrote: -Original Message- From: Thorsten Scherler [mailto:[EMAIL PROTECTED] ] Sent: Tuesday, 2 December 2008 9:43 PM To: dev@forrest.apache.org Subject: RE: [jira] Commented: (FOR-1108) Dispatcher, Cocoon 2.1 and Windows El lun, 01-12-2008 a las 12:04 +1000, Gavin escribió: ... I checked the PDF plugin again as this was never broken on Windows and found that the exact same fix we recently found we needed to do to other plugins was already present in the PDF plugin. Thorsten committed this change back in February 18th [1] with the log message of 'making resources usable from other plugins' . ... [1] - http://svn.apache.org/viewvc/forrest/trunk/plugins/org.apache.forrest.plug in .output.pdf/locationmap.xml?r1=628558r2=628586diff_format=h Yeah, actually if we want to reuse resources from other plugins the relative path does not work in the lm for plugins. The solution to add as fallback the absolute location will work for all plugin as I understand it and brings the benefit of usability of the resources. ... However, if the above fix is useful in general for making reusable resources available by default then it doesn't feel so bad. Combine that with talk of future and markably different direction(s) for Forrest as a whole then it might just be acceptable. +1 Thorsten and I talked about the solution for reusing resources some time ago. The result was his commit you refer to. A side effect that fixes a weird bug on a single platform is a plus. It is well documented thanks to your work and the discussion here and on the JIRA issue. I'd just make the patch and be done with it. If it bites us in the ass in the future we can revisit. Ross
[jira] Updated: (FOR-1133) PDF don't display images in deployed WAR file on Tomcat
[ https://issues.apache.org/jira/browse/FOR-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ross Gardler updated FOR-1133: -- Priority: Major (was: Critical) Urgency: Normal (was: Urgent) This is an issue with a version of Forrest that has been in production for quite some time. The problem would therefore appear to be with the specific configuration. Can you please report what happens when you do forrest run and retrieve a PDF, can you also tell us what the fo:external-graphic is when doing forrest run. Testing a built war file in a diferent servlet engine (e.g. Jettry) would also be informative. Please also test using 0.9-dev so that we can ascertain if this is a problem with 0.8 only or also a problem with SVN head. On my configuration I am unabe to reproduce this problem, so the more information you can provide us the more likely we are to be able to help you fix the problem. I'm reducing the priority to major as this issue needs to be confirmed as a problem in Forrest rather than a problem in your configuration (although I note you have tested on multiple operating systems). I'm also reducing the urgency to Normal, this means active devs are likely to help you solve the problem, but that they are not likely to do the work for you (i.e. an existing dev is not being affected by the issue) PDF don't display images in deployed WAR file on Tomcat --- Key: FOR-1133 URL: https://issues.apache.org/jira/browse/FOR-1133 Project: Forrest Issue Type: Bug Components: Plugin: output.pdf Affects Versions: 0.8 Reporter: Antoine ROBERT Hi, In order to make this discussion as an official issue (http://www.nabble.com/PDF-not-working-correctly-in-deployed-WAR-file-on-Tomcat-td15295911.html) i post a JIRA. Bug information : Tools : apache-tomcat-6.0.18 + apache-forrest-0.8 + java-1.6 OS : Windows XP and CentOs (a RedHat) Step to reproduce 1/ Download apache-forrest-0.8 (Actual release) 2/ Downlaod apache-tomcat-6-0.18 (Actual release) 3/ Use java 1.6 (Actual release) 4/ forrest seed (To create sample forrest site) 5/ forrest war (to create WAR sample forrest site) 6/ put the .war in the tomcat webapps folder 7/ Launch sample forrest application from tomcat 8/ Go to any page with any image of this war sample forrest site 9/ Try to see it in PDF version 10/ See that you don't have image displayed The issue is that, images are not displayed .. Any image (gif, png, jpg). This issue is only in case of a deployed WAR, that works fine in jetty. Here are some clues about the issue : When i take a look in the graphical section of the .fo file I can see that : fo:external-graphic src=context:///project/src/documentation/content/xdocs/mySpecificProject/conception/specificModule/fonctionnal/../resource/anImage.jpg And when I take a look in my WEB-INF/logs/core.log i can see that : http-8080-1/ExternalGraphic: Error while creating area : Error with image URL: context:/project/src/documentation/content/xdocs/mySpecificProject/conception/specificModule/fonctionnal/../resource/anImage.jpg (No such file or directory) and no base URL is specified I think that is a serious issue, and I would like your opinion about it. Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (FOR-1108) Dispatcher, Cocoon 2.1 and Windows
On 30 Nov 2008, at 10:35, Gavin wrote:
-Original Message-
From: Gavin (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Sunday, 30 November 2008 8:22 PM
To: dev@forrest.apache.org
Subject: [jira] Commented: (FOR-1108) Dispatcher, Cocoon 2.1 and
Windows
[ https://issues.apache.org/jira/browse/FOR-
1108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanelfocusedCommentId=12651805#action_12651805 ]
Gavin commented on FOR-1108:
Well, I got the .Text and .POD plugins working fine on Windows too,
and I
expect if I make the same changes throughout the rest will too. I
will
test on a couple of whiteboard plugins next.
Previously - with a seed-sample and no dispatcher, only the PDF
plugin
worked, with the changes below then the above two also work now.
locator
match pattern=text.transform.*.*
select
location src=resources/stylesheets/{1}-to-
{2}.xsl /
location
src={forrest:forrest.plugins}/
org.apache.forrest.plugin.output.Text/resou
rces/stylesheets/{1}-to-{2}.xsl/
/select
/match
/locator
So, all I did there then was add in a second match using the more
full path
to the plugins stylesheet(s) and so then it worked fine.
This is a workaround, one that we could extend and test to all
plugins and
if works fine can get Windows devs back to working on trunk.
Getting windows up and running is the primary goal - well done!
Or, we need to find the real cause and fix it there, may only be a
few lines
of one file rather than altering every single plugin.
We do need to figure out the real cause of the problem though. It used
to work and now it doesn't - who knows what hidden surprises there are
because of this.
However, since I wasn't finding the time to fix the windows problem
myself I'm not about to start demanding you fix this. However, it's
worth adding a fixme referring to the original issue when adding the
workaround.
As a windows user, I'll help with what I can, but I doubt 'll be
actively working on this (my main machines are all Linux).
Ross
Re: [RT] Requirements for Spring-based Forrest (forrest2)
On 29 Nov 2008, at 00:56, Brian M Dube wrote: I'd like to spend some time on a proof of concept version of Forrest without Cocoon, whether that's whiteboard/forrest2 or a new approach. One of the requirements, or at least functional tests, that has already been mentioned with respect to forrest2 is that the seed site must function correctly. I think this implies that current style plugins need to be supported. That really depends on your use case. The majority of work in the plugins is the XSLT, so reuse of part of the plugins would probably be acceptable. However, those plugins are based on XDoc and we have been intending to go to XHTML2 for a very long time and Forrest2 would be the sensible time to do that. So, I'd say there is no need for it to be compatible with existing plugins. I would say that it should be compatible with the important part of Forrest. That is, existing sites should work without modification - or a tool be provided for conversion. To support current plugins requires sitemap and locationmap implementations that don't depend on Cocoon. My original motivation for the Forrest2 experiments was to remove the complexity of the sitemap (an expressive language for web apps, not applicable to a publishing framework) and further enhance the ideas in the locationmap (decoupling of source and target data). For me Forrest 2 should not be constrained by Forrest 1. It looks difficult, but not impossible, to extract sitemap support from the Cocoon source. Is this the way to go? Not for what I did with Forrest2 in whiteboard. I can't answer for your own use case. Speaking personally, if your work went the sitemap route I would probably not be engaged by it. That's not to say it is a bad idea - just that if it doesn't solve the configuration complexities of the current system I'm not sure what utility it would have for me. However, have you looked at the Cocoon 3 work? From what (little) I know of this it is a simplified Cocoon. Implement support for sites and plugins as they exist now, and use a new format for new development? See above. What are the other requirements to move away from Cocoon? My motivations can be found in the archives, e.g. http://markmail.org/message/dxy3qrsw4jyw26rd Is there community interest to move away from Cocoon? My Forrest2 proposal was never about moving away from Cocoon. It was about removing the need for a monolithic web framework for creating an XML publishing framework. My Forrest 2 design was all about allowing people who need to leverage Cocoon (or any other framework) in a Forrest content object - but not forcing them to do so. Do I still think this is a good idea? Yes I do - see my RT thread linked above. Will I work on it. Quite possibly. I don't find the time to work with Forrest these days - it doesn't match my needs anymore, but I still need an XML publishing framework that is something like Forrest (but allows more flexibility). There is, to my knowledge, no suitable alternative. Ross Ross
Re: Forrest friendly searching
Tim Williams wrote: I've been playing around with Google's Custom Search and thought I'd use Forrest as my playground since I have a good idea of what I think good results are. Anyway, I haven't added a whole lot of customization or refinements to it but think it's already fairly useful nonetheless. http://www.google.com/coop/cse?cx=014207783617196158741:fgpzn29ywzq e.g. http://www.google.com/cse?cx=014207783617196158741%3Afgpzn29ywzqq=dispatcher Let me know what you think and let me know if you want to contribute... btw, i just picked a reasonable name, if it violates some rule, let me know... Quite the contrary. As long as you are prepared to give committers who ask for it the ability to work on the resources then I'd propose that this become the default search facility on our site. Ross
Re: input.wordpress (was Re: potential new plugin)
Brian M Dube wrote: On Wed, Aug 13, 2008 at 04:03:27PM +1000, David Crossley wrote: The dependencies on the main facilities (e.g. WordPress and MySql) seem okay to me. I expect that they would be treated as system requirements, i.e. there is no use for the plugin if there is no server available to connect to and extract content from. (Snip) Some of them (e.g. ehcache) are already in forrest core lib but need to to updated. If Forrest followed our usual technique of re-distributing the supporting jars as a convenience, then definitely there are some in that list that cannot be re-distributed: e.g. hibernate - See 150 hits for that word on legal-discuss@ especially LEGAL-7 (and its linked issues) and the responses to that and to LEGAL-9. e.g. mysql-connector-java - I expect that there would be similar issues. Is there no suitably licensed alternative? I haven't found one. I don't have the energy to make the plugin work without Hibernate and the MySQL driver. I'm happy to make the code available elsewhere, but this is a blocker to host it here. Note I have not contacted legal-discuss. The time and energy for that is lacking, too. If there is no way of getting into Forrest I'll give you commit rights to the SF plugins project. Just let me have your SF username (when I set this up we said any Forrest committer could have committ access over their simply by asking). However, be aware that it is not an active community in its own right. It's merely a place to put stuff the ASF cannot distibute. We can (but at present do not) include plugins from there in the Forrest documentation (i.e. plugins.xml). Although to do this will require us to include a big this is not an approved ASF released plugin or something like that. Ross
Re: [forrest seed] problem with dispatcher
Cyriaque Dupoirieux wrote: Hi, I have not been working with my site for a long time, and now I cannot generate it again. The problem is with the recent change of Cocoon jars, head no longer works with Windows and it is waiting for a windows user to test and fgix the problem. I my self have sites failing on windows. However, I am currently off work on compassionate grounds and that includes much of my involvement with projects such as Forrest. I intend to fix it in the near future - but if it is critical to you then you need to debug. There is some starting info in the issue tracker at https://issues.apache.org/jira/browse/FOR-1108 Ross I have tried to generate a newly seeded site configured for the dispatcher and I get : cocoon 2.1.12-dev Copyright (c) 1999-2007 Apache Software Foundation. All rights reserved. X [0] linkmap.html BROKEN: D:\duc\forrest\main\webapp\.\D:\duc\ForrestSeed\build\tmp\D:\duc\forrest\build\plugins \dataModel.xmap (Syntaxe du nom de fichier, de rÚpertoire ou de volume incorrecte) Total time: 0 minutes 2 seconds, Site size: 0 Site pages: 0 Java Result: 1 Copying broken links file to site root. Copying 1 file to D:\duc\ForrestSeed\build\site BUILD FAILED D:\duc\forrest\main\targets\site.xml:183: Error building site. Do I have to try the new Dispatcher branch or is there something I haven't understood ? Thank you,
Re: input.wordpress (was Re: potential new plugin)
David Crossley wrote: Ross Gardler wrote: Brian M Dube wrote: David Crossley wrote: The dependencies on the main facilities (e.g. WordPress and MySql) seem okay to me. I expect that they would be treated as system requirements, i.e. there is no use for the plugin if there is no server available to connect to and extract content from. (Snip) Some of them (e.g. ehcache) are already in forrest core lib but need to to updated. If Forrest followed our usual technique of re-distributing the supporting jars as a convenience, then definitely there are some in that list that cannot be re-distributed: e.g. hibernate - See 150 hits for that word on legal-discuss@ especially LEGAL-7 (and its linked issues) and the responses to that and to LEGAL-9. e.g. mysql-connector-java - I expect that there would be similar issues. Is there no suitably licensed alternative? I haven't found one. I don't have the energy to make the plugin work without Hibernate and the MySQL driver. I'm happy to make the code available elsewhere, but this is a blocker to host it here. Note I have not contacted legal-discuss. The time and energy for that is lacking, too. If there is no way of getting into Forrest ... We don't know that yet. Brian is not the only person in this community. It is a pity that no-one can make the effort to follow up on such legal aspects. Peronslly I don't need to follow up. There is GPL code - that's the end of the story for the ASF. I too have looked for alternatives in the past - they don't (to my knowedge exist) and I've wasted much time on this in the past. I'm offering a solution. If others want to follow up on the legal front fine - for me it is a dead end so lets get the code where it can be used. Ross
Re: input.wordpress (was Re: potential new plugin)
David Crossley wrote: David Crossley wrote: Ross Gardler wrote: David Crossley wrote: Ross Gardler wrote: Brian M Dube wrote: David Crossley wrote: The dependencies on the main facilities (e.g. WordPress and MySql) seem okay to me. I expect that they would be treated as system requirements, i.e. there is no use for the plugin if there is no server available to connect to and extract content from. (Snip) Some of them (e.g. ehcache) are already in forrest core lib but need to to updated. If Forrest followed our usual technique of re-distributing the supporting jars as a convenience, then definitely there are some in that list that cannot be re-distributed: e.g. hibernate - See 150 hits for that word on legal-discuss@ especially LEGAL-7 (and its linked issues) and the responses to that and to LEGAL-9. e.g. mysql-connector-java - I expect that there would be similar issues. Is there no suitably licensed alternative? I haven't found one. I don't have the energy to make the plugin work without Hibernate and the MySQL driver. I'm happy to make the code available elsewhere, but this is a blocker to host it here. Note I have not contacted legal-discuss. The time and energy for that is lacking, too. If there is no way of getting into Forrest ... We don't know that yet. Brian is not the only person in this community. It is a pity that no-one can make the effort to follow up on such legal aspects. Peronslly I don't need to follow up. There is GPL code - that's the end of the story for the ASF. I too have looked for alternatives in the past - they don't (to my knowedge exist) and I've wasted much time on this in the past. I'm offering a solution. If others want to follow up on the legal front fine - for me it is a dead end so lets get the code where it can be used. I am not referring to finding a replacement. I mean that our legal-discuss list is not a boogey monster. They want to treat everything on a case-by-case basis. No-one has yet even approached them on this matter. See Henri's answer in https://issues.apache.org/jira/browse/LEGAL-8 The way that i see it is that is it up to our PMC. It is an optional plugin. If it was the core of Forrest then things would be very different. Sure we cannot distribute those jars, but we can choose to say to the user: You need to download xxx.jar and add it to your lib directory. If that approach is acceptable to this PMC then so be it. Someone needs to clarify that with legal-discuss. As a PMC member I will support whatever those putting the effort into it want to do. What I care most about is getting the code out there uner clear legal terms. I respect the ASF hard line on licence compatailbity as it results in considerable cost saving for thos doing procurement (i.e. we can trust the ASF). I don't like the idea of shipping code that does not work the way everything else does (i.e. add the plugin to forrest.properties and then download these jars). It breaks the way Forrest is supposed to learn. By distributing from a place where we explicitly have a more relaxed attitude to the GPL compatability argument and by highlighting this to users we allow people to decide on the risk for themselves (if they do not intend to redistribute there is no risk in any case). I said I'm prepared to support whatever those doing the work want to do - I set up an SF account for this purpose and I will do what is necessary to allow this code to reach that distribution point if that is what those doing the work want. I don't think it is helpful to push in one direction or another and ask for others to do the work to move in that direction. Ross
Re: Xdoc documentation
Carlos Tejo Alonso wrote: Hello, I was reading about the intermediate language xdoc and I found that there is no difference between all this web pages: * document-v20 http://forrest.apache.org/dtdx/document-v20.dtdx.html * howto-v20 http://forrest.apache.org/dtdx/howto-v20.dtdx.html * faq-v20 http://forrest.apache.org/dtdx/faq-v20.dtdx.html Would be like that or there is something wrong? If it is ok, what's the reason to have the same content 3 times with different names? Look again. They are all different. It's true that the how to and faq documents use most of the otehr dtd but they are different. Look at the top level elements for a start. Ross
Re: Use of 3rd party template
Gavin wrote: Hi, I have an OSSWatch ODT file to be used as a template to use for our OOo output plugin. Can I get appropriate permissions to use the contents of this file ? Yes, Consider this email my permission to contribute it to the example site under the Apache Licence V2. Ross
Re: [jira] Commented: (FOR-1068) plugins need to be managed via the ASF mirror system
David Crossley (JIRA) wrote: [ https://issues.apache.org/jira/browse/FOR-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12634547#action_12634547 ] David Crossley commented on FOR-1068: - I have made some local progress on this issue. I have a demonstration Ant build that finds the nearest mirror (list of preferred mirrors) try each until it gets the artefact, then get its signature and checksum from the main dist area. Kudos to David! Ross
[jira] Closed: (FOR-1114) Reference section in tei output can show each item several times
[ https://issues.apache.org/jira/browse/FOR-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ross Gardler closed FOR-1114. - Resolution: Fixed Assignee: Ross Gardler Applied with thanks Reference section in tei output can show each item several times Key: FOR-1114 URL: https://issues.apache.org/jira/browse/FOR-1114 Project: Forrest Issue Type: Improvement Components: Plugin: output.tei Reporter: Pablo Barrera Assignee: Ross Gardler Attachments: 0001-Show-each-item-only-once-in-the-references-section-o.patch xsl:sort does not filter the results to have uniq results, so if you have a link twice in the document it will appear twice in the references. This patch uses a key to show each link just once. More information at http://www.dpawson.co.uk/xsl/sect2/N6461.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Conditional locations and i18n
Sjur Moshagen wrote: Den 23. sep. 2008 kl. 18.58 skrev Ross Gardler: ... A long time ago I looked at using the locationmap to handle internationalisation. It never happened because I had no use case for it and it seems the current i18n solution was sufficient. I wonder if this is the first use case we have where it is not sufficient. What would be the benefit compared to the i18n matcher already available in Cocoon (and thus Forrest)? If the remote server understands i18n requests then there is no benefit. In other words, if we want the source to be http://foo.org/bar.xml and the remote serve honours the language preferences of the client all is well. However, in this use case the remote server does not honour the clients i18n settings and the request breaks. If i18n were handled in the locationmap the developer of the content object could override default i18n behaviour when needed, such as in this wiki instance. BUT... I've not fully thought this through. I don't have any i18n sites and I'm not fully up to speed with i18n content negotiation. In other words, my argument could well be full of holes and I'm not about to start experimenting with it. So, feel free to implement something that works for your use case and retains backward compatability (as discussed) if you don't want to explore this random thought. Ross
[jira] Closed: (FOR-1113) New section in tei output with all the references in the document
[ https://issues.apache.org/jira/browse/FOR-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ross Gardler closed FOR-1113. - Resolution: Fixed Fix Version/s: 0.9-dev Assignee: Ross Gardler Applied with thanks. New section in tei output with all the references in the document - Key: FOR-1113 URL: https://issues.apache.org/jira/browse/FOR-1113 Project: Forrest Issue Type: Improvement Components: Plugin: output.tei Reporter: Pablo Barrera Assignee: Ross Gardler Fix For: 0.9-dev Attachments: 0002-tei-references.patch, 0003-tei-docs.patch As commented in the mailing list, I have modified the XSL for the TEI output to include a section at the end with all the links (references) in the document. This section is optional and is controlled using a property included in the forrest.properties.xml file. The patch depends on patch I submitted for the bug # https://issues.apache.org/jira/browse/FOR- - https://issues.apache.org/jira/secure/attachment/12390728/0001-tei-properties.patch as this patch modify the output.xmap file for the plugin. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FOR-1111) publicationStmt info in document-to-teiLite.xsl contains incorrect defaults
[ https://issues.apache.org/jira/browse/FOR-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ross Gardler closed FOR-. - Resolution: Fixed Fix Version/s: 0.9-dev Applied with thanks. publicationStmt info in document-to-teiLite.xsl contains incorrect defaults --- Key: FOR- URL: https://issues.apache.org/jira/browse/FOR- Project: Forrest Issue Type: Bug Components: Plugin: output.tei Reporter: Pablo Barrera Assignee: Ross Gardler Fix For: 0.9-dev Attachments: 0001-tei-properties.patch Right now the xsl file at whiteboard/plugins/org.apache.forrest.plugin.output.tei/resources/stylesheets/document-to-teiLite.xsl contains this information: publicationStmt publisherOSS Watch, Oxford University/publisher authorityOSS Watch/authority address email[EMAIL PROTECTED]/email /address availability licence http://creativecommons.org/licenses/by-sa/2.0/uk/ /licence /availability datexsl:value-of select=datetime:date()//date /publicationStmt The reference to a particular organization should be removed. Otherwise all the documents generated with this plugin will show Oxford University as publisher (and there is some change they are not). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Using dispatcher contracts with a not html output
Thorsten Scherler wrote: On Mon, 2008-09-22 at 08:52 +0100, Pablo Barrera wrote: ... I will try to get the dispatcher working looking to the files you suggested. I personally have never worked with tei and I am not sure whether the dispatcher makes sense for tei. Maybe Ross can comment on this. TEI is just an XML format. However, it's a very, very old XML format (its roots are actually in SGML). Consequently, people expect to use it in extremely varied ways. I'd say the dispatcher is ideal as it allows content to be moved from one place to another within the TEI document in order to accommodate for strange requirements placed on the system by downstream XSL. Having said that, coding it directly in the TEI plugin is quicker and easier and could always be factored out into the dispatcher if it actually needs to be. Ross
Re: Using forrest.properties.xml inside a xsl
Pablo Barrera wrote: Hello I was completely unable to have a copy of the plugin working in my site directory, as I commented in other mail. So, I have decided to fix all the problems I am having with the tei plugin now instead of later. I have added this template to document-to-teiLite.xsl of the plugin: xsl:template name=references div headReferences/head ul xsl:for-each select=//link xsl:sort select =./ li a xsl:attribute name=href xsl:value-of select=@href/ /xsl:attribute xsl:value-of select=./ /a /li /xsl:for-each /ul /div /xsl:template However this should not be execute for all tei outputs, as not everybody is interested in this particular section. I have included this into the xsl: xsl:template match=body text body xsl:apply-templates / xsl:choose xsl:when test=$reference-section = 'true' xsl:call-template name=references/ /xsl:when /xsl:choose /body /text /xsl:template but I need to control the variable reference-section. How do I read variables from the forrest.properties.xml file? I have tried to look for $properties//[EMAIL PROTECTED]'tei.reference-setion']/@value with no results (properties is defined as xsl:variable name=properties select=//prop:properties /). The property tei.reference-section is listed in http://localhost:/index.props. Should I config the plugin to read the properties.xml file or it is done automatically? I have looking to the pdf out plugin to learn a little bit more about this but I had little luck. This needs documenting, but you can find an answer 9with pointers to examples) in See http://markmail.org/message/3dwdpp3dwzim7u5l (in particular the last set of comments That'll hopefully give you a starter If you get stuck again, just yell. Ross
Rename ODT example site
Gavin has committed an ODT example site which is nothing more than a simple sample at this time - it includes a TEI sample. Pablo is working on a wiki to TEI converter. I'm planning on creating an example that demonstrates quite a few of the integration features of Forrest using Resume, TEI, wiki, DOAP, mySQL, RT and a few other sources (eventually). I wonder if we should do these all in the same example. You may recall, my original motivation for doing this was that we will be doing some development work on this internally (the wiki-TEI and TEI-HTML stuff Pablo is working on is part of this). My proposal was that we do this work in Forrest itself in order to demonstrate the functionality and felxibility of Forrest. The ODT stuff looks like it could be useful to use as well. Shall I rename the ODT sample to something more generic so that it can grow to include samples from our work? I'm not sure what name to give it, perhaps: contentIntegration Ross
[jira] Closed: (FOR-1112) Incorrect example with local plugin dirs in Extending Forrest with Plugins
[
https://issues.apache.org/jira/browse/FOR-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ross Gardler closed FOR-1112.
-
Resolution: Invalid
Assignee: Ross Gardler
The text you quote is an example only. The local plugins can be placed anywhere
you like and the directory added to the property should be the one chosen.
I've updated the docs to make this clear.
Incorrect example with local plugin dirs in Extending Forrest with Plugins
Key: FOR-1112
URL: https://issues.apache.org/jira/browse/FOR-1112
Project: Forrest
Issue Type: Bug
Components: Documentation and website
Reporter: Pablo Barrera
Assignee: Ross Gardler
Attachments:
0001-Add-project.dir-to-example-code-otherwise-the-text.patch
In this page
http://forrest.apache.org/pluginDocs/plugins_0_90/usingPlugins.html
it is said:
For example,
project.required.plugins.src=${forrest.home}/plugins,${forrest.home}/whiteboard/plugins,/export/forrest_plugins
will add the project specific directory ${project.home}/plugins to the list
of directories to search in.
but I think the correct one is:
For example,
project.required.plugins.src=${project.home}/plugins,${forrest.home}/plugins,${forrest.home}/whiteboard/plugins
will add the project specific directory ${project.home}/plugins to the list
of directories to search in.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FOR-1106) Dispatcher quickstart documentation hard to follow
[
https://issues.apache.org/jira/browse/FOR-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12632830#action_12632830
]
Ross Gardler commented on FOR-1106:
---
Applied patches 4, 5 and 6 - thanks for your contribution.
Patch 4 was invalid XML and needed changes as a result (please validate all XML
before submitting a patch, if you don't use a valiating editor then you can fo
forrest validate from the command line)
Patch 5 had lines that were very long, please stick to a maximum column count
of 80 characters. This makes it easier to read in many editors and SVN commit
mails. It also ensures that changes to a single word do not cause a whole
paragrah to appear in the diffs, thus making it easier to read diffs (as
illustrated by patch 6 in fact)
Dispatcher quickstart documentation hard to follow
--
Key: FOR-1106
URL: https://issues.apache.org/jira/browse/FOR-1106
Project: Forrest
Issue Type: Bug
Components: Documentation and website, Plugin: internal.dispatcher
Reporter: Pablo Barrera
Attachments:
0002-Added-pelt-html.header.panel.xml-to-dispatcher-docum.patch,
0003-Change-theme-and-added-notes-to-dispatcher-quickguid.patch,
0003-Update-forrest-bar-reference.patch,
0004-Added-cache-warning-to-dispatcher-quickstart-guide.patch,
0005-Added-Decide-how-to-manage-your-contracts-using-Ro.patch,
0006-Change-directory-folder-to-directory.-Change-also.patch
I am trying to use the dispatcher again. I have looking in the documentation
and I was only able to find this quickstart guide:
http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.internal.dispatcher/how/howto-dispatcher-quickstart.html
I was looking for something in plugins_0_90-dev but all links pointed to 0_80.
I think this guide is hard to follow. For example, if you follow it directly
you reach this point:
Use another theme
* Add property name=dispatcher.theme value=common/ to your
forrest.properties.xml
* Re-start 'forrest run'
* localhost:/index.html ... See the new view.
But in the rest of the document the pelt theme is used. For example, the line:
# Copy THEMER_PLUGIN/themes/pelt.fv into your project at
${themer.project.dir}/pelt.fv
will be of no use if the user has changed the theme to the common one.
Forrest will ignore these changes.
After that, in the section Create our own structurer by copy-and-customise
there are several problems. It's not straight forward to know where the
THEMER_PLUGIN is. A note with the default localisation will help.
The file used in this example is pelt/panels/pelt-html.panel.xml, but
according to my logs locationmap is not looking for that file at all. Maybe
the example is outdated. Changing the file to other one could be enough.
It can be also interesting mention that the url
http://localhost:/resolve.structurer.index
shows you the structurer in use. Any change to your pelt.fv file will be
shown here.
The patch adds some comments about this problems but does not provide an
alternative file in for pelt/panels/pelt-html.panel.xml
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Seed site, whiteboard or example?
Gavin wrote: -Original Message- From: David Crossley [mailto:[EMAIL PROTECTED] Sent: Saturday, 6 September 2008 11:58 AM To: dev@forrest.apache.org Subject: Re: Seed site, whiteboard or example? Gavin wrote: From: David Crossley Ross Gardler wrote: Thinking ahead to release time, how would we handle the examples? Our release is big enough as it is, including complete example sites would really add to the size. However, examples aren't really useful unless they are downloaded for folks to look at/play with. They should be as minimal as possible, mostly being configuration. The actual functionality is documented in each plugin's own documentation, so no need to repeat that. Sure we will need minimal working examples in the content. I've done seed site, enabled for tei input and odt output and pelt theme dispatcher enabled. Theres not much there yet, a tei version of document-v20 and minimal docs, with odt output link icon on each page. This can be built upon - and is a current work in progress, is this the sort of thing that can go into the examples section now or was the idea for something more? Yes it is an example, since I will be adding a wiki2tei example to the same site and we will probably add code to bring stuff in from Simal and SugarCRM and an yes undecided CMS system. I'm delaying my own work on this as I want to debug the windows problem with the Cocoon version change first. Ross
[jira] Commented: (FOR-1111) publicationStmt info in document-to-teiLite.xsl contains incorrect defaults
[ https://issues.apache.org/jira/browse/FOR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12631958#action_12631958 ] Ross Gardler commented on FOR-: --- Ooops, that was sloppy of me. It must have been a quick hack to make things work. This should either come from the source document, or it should be parameterised. Is it available in the source? publicationStmt info in document-to-teiLite.xsl contains incorrect defaults --- Key: FOR- URL: https://issues.apache.org/jira/browse/FOR- Project: Forrest Issue Type: Bug Components: Plugin: output.tei Reporter: Pablo Barrera Right now the xsl file at whiteboard/plugins/org.apache.forrest.plugin.output.tei/resources/stylesheets/document-to-teiLite.xsl contains this information: publicationStmt publisherOSS Watch, Oxford University/publisher authorityOSS Watch/authority address email[EMAIL PROTECTED]/email /address availability licence http://creativecommons.org/licenses/by-sa/2.0/uk/ /licence /availability datexsl:value-of select=datetime:date()//date /publicationStmt The reference to a particular organization should be removed. Otherwise all the documents generated with this plugin will show Oxford University as publisher (and there is some change they are not). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FOR-1111) publicationStmt info in document-to-teiLite.xsl contains incorrect defaults
[ https://issues.apache.org/jira/browse/FOR-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ross Gardler reassigned FOR-: - Assignee: Ross Gardler publicationStmt info in document-to-teiLite.xsl contains incorrect defaults --- Key: FOR- URL: https://issues.apache.org/jira/browse/FOR- Project: Forrest Issue Type: Bug Components: Plugin: output.tei Reporter: Pablo Barrera Assignee: Ross Gardler Right now the xsl file at whiteboard/plugins/org.apache.forrest.plugin.output.tei/resources/stylesheets/document-to-teiLite.xsl contains this information: publicationStmt publisherOSS Watch, Oxford University/publisher authorityOSS Watch/authority address email[EMAIL PROTECTED]/email /address availability licence http://creativecommons.org/licenses/by-sa/2.0/uk/ /licence /availability datexsl:value-of select=datetime:date()//date /publicationStmt The reference to a particular organization should be removed. Otherwise all the documents generated with this plugin will show Oxford University as publisher (and there is some change they are not). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Dispatcher cache deactivation not working
Pablo Barrera wrote: On 16/09/2008, at 13:14:34, Ross Gardler wrote: Pablo Barrera wrote: On 16/09/2008, at 12:21:09, Ross Gardler wrote: Thorsten Scherler wrote: On Tue, 2008-09-16 at 11:22 +0100, Pablo Barrera wrote: Hello I am trying to modify an structurer but every time I make a change I have to reboot forrest, otherwise I don't see the new changes. Looking around I have read I should turn off the cache adding: property name=dispatcher.caching value=off / I'm not sure what this is supposed to do in the disaptcher, but it does not turn off the locationmap cache because: DEBUG (2008-09-16) 12:05.07:961 [core.modules.mapper.lm] (/index.dispatcher.css): Locationmap cached location returned for hint: resolve.panels.pelt-html.content value: PATH-TO-PROJECT/src/documentation/resources//themes/pelt/panels/pelt-html.content.panel.xml Try the traditional approach to turning off the LM caching. In main/webapp/WEB-INF/xconf/cocoon.xconf change the cacheable element for the LocationMapModule to false. !-- LocationMap is used to map one URL to another, allowing content to be stored anywhere -- component-instance class=org.apache.forrest.locationmap.LocationMapModule logger=core.modules.mapper.lm name=lm file src=cocoon://locationmap.xml/ cacheablefalse/cacheable cache-lifespan10/cache-lifespan /component-instance This is main/webapp/WEB-INF/cocoon.xconf in FORREST_HOME, isn't it? I have change it to: !-- LocationMap is used to map one URL to another, allowing content to be stored anywhere -- component-instance class=org.apache.forrest.locationmap.LocationMapModule logger=core.modules.mapper.lm name=lm file src=cocoon://locationmap.xml/ cacheablefalse/cacheable cache-lifespan10/cache-lifespan /component-instance but same result. I have to reboot forrest to see the changes. Then I can't help any further this is an issue with the dispathcer only. LM caching works elsewhere (to the best of my knowledge0. Ross
[jira] Updated: (FOR-1108) Dispatcher, Cocoon 2.1 and Windows
[ https://issues.apache.org/jira/browse/FOR-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ross Gardler updated FOR-1108: -- Attachment: core.log testRunWithDebug.log Log level upped to Debug forrest run -v testRunWithDebug.log http://localhost:/index.html Attached testRunWithDebug.log and core.log Main problem: Caused by: java.io.FileNotFoundException: C:\projects\forrest\main\webapp\C:\tmp \forretTest\build\tmp\C:\projects\forrest\build\plugins\dataModel.xmap (The file name, directory name, or volume label syntax is incorrect) Not attempted to debug - time presses. Dispatcher, Cocoon 2.1 and Windows -- Key: FOR-1108 URL: https://issues.apache.org/jira/browse/FOR-1108 Project: Forrest Issue Type: Bug Components: Core operations, Plugin: internal.dispatcher Affects Versions: 0.9-dev Reporter: Ross Gardler Priority: Blocker Fix For: 0.9-dev Attachments: core.log, test.log, test_dispatcher_site.zip, testRunWithDebug.log Since the update to Cocoon 2.1 Forrest and Dispatcher have broken on windows. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [STATUS] [heads-up] merging our branch Cocoon-2.1
David Crossley wrote: Or any other Windows developer can answer really. I'm afraid I can't right now. SVN is down./ If it comes up within the hour I should be able to test. Ross
[jira] Created: (FOR-1108) Dispatcher, Cocoon 2.1 and Windows
Dispatcher, Cocoon 2.1 and Windows -- Key: FOR-1108 URL: https://issues.apache.org/jira/browse/FOR-1108 Project: Forrest Issue Type: Bug Components: Core operations Affects Versions: 0.9-dev Reporter: Ross Gardler Priority: Blocker Fix For: 0.9-dev Since the update to Cocoon 2.1 Forrest and Dispatcher have broken on windows. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FOR-1108) Dispatcher, Cocoon 2.1 and Windows
[ https://issues.apache.org/jira/browse/FOR-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ross Gardler updated FOR-1108: -- Attachment: test_dispatcher_site.zip test.log Results of running on windows + cygwin (but using forrest.bat, rather than forrest.sh) test.log is the console output for build.bat test test_dispatcher_site.zip is a zip of build/test_dispatcher_site I've not had the time to look at these and am unlikely to do so for at least a week as I'm travelleing a great deal next week. However, I shuld be able to rerun tests and the like, just ask. Dispatcher, Cocoon 2.1 and Windows -- Key: FOR-1108 URL: https://issues.apache.org/jira/browse/FOR-1108 Project: Forrest Issue Type: Bug Components: Core operations Affects Versions: 0.9-dev Reporter: Ross Gardler Priority: Blocker Fix For: 0.9-dev Attachments: test.log, test_dispatcher_site.zip Since the update to Cocoon 2.1 Forrest and Dispatcher have broken on windows. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [STATUS] [heads-up] merging our branch Cocoon-2.1
David Crossley wrote: Please provide the error.log ... If it is too big then create a Jira Issue. After doing: ]$ cd main ]$ build test https://issues.apache.org/jira/browse/FOR-1108
Re: svn commit: r691518 - /forrest/trunk/plugins/org.apache.forrest.plugin.input.wiki/input.xmap
[EMAIL PROTECTED] wrote: Author: sjur Date: Tue Sep 2 22:35:58 2008 New Revision: 691518 URL: http://svn.apache.org/viewvc?rev=691518view=rev Log: Added i18n matching to the source file lookup, thus allowing l10n of page content for wiki-format pages: somedoc.en.jspwiki somedoc.es.jspwiki etc can be used to serve localised content using the simple markup format of wikis. Also added some comments. We have used this setup for jspwiki for months at our site, so should work without problems. But it is not tested for the other wiki formats. -1 This causes problems when pulling content from a live wiki rather from a local server. I'm reverting this change until we find a workaround for this as it just broke about a dozen sites for me. I strongly suspect this was the problem Pablo was desribing on the user list as well in which he reported it worked with local files but not remote files. (NB Pablo is with our team for a few months so I'll try this with him tomorrow) Ross
Re: [STATUS] [heads-up] merging our branch Cocoon-2.1
David Crossley wrote: The new trunk using Cocoon-2.1 is working fine on these systems: Ubuntu - okay Mac OS X Tiger - okay Solaris10 - okay We have reports from one person with unknown troubles. Not sure what operating system (Windows?). Would other people test ASAP please. I can report that it *fails* on windows + cygwin at the dipatcher test. I'm currently building and deploying a production site and immediately reverted using the same command line shell so can't post the logs right now. Why do these things always occur at critical times? (that is not a complaint, merely an observation about life in an open source world, I am very grateful for the work David and Thorsten have done on this, I'm particularly grateful for Davids thoughtful post indicating which version I should revert to in order to get working, another observation about life in an open source world). I'll try and do a test again soon and send the log output. I'm afraid I'm unlikely to be able to debug it for at least a week though (although I will try) Ross
Re: Resolving relative locations in the locationmap
Thorsten Scherler wrote:
On Tue, 2008-09-09 at 23:26 +0100, Ross Gardler wrote:
...
So, my question is. How can I get the location of the locationmap file
itself for use in these relative matches?
Have you tried {properties:home}../../../subsiteA ?
IMO should work as I understand your mail.
AhHa - of course, that should work. Sometimes new eyes are what is
needed, I spent hours trying to find a way of getting it out of our Java
code last night.
This is the first time in years I broke my rule of if struggling for
more than 30 mins to figure it out, ask on the list - good to have it
reaffirmed occasionally.
Thanks Thorsten.
Ross
Re: Resolving relative locations in the locationmap
Thorsten Scherler wrote: On Wed, 2008-09-10 at 08:56 +0100, Ross Gardler wrote: ... This is the first time in years I broke my rule of if struggling for more than 30 mins to figure it out, ask on the list - good to have it reaffirmed occasionally. Yeah, lists are just great. How many times I solved my problem starting a mail and with reading what I wrote I actually found the solution (even without sending the mail). That's the other advantage of course. Must put that in our (OSS Watch) upcoming briefing doc on why to work with the community mailing lists. Ross
Re: Properties for contract (was Re: Dispatcher 1.0 - towards a stable version)
Thorsten Scherler wrote: On Fri, 2008-09-05 at 14:59 +0200, Thorsten Scherler wrote: ... The first solution is fast to implement and seems quite clean. The downside is that we cannot use xml anymore. Which actually IMO is not that bad since maybe we start to use the actual forrest.properties.xml to configure contracts. The second solution is more complicated to implement since the aggregation has to be done in the DispatcherTransformer which does not feel right but we could use xml in the properties. Personally the cleaner solution is 1 but that would break downward compatible by a couple of contracts. WDYT? I haven't thought long and hard about this. I'm going on your assessment and my gut reaction. I'd say go for option 1 because: a) I like that it brings more configuration into the new properties system b) you said it is easier to implement c) we currently have no use case for using XML in the properties d) if we find a use case for XML we can deal with it at that point (and maybe implement the second solution by adapting the properties system to allow XML) Ross
Re: i18n message catalogue in dispatcher and skins
Sjur Moshagen wrote:
Hello all,
I'm starting on the next step to make the pdf plugin fully i18n -
support for i18n text.
To that extent I have a couple of questions:
1.
In $FORREST_HOME/main/webapp/sitemap.xmap, the following lines are found:
map:transformer name=i18n
src=org.apache.cocoon.transformation.I18nTransformer
catalogues default=common
catalogue id=common name=CommonMessages
location={properties:skins-dir}common/translations/
/catalogues
cache-at-startuptrue/cache-at-startup
/map:transformer
Why is the path to the message catalogue soft-coded to the project
instead of using a LM?
Quite possibly missed when I did the move to LM. I probably did a search
for 'src=' which would have missed this.
I certainly didn't intentionally leave it out.
[I'll have to pass on questions 2 and 3]
Basic point for all these questions:
now we have copies of the same info all over the place, and most is not
used - I would like to remove all the unnecessary ones, and use LM in
all cases - and remove the messages from the seed. As part of that I
would like to update the user documentation for i18n as well, to make
sure it reflects the current state and how to set up proper i18n
support, as well as how to add new languages to the translation catalogue.
Yes please!
Ross
Re: Properties for contract (was Re: Dispatcher 1.0 - towards a stable version)
Thorsten Scherler wrote: On Wed, 2008-09-10 at 10:10 +0100, Ross Gardler wrote: Thorsten Scherler wrote: On Fri, 2008-09-05 at 14:59 +0200, Thorsten Scherler wrote: ... The first solution is fast to implement and seems quite clean. The downside is that we cannot use xml anymore. Which actually IMO is not that bad since maybe we start to use the actual forrest.properties.xml to configure contracts. The second solution is more complicated to implement since the aggregation has to be done in the DispatcherTransformer which does not feel right but we could use xml in the properties. Personally the cleaner solution is 1 but that would break downward compatible by a couple of contracts. WDYT? I haven't thought long and hard about this. I'm going on your assessment and my gut reaction. I'd say go for option 1 because: a) I like that it brings more configuration into the new properties system b) you said it is easier to implement c) we currently have no use case for using XML in the properties d) if we find a use case for XML we can deal with it at that point (and maybe implement the second solution by adapting the properties system to allow XML) To not break downward compatibility I will implement the option 1 but with a flag allowXmlProperties. I added the javadoc that setting this properties to true will be paid by performance but this let our current dispatcher user decide when to update their contracts and structurer. Perfect. Ross
Resolving relative locations in the locationmap
I've hit a problem with my work on multiple site integration in the whiteboard. I thought it was all going too well ;-) I've got a site that is made up of 1 master site and 3 sub sites. The process for doing this is documented in the sample in whiteboard. The primary trick is a locationmap that mounts the sub sites. In my worksite I've done this with relative paths and it worked great. That is, subsiteA is mounted from ../../../subsiteA. Unfortunately someone else has just tried to build this on their machine and it doesn't work. After some digging I discovered that the resolved location from the sitemap is relative to the Forrest install not the site being built. i.e. instead of /mysite/src/documentation/content/../../../../subsiteA... we get /forrest/src/documentation/content/../../../../subsiteA... On my machine this works because Forrest is at the same directory depth as my master site. On my colleagues machine this is not the case and so it fails. So, my question is. How can I get the location of the locationmap file itself for use in these relative matches? Ross
Re: Fresh seed build errors (PDF)
David Crossley wrote: On Sep 06, 2008 Brian M Dube wrote: On Jun 25, 2008 David Crossley wrote: Sorry, in my last message i intended to suggest the obvious. Have you set FORREST_HOME and PATH to point to the new fresh forrest installation? Also you might need to do a 'forrest clean' in any of your existing project workspaces. Oops, I intended to reply to this a long time ago. FORREST_HOME and PATH are correct, and I tried 'forrest clean' in each project. Again grasping at obvious things to be verified ... What about Java version? That should not matter. Just another straw to clutch at... I know some versions of Ubuntu has problems because the default Java VM is not compatible with Forrest. I can't recall what the error was, so not sure if this is related. Ross
Re: Dispatcher 1.0 - towards a stable version
David Crossley wrote: Thorsten Scherler wrote: My initial plan is to reuse the code from whiteboard/dispatcher, conduct the needed changes to work with java contracts and add spring support. Any thoughts. When we all talk about Dispatcher i thought that we were talking about the whiteboard/plugins/o.a.f.plugin.internal.dispatcher That is what i use and what the zone demos use. I missed that nuance. Thanks for picking it up David. All my comments were targtetted at getting the dispatch plugins into core. In particular, my one about lets finish one feature before starting the next. Ross
Re: Dispatcher 1.0 - towards a stable version
Thorsten Scherler wrote: Hi all, I will have some time in the next week to enhance the performance of the dispatcher. The performance always have been the Achilles’ heel of the dispatcher. Actually, the achilles' heel is the lack of clarity in the documentation. This mail is an amazing coincidence. One of our team hear asked me this morning how to do something with the dispatcher. I've done it before and have sites running dispatcher, but I can't remember how I did it and I can't point to any documentation about it. In many cases this will mean that the dispatcher is not used and a potential contributor is lost. Performance is irrelevant if there are no users. Another week point was/is the readability of the code. Indeed, this is part of the documentation. Another thing that I always wanted to integrate are java based contracts. I want to allow within the next version of the dispatcher that one can use a class instead of a xsl. How about we finish one feature before adding another? Since future version of cocoon are based on Spring and I am really appreciate Spring as an excellent IoC container the dispatcher will be as well based it. +1 My plan is that this work will be compatible with the current version of the dispatcher. It will provide simple shell scripts to update the current version of structurer/contracts to the new form. I do not like the specific extension we have for structurer (.fv)/contracts (.ft) anymore since they are historic and do not reflect anymore the reality. To remember ft stands for forrestTemplate and fv for forrestView which is the first names of contracts and structurer. Instead I suggest *.contracts.xml and *.structurer.xml. Fine. My initial plan is to reuse the code from whiteboard/dispatcher, conduct the needed changes to work with java contracts and add spring support. Any thoughts. Documentation. Documentation and, er, documentation. Other than that go for it! Ross
Re: Dispatcher 1.0 - towards a stable version
Thorsten Scherler wrote: On Fri, 2008-09-05 at 14:51 +0100, Ross Gardler wrote: Thorsten Scherler wrote: Hi all, I will have some time in the next week to enhance the performance of the dispatcher. The performance always have been the Achilles’ heel of the dispatcher. Actually, the achilles' heel is the lack of clarity in the documentation. This mail is an amazing coincidence. One of our team hear asked me this morning how to do something with the dispatcher. I've done it before and have sites running dispatcher, but I can't remember how I did it and I can't point to any documentation about it. How about http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.internal.dispatcher/ I agree that documentation always can be enhanced but we have some. I didn't say there was no documentation I said there was a documentation problem. Pointing to a resource that is unintelligible does not help. I've read those docs, even written some of them, but they make little sense to me and I have the background of Forrest. The individual I'm talking about has also read them and failed to achieve what he needs. (and yes I have directed him to the lists - he'll turn up soon I'm sure - but this is a low priority project for us so time is not on our side) ... I totally agree that the next version should be documented in more detail. I promise I will write as much javadocs as possible and we should review above linked documentation and see how we can be more clear about it. Excellent - thank you. Of course, I should help myself, but I don't have the time. I only mention it because you asked for opinion. Another week point was/is the readability of the code. Indeed, this is part of the documentation. Yes, I agree. I found a nice tool to create uml diagrams in javadocs: UmlGraph. Have a look at the droids javadoc to see it in action. What about the horrible mess of redirection (indirection) between sitemap and locationmap. I've found it near to impossible to figure out what is coming from where in the dipatcher. I'm sure it doesn't need to be as complex as it is, but I can't figure out how to simplify it. Perhaps an effort to document the flow will help make it understandable or illustrate where we can simplify. Again, I doubt I'm going to be able to do this myself, I'm just flagging areas for improvement - sine you ask ;-) e.g. http://people.apache.org/~thorsten/droids/api/org/apache/droids/api/Droid.html I'll have to take a look at UMLGraph - thanks. Another thing that I always wanted to integrate are java based contracts. I want to allow within the next version of the dispatcher that one can use a class instead of a xsl. How about we finish one feature before adding another? Which feature is unfinished? I have more or less a week for the rewrite and yes I will first concentrate on implementing everything we have till now in a clean efficient way and then if time allows at the java contract support. Dispathcer. It's still in whiteboard , therefore it is unfinished. I'm just saying we should get a usable version out there that people can use (normal people, not just those with years of Forrest history) and then start adding new features. Cheers Ross for your feedback. You're welcome. I know your big enough to pick and choose the most important bits, rather than think I'm demanding the world (although if you want to deliver the world...) Ross
Re: output.inputModule Plugin dependency
Thorsten Scherler wrote: On Mon, 2008-09-01 at 13:40 +0300, Sjur Moshagen wrote: ... I agree with Ross that the easiest solution would be to just move the code to core. Yeah, it is just one generator. It is fine with me to move this class directly to the core, best solution IMO is to leave it in the plugin structure but build it by default with the core. Meaning we can drop the dependency in the required plugin section. However ATM I cannot look into the needed changes for that. I am fine with either move the class directly to the core or generate the jar once and add it to the lib dir. In both cases we need the one match that the plugin offers in the main sitemap. Looks like we have a solution then. I don't understand the motivation for leaving the code in a plugin but building it with core, I'm -0 on that. Easiest solution is certainly just to take the code into core and lose the plugin, I'm +0 for that. Ross
Re: Could Forrest use Hudson?
David Crossley wrote: Ross Gardler wrote: Gavin wrote: Just wondering, Would Hudson [1] and its variety of Plugins [2] be of any use to Forrest? I'm not at all sure. Most of the utility of Hudson is in managing executble code. We have some code, but it is mostly XML and XSLT. What little code we have has almost no tests - thus making the continuous integration efforts rather pointless. Using such tools might encourage tests to be contributed and general code improvement to happen. We do have six modules in main/java/org/apache/forrest/ and some of those are extremely important to us. We have eight plugins that have some Java code. All true. Finally, we don't really have a great deal of code that depends on other code. Hmmm ... Cocoon, Avalon, Excalibur, etc. classes are mentioned a lot in the above code. Let me clarify. We don't depend on code to the extent that we are pouching the boundaries of that code and therefore need CI. We run packaged and released code. All our dependencies are inside those releases. Having Hudson won't harm us. I'm just not sure well see much benefit. Having said that, it is true that I get a kick out of seeing the graphs of tints go up and defects go down. It does indeed encourage good behaviour. Problem is we don't get all that by installing Hudson, we need much more than that. If someone is going to put that effort in then, of course, I'd be happy to see it. I just think there are other more important things to focus on. Ross
Re: [Proposal] use Cocoon-2.1
Gavin wrote: I also agree with the proposal of Option 2. And I will find time to test it over the next few days, I will provide feedback soon. Thorsten and David, great work, and it does deserve our immediate attention to this important time of Forrest, I hope other devs will be able to find some time to test also if possible. +1 (I had hoped to test over the weekend, but it didn't happen, will get it tested ASAP). Ross
Re: ODT - Specifying images to be zipped?
Gavin wrote: zip:archive zip:entry name=blah .../zip:entry /zip:archive So I need a way to automatically create zip:entry blocks for images referenced within the file. The file may or may not be local, and as far as I can tell, we don't need to physically copy them anywhere, just reference their current locations as a zip entry. Something like... xsl:template match=/ !-- create other archive entries -- xsl:call-template name=createImageEntries/ !-- more processing -- /xsl:template xsl:template name=createImageEntries xsl:for-each select=./image zip:entry xsl:attribute name=namePictures/xsl:value-of select=@src//xsl:attribute !-- need to extract the relevant part of the URI here -- xsl:attribute name=srcPictures/xsl:value-of select=@src//xsl:attribute !-- will probably need to make the path absolute, cocoon://... -- /zip:entry /xsl:for-each /xsl:template Ross
Re: OpenOffice.org output plugins license (Was: svn commit: r682286)
David Crossley wrote: Thanks for explaining. No i didn't know any of that. Perhaps it should go into the documentation for that plugin. What frightened me was seeing this in the XSL stylesheet: meta:generatorOpenOffice.org/2.4$Win32 OpenOffice.org_project/680m17$Build-9310/meta:generator meta:creation-date2008-07-31T19:08:12/meta:creation-date However, now i see that it is for default output rather than part of the XSL itself. A great example of CTR in action - thanks. Ross
[jira] Closed: (FOR-617) Forrest DOAP file
[ https://issues.apache.org/jira/browse/FOR-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ross Gardler closed FOR-617. Resolution: Fixed Closed as recommended by Carlos Tejo Forrest DOAP file - Key: FOR-617 URL: https://issues.apache.org/jira/browse/FOR-617 Project: Forrest Issue Type: Improvement Components: Documentation and website Affects Versions: 0.8 Reporter: Diwaker Gupta Priority: Trivial Attachments: doap.xml See http://thread.gmane.org/gmane.text.xml.forrest.devel/15097 for background. I've created an initial DOAP file for Forrest. Its easy to do this manually at each release. I wasn't sure how to publish it, so I thought I'd let it burn on JIRA for a while. What do people think? Its a regular XML file, but we want it published as-is, without any processing from Forrest. Will putting an exclude directive for doap.xml in cli.xconf be enough? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
