The Forrest feels like home

[Ross Gardler (MS OPEN TECH)]

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

[Ross Gardler]

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  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-dev&m=129591307420205&w=2
> 
> 

Re: Merging back the dispatcher

[Ross Gardler]

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

[Ross Gardler]

On 22/04/2010 00:54, Tim Williams wrote:

On Mon, Dec 7, 2009 at 6:19 PM, Tim Williams  wrote:


On Sun, Dec 6, 2009 at 9:38 PM, David Crossley  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?

[Ross Gardler]

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

[Ross Gardler]

2009/11/24 David Crossley :
> 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

[Ross Gardler]

2009/11/23 David Crossley :
> 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

[Ross Gardler]

2009/11/21 David Crossley :
> 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

[Ross Gardler]

2009/11/20 Tim Williams :
> 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.

[Ross Gardler (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOR-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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(Htt

[jira] Commented: (FOR-993) Plugins not finding the optional plugin specific Locationmap causes Errors instead of warnings.

[Ross Gardler (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOR-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.

Re: problem with feeder plugin

[Ross Gardler]

2009/11/3 Vicent Mas :
>> 2009/11/2 Vicent Mas :

...

> I've done a patch for the current revision of trunk, r832303. The patch has to
> be applied to feeder_dir/src/documentation/content/xdocs/index.xml
>
> I also dowloaded the current official release tarball for linux but I cannot 
> find
> the plugin sources there. So I've not pached it for the 0.80 version.

Excellent - thank you so much.

Can you please attach your patch to an issue at
https://issues.apache.org/jira/browse/FOR

The reason is so that it does not get lost in mail (I've not got a
checkout on this machine and will not be back in the office for a week
- others may not pick it up).

The other reason is so that we can do proper tracking of your
contribution and ensure you are correctly credited.

Thanks again for you contributions - they are very much appreciated.

Ross

Re: problem with feeder plugin

[Ross Gardler]

2009/11/2 Vicent Mas :

...

> This was wrong. The file has not xdoc format. Simply
>
> 
>   
>  http://news.bbc.co.uk/rss/sportonline_uk_edition/front_page/rss.xml
> 
> 
>
> 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

[Ross Gardler]

2009/10/25 Vicent Mas :
> 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: r826147 - /forrest/trunk/etc/rat-avoid.txt

[Ross Gardler]

2009/10/17  :
> Author: crossley
> Date: Sat Oct 17 00:34:38 2009
> New Revision: 826147
>
> URL: http://svn.apache.org/viewvc?rev=826147&view=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=826147&r1=826146&r2=826147&view=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: svn commit: r825833 - /forrest/trunk/etc/rat-avoid.txt

[Ross Gardler]

2009/10/16  :
> Author: crossley
> Date: Fri Oct 16 10:11:32 2009
> New Revision: 825833
>
> URL: http://svn.apache.org/viewvc?rev=825833&view=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=825833&r1=825832&r2=825833&view=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: [Important] Status and future direction

[Ross Gardler]

2009/10/16 David Crossley :
> 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

[Ross Gardler]

2009/10/16 Gavin :
>
>
>> -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: release process

[Ross Gardler]

2009/10/12 David Crossley :
> 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

[Ross Gardler]

2009/10/12 Johannes Schaefer :
> 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: [Important] Status and future direction

[Ross Gardler]

2009/10/12 David Crossley :
> 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

[Ross Gardler]

2009/10/9 Thorsten Scherler :
>
> 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  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

[Ross Gardler]

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

[Ross Gardler]

I agree with

Sent from my mobile device.

On 8 Oct 2009, at 13:35, Tim Williams  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: assistance with Forrest

[Ross Gardler]

Well done David

Ross

Sent from my mobile device.

On 8 Oct 2009, at 08:50, David Crossley  wrote:


The purposes of this email are to remind people
about some of the useful facilities of Forrest,
and also alert them to discussion about the status
and future directions of Forrest, and to appeal for
people to assist Forrest.

I intend to send this to all of the ASF projects
that manage their websites with Forrest.
See my home directory at p.a.o which has a tool
to find them. There are about 55 websites, managed
by about 16 Top Level Projects.

It is also useful for developers who manage any
website with Forrest.

Later when we are more clear about our direction
we can send something similar to our user mail list.

--- oOo ---

These are useful facilities to assist with developing
and managing a Forrest solution for your project's website.

"How to deploy documentation with the Forrestbot
svn workstage"
This explains how the Forrest project manages our
own documentation.
http://forrest.apache.org/howto-forrestbot-svn.html

"Generate an ASF mirrors page using interactive web form"
http://forrest.apache.org/docs/dev/howto/howto-asf-mirror.html

"ForrestBar - Firefox toolbar to ease navigation
and search of Forrest resources"
http://forrest.apache.org/tools/forrestbar.html

"How to do development with Apache Forrest"
http://forrest.apache.org/howto-dev.html

"Frequently Asked Questions"
http://forrest.apache.org/faq.html

"The Anakia output plugin"
This was developed to assist the old Incubator
website to stop using Forrest and export all content
to an Anakia "xdoc" format. From there it could used
by an Anakia-based build system, or be further transformed.
http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.Anakia/

As usual, if you need further assistance with anything
then please ask on the Forrest mail lists.

--- oOo ---

There is discussion currently underway on the Forrest
dev mail list about the current status and future
direction of Forrest.
http://thread.gmane.org/gmane.text.xml.forrest.devel/27325

If anyone can assist Forrest, in any capacity, then
please do.

-David

Re: ical output plugin - sitemap feedback wanted

[Ross Gardler]

2009/8/19 David Crossley :
> 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:
>>
>> 
>> 
>>     
>>     
>>         
>>         
>>     
>>     
>> 
>>
>> 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:

  

  
  

  

forrest.properties.xml:


...


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: prompting a release (Was: r19010 ... board_agenda_2009_08_19.txt

[Ross Gardler]

2009/8/19 David Crossley :
> 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

Fwd: board: r19010 - /foundation/board/board_agenda_2009_08_19.txt

[Ross Gardler]

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:  
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: missing license headers

[Ross Gardler]

2009/7/20 David Crossley :
> 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

[Ross Gardler]

2009/6/5  :
> Author: sina
> Date: Fri Jun  5 13:11:58 2009

Welcome Sina.

Ross

Re: Simple include files?

[Ross Gardler]

2009/5/16 Brolin Empey :
> 2009/5/15 Gavin 

...

> Anyway, can we please get back on track?  Can someone please change
> the XDocs DTDs so I can use  as a child of a 
> (after the optional )?

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: class attribute of body element in XDocs source is not included in generated HTML

[Ross Gardler]

2009/5/16 Brolin Empey :
> 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?

[Ross Gardler]

2009/5/16 Gavin :
>
>
>
>
> 
>
> 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 
>
> 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

[Ross Gardler]

2009/5/15 Brolin Empey :
> 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:
>
> 
>
> 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: reducing duplication in menus with pelt skin

[Ross Gardler]

2009/5/5 Brolin Empey :
> Hello,
>
> See the Products menu on the left side of .
> 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: How can I use class lists with XDocs?

[Ross Gardler]

2009/5/14 Brolin Empey :
> 2009/5/13 David Crossley 
>>
>> 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: problem skinning legacy html

[Ross Gardler]

2009/4/11 Vicent Mas :
>
> 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

[Ross Gardler]

2009/3/23 Sjur Moshagen :
> Replying to myself:
>
> Den 23. mar. 2009 kl. 14.59 skrev Sjur Moshagen:
>
>> The action on line 117 in that build file reads:
>>
>>   
>>     
>>       
>>       
>>     
>>   
>
> If I change this to the following:
>
>    
>      
>        
>        
>      
>    
>
> 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

[Ross Gardler]

2009/3/18 David Crossley :
> 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

[Ross Gardler]

2009/3/11 David Crossley :
> 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: Applying patches

[Ross Gardler]

2009/3/3 David Crossley :
> 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

Re: site-author - no output during forrest run

[Ross Gardler]

2009/3/3 Gavin :
> 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: [jira] Commented: (FOR-1160) Enhanced locationmap documentation, added example and fixed some typos

[Ross Gardler]

2009/3/3 EMMEL Thomas :
> 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-tabpanel&focusedCommentId=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

Applying patches

[Ross Gardler]

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: not resolved in helper-commonElements.xsl, bug or feature?

[Ross Gardler]

2009/2/27 EMMEL Thomas :
> Ross Gardler schrieb:
> ...
>
> Such a hole would not show up when converting to HTML as the 
> 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  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  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:
>
>      "-//APACHE//ENTITIES Common Character Entity Sets V1.0//EN"
>     "common-charents-v10.mod">
> %common-charents;
>
>      "-//APACHE//ENTITIES Documentation V2.0//EN"
>     "document-v20.mod">
> %document;
>
> and refere to it in a document like this:
>
> 
> 
>
> 
>   
>     test
>   
> 
> test this link:
>  http://forrest.apache.org";>Forrest.
> 
> 
>
> 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  elements internally only ,  and . 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: plugin: output.pdf: not resolved in helper-commonElements.xsl, bug or feature?

[Ross Gardler]

2009/2/26 EMMEL Thomas :
> Ross Gardler schrieb:
>
> 2009/2/26 EMMEL Thomas :
>> 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 @@
>>       
>>     
>>   
>> -  
>> +  
>>     >       select="$config/colors/col...@name = 'body']/@link"/>
>>     
>>
>> Is it a bug or feature that  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  element. Under what
> circumstances do you find a document containing an  gets processed
> by this stylesheet?

...

> Confusion 
>
>  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  and  and  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 
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  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: plugin: output.pdf: not resolved in helper-commonElements.xsl, bug or feature?

[Ross Gardler]

2009/2/26 EMMEL Thomas :
> 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 @@
>       
>     
>   
> -  
> +  
>            select="$config/colors/col...@name = 'body']/@link"/>
>     
>
> Is it a bug or feature that  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  element. Under what
circumstances do you find a document containing an  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: question to FOR-1136 and locationmap.xml not found

[Ross Gardler]

2009/2/25 EMMEL Thomas :

> 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: Merge output plugins OpenOffice.org-output with OOo

[Ross Gardler]

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

[Ross Gardler]

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: Piwi - Forrest in PHP

[Ross Gardler]

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:
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 this
bro

Re: Outdated docs?

[Ross Gardler]

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

[Ross Gardler]

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

[Ross Gardler]

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

[jira] Updated: (FOR-1133) PDF don't display images in deployed WAR file on Tomcat

[Ross Gardler (JIRA)]

 [ 
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

[Ross Gardler]

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=628558&r2=628586&diff_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

Re: [jira] Commented: (FOR-1108) Dispatcher, Cocoon 2.1 and Windows

[Ross Gardler]

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-
tabpanel&focusedCommentId=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.

 
 
 
 
 src="{forrest:forrest.plugins}/ 
org.apache.forrest.plugin.output.Text/resou

rces/stylesheets/{1}-to-{2}.xsl"/>
 
   
 


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)

[Ross Gardler]

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: [jira] Updated: (FOR-1005) Use sourcetypeaction for input plugins

[Ross Gardler]

Daive, I agree that this is a good entry level issue. I wonder if we 
should have a page on the site that highlights these entry level issues 
with a big notice saying our devs are happy to help people understand 
the steps needed. I'd come out of the woodwork to help onlist, but I'm 
rarely engaged with Forrest as a code base anymore so I'm unlikely to 
create the page/address the issue directly.


If we add a tag to the description, or something like that, then we 
could create a standard search and automatically generate the page.


Ross





David Crossley (JIRA) wrote:

 [ 
https://issues.apache.org/jira/browse/FOR-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Crossley updated FOR-1005:


Attachment: FOR-1005-sourcetype-plugins.txt

The attached file FOR-1005-sourcetype-plugins.txt is a list of all current plugins. In 
column #1 is a symbol to indicate its status. So far i have just used 'find and grep' to 
see if their sitemaps use "sourcetype". There are 49 plugins, of which 11 use 
sourcetype.


Use sourcetypeaction for input plugins
--

Key: FOR-1005
URL: https://issues.apache.org/jira/browse/FOR-1005
Project: Forrest
 Issue Type: Improvement
 Components: Plugin: input.doap, Plugin: input.foaf, Plugin: input.skos
   Affects Versions: 0.9-dev
   Reporter: Ross Gardler
Attachments: FOR-1005-sourcetype-plugins.txt


Wherever possible input plugins should use the sourcetypeaction to figure out 
whether to process a file or not.
Too many plugins use a fixed url space for this, it is not maintainable.

Re: Forrest friendly searching

[Ross Gardler]

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%3Afgpzn29ywzq&q=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)

[Ross Gardler]

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: input.wordpress (was Re: potential new plugin)

[Ross Gardler]

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: [forrest seed] problem with dispatcher

[Ross Gardler]

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)

[Ross Gardler]

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: Xdoc documentation

[Ross Gardler]

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

[Ross Gardler]

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

[Ross Gardler]

David Crossley (JIRA) wrote:
[ https://issues.apache.org/jira/browse/FOR-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Ross Gardler (JIRA)]

 [ 
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
>
>
>  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.

[jira] Closed: (FOR-1111) publicationStmt info in document-to-teiLite.xsl contains incorrect defaults

[Ross Gardler (JIRA)]

 [ 
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:
> 
>   OSS Watch, Oxford University
>   OSS Watch
>   
> [EMAIL PROTECTED]
>   
>   
> 
>   http://creativecommons.org/licenses/by-sa/2.0/uk/
> 
>   
>   
> 
> 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] Closed: (FOR-1113) New section in tei output with all the references in the document

[Ross Gardler (JIRA)]

 [ 
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.

Re: Conditional locations and i18n

[Ross Gardler]

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

Conditional locations and i18n

[Ross Gardler]

I recently reverted a patch by Sjur because I broke backwards 
compatibility. See [1]


I just found myself searching for that in the archives so I could point 
a colleague to it. I discovered that Sjur had made a proposal for an 
alternative patch as follows:


Would a conditional sitemap along the lines of the following be a 
possible solution?


--


 pattern="^(.*?)([^/]*).xml$">


 value="{properties:forrest.i18n}"/>


  pattern="{lm:project.{1} {2}.*.moinwiki}"> src="{source}" /> src="cocoon:/moinwiki.xlex"/> src="cocoon:/moinwiki.xgrm"/> src="{lm:wiki.transform.moinwiki.xdoc}"> value="{../2}" /> value="true"/>   
 


  src="{lm:project.{1} {2}.moinwiki}" /> src="cocoon:/moinwiki.xlex"/> src="cocoon:/moinwiki.xgrm"/> src="{lm:wiki.transform.moinwiki.xdoc}"> value="{2}" />  
  




 

That is, do as before unless i18n has been turned on in forrest.properties.

WDYT?

--

Sjur, sorry I have not responded. I can't find the email anywhere on my 
machine. Not sure what happened to it.


The problem I see with this is that a site with i18n turned on and the 
desire to retrieve content remotely will still fail. This will not 
affect my sites (non have i18n turned on) but it may affect other 
peoples sites.


I'm happy to reduce my -1 to a -0 for your proposed solution. I can't 
help thinking there is a better way though, perhaps a property local to 
the wiki plugin telling it whether it should allow i18n requests. The 
default would be no i18n to maintain backward compatibility.


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.


Ross

[1] http://markmail.org/message/orpwr7kfivdi7iso

Rename ODT example site

[Ross Gardler]

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

Re: Using forrest.properties.xml inside a xsl

[Ross Gardler]

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:
  

  References
  

  
  

  

  
  

  

  

  

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:


  

  


  

  

  

  

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

Re: Using dispatcher contracts with a not html output

[Ross Gardler]

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: Seed site, whiteboard or example?

[Ross Gardler]

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-1106) Dispatcher quickstart documentation hard to follow

[Ross Gardler (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOR-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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  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.

[jira] Closed: (FOR-1112) Incorrect example with local plugin dirs in "Extending Forrest with Plugins"

[Ross Gardler (JIRA)]

 [ 
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] Assigned: (FOR-1111) publicationStmt info in document-to-teiLite.xsl contains incorrect defaults

[Ross Gardler (JIRA)]

 [ 
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:
> 
>   OSS Watch, Oxford University
>   OSS Watch
>   
> [EMAIL PROTECTED]
>   
>   
> 
>   http://creativecommons.org/licenses/by-sa/2.0/uk/
> 
>   
>   
> 
> 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] Commented: (FOR-1111) publicationStmt info in document-to-teiLite.xsl contains incorrect defaults

[Ross Gardler (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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:
> 
>   OSS Watch, Oxford University
>   OSS Watch
>   
> [EMAIL PROTECTED]
>   
>   
> 
>   http://creativecommons.org/licenses/by-sa/2.0/uk/
> 
>   
>   
> 
> 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

[Ross Gardler]

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:





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.


   

   
 
 false
 10
   




This is main/webapp/WEB-INF/cocoon.xconf in FORREST_HOME, isn't it? I 
have change it to:





  
  false
  10


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

[Ross Gardler (JIRA)]

 [ 
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

[Ross Gardler]

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

[jira] Updated: (FOR-1108) Dispatcher, Cocoon 2.1 and Windows

[Ross Gardler (JIRA)]

 [ 
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.

[jira] Created: (FOR-1108) Dispatcher, Cocoon 2.1 and Windows

[Ross Gardler (JIRA)]

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.

Re: [STATUS] [heads-up] merging our branch Cocoon-2.1

[Ross Gardler]

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

Re: [STATUS] [heads-up] merging our branch Cocoon-2.1

[Ross Gardler]

Thorsten Scherler wrote:

On Thu, 2008-09-11 at 23:22 +0100, Ross Gardler wrote:

Why do these things always occur at critical times?


Because it seems we failed to test on windows in the branch. 


:-)

Fair comment (I'm especially glad I emphasised that I wasn't complaining 
now - shame you stripped that - I look an ass in the archives now - 
again I'm not complaining - I'm emarassed that I didn't test on windows 
prior to the merge)


Ross

Re: [STATUS] [heads-up] merging our branch Cocoon-2.1

[Ross Gardler]

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: svn commit: r691518 - /forrest/trunk/plugins/org.apache.forrest.plugin.input.wiki/input.xmap

[Ross Gardler]

[EMAIL PROTECTED] wrote:

Author: sjur
Date: Tue Sep  2 22:35:58 2008
New Revision: 691518

URL: http://svn.apache.org/viewvc?rev=691518&view=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: Properties for contract (was Re: Dispatcher 1.0 - towards a stable version)

[Ross Gardler]

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

Re: i18n message catalogue in dispatcher and skins

[Ross Gardler]

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:

  src="org.apache.cocoon.transformation.I18nTransformer">


  location="{properties:skins-dir}common/translations"/>


true
  

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)

[Ross Gardler]

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: Resolving relative locations in the locationmap

[Ross Gardler]

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: Resolving relative locations in the locationmap

[Ross Gardler]

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: [Vote] Move output.inputModule into core

[Ross Gardler]

Thorsten Scherler wrote:

Through the recent update of the pdf plugin we creates a implicit plugin
dependencies on the output.inputModule plugin. This cause a couple of
problems [1/2]. We decided the best approach to get rid of the
dependency is by moving the plugin into core. 


Please vote if you are in favor to move the code into core.


+1

Ross

Resolving relative locations in the locationmap

[Ross Gardler]

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)

[Ross Gardler]

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

[Ross Gardler]

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

[Ross Gardler]

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: Dispatcher 1.0 - towards a stable version

[Ross Gardler]

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