Re: [jira] Updated: (FOR-617) Forrest DOAP file

[Diwaker Gupta]

On Thursday 11 August 2005 1:40 am, David Crossley wrote:
> Aha, i see that you have been misunderstanding
> something fundamental. It needs to be published
> via our normal document publishing, just like
> any other document.

Thanks a ton for clearing that up! All this while I had been under the 
impression that everything on Forrest's website had to go through a Forrest 
publishing process. Completely forgot about the .htaccess! :-)

I have added the doap.xml file both to Forrest trunk and site. Right now I've 
just synced them manually, and its not linked from anywhere within site.xml 
yet. That will probably change as we figure out the best way of publishing 
this info.

> To publish the website manually, do the following.
> It is good to get a feel for how it all happens,
> then use the forrestbot most times after that.

This was very useful, thanks again!

> Or use the forrestbot as described in
> trunk/etc/publishing_our_site.txt
> which you already did sucessfully recently.

I sure did.

Diwaker
-- 
Web/Blog/Gallery: http://floatingsun.net


pgpKwWGwNtnpX.pgp
Description: PGP signature

passing parameters from sitemaps to stylesheets

[David Crossley]

Gav wrote:
> 
> How do I check for project.i18n=true (from forrest.properties created by 
> forrest seed) from this when statement.
> 
> I have :-
> 
>  
>  /* also tried $config/i18n 
> and a few others, this is where I'm stuck */
> (i18n compatible stuff)
>   
>
>(Remove i18n stuff)
> 
>  

Ah, this is turning in to a useful lesson. How to
pass parameters from the sitemaps into the stylesheets
and how to access project properties.

Notice that pelt/xslt/html/site2xhtml.xsl
imports common/xslt/html/site2xhtml.xsl
Look at the latter.



That sets $config to all of the values from the
project's skinconf.xml file. This information has
been previously aggregated by the sitemap into the 
xml stream that we are transforming.



That was passed to this stylesheet from the sitemap.

Lets look at the sitemaps to find out how:
cd /svn/asf/forrest/main/webapp
grep site2xhtml *
more sitemap.xmap

That shows that the sitemap resource named "skinit"
was called with 
That passes the value of the uri being processed.

Looking at the skinit resource, a transformer then
applies the relevant stylesheet and passes the
parameter "path".

So you could get other properties into your final
stylesheet in that way. Looking at the sitemaps
you can see that those values are obtained from
properties using the syntax {project:blah} or
{defaults:blah} {request:blah} {forrest:blah} etc.

The main/webapp/WEB-INF/xconf/forrest-core.xconf
shows how those values are made available using
"sitemap input modules".

-David

Re: FOR-592 - pelt and i18n clarifications

[David Crossley]

Gav wrote:
>
> | > | > Should there be an if statement added to pelt skin to check for
> | > | > project.i18n=true and act accordingly, as in provide an alternative 
> if
> | > it is
> | > | > turned off -- which it is by default.?
> | > |
> | > | Could do that. That would be a an immediate solution.
> | > | This ablility to add translation for certain parts
> | > | of the skin such as "Search", was only added very
> | > | recently. Perhaps it does need better implementation.
> | >
> | > I will look into it, I somehow feel this is a quick-fix and not the 
> proper
> | > solution. If I do not find the proper solution soon I will implement 
> this
> | > fix as an interim and see what you think.
> |
> | This is definitely the best way to go at this stage.
> | Yep, i reckon do the workaround above, then get on to
> | something else. This excursion to understand i18n has
> | given you a little more grasp of how to work with
> | Forrest internals.
> 
> Well, I'm working on this and need a bit of help to complete it.
> 
> I am using  block and then an  in the pelt 
> site2xtml.xsl but the
> when statement is causing me problems.
> 
> How do I check for project.i18n=true (from forrest.properties created by 
> forrest seed) from this when statement.

See my separate message today about
"passing parameters from sitemaps to stylesheets".

While this could solve the issue, you are right that
this feels like a quick fix.

Another approach would be to add another transformer at
the very end of the processing for html output, whose
job is to remove the unnecessary  wrappers which
are left over from not having done i18n processing.

That would be an "otherwise" clause at
main/webapp/sitemap.xmap line 242

Yet another approach would be to have i18n happening
all the time. But that topic is too big for the moment.
Lets get one of these workarounds happening first.

-David

[jira] Commented: (FOR-572) run a memory profiler while forrest is operating

[David Crossley (JIRA)]

[ 
http://issues.apache.org/jira/browse/FOR-572?page=comments#action_12318565 ] 

David Crossley commented on FOR-572:


Another separate discussion thread:

Quick glimpse at Forrest's build times
http://marc.theaimsgroup.com/?t=11237704496

> run a memory profiler while forrest is operating
> 
>
>  Key: FOR-572
>  URL: http://issues.apache.org/jira/browse/FOR-572
>  Project: Forrest
> Type: Task
>   Components: Core operations
> Versions: 0.8-dev
> Reporter: David Crossley
> Priority: Critical
>  Fix For: 0.8-dev

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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Quick glimpse at Forrest's build times

[Ross Gardler]

Ron Blaschke wrote:

I did a quick comparison of Forrest revision 231407 (before Cocoon
update) and revision 230867 (somewhere near HEAD).


Ron, this work you are doing is fantastic. I don't know how you can call 
it "quick", it seems very detailed to me.


I've not got the time to go into it in detail right now, I hope someone 
else can follow up with you. I just want to show my appreciation.


CHEERS!!!

Ross

Re: joinin LENYA and FORREST

[Ross Gardler]

David Podunavac wrote:

I am David, some of you might remember me from the ApacheCon this year,
anyway I heard the need of joinin LENYA and FORREST and the discussion
monday late night.


Good to "see" you again.




 here are some tries or ideas on how lenya and forrest could/should work
together

 this MARRIAGE(joining lenya and forrest) what i call it now could be
done on the publication-sitemap.xmap level


There are two aspects to integration of Forrest and Lenya. The first is 
the publication aspect, but the Lenya folk also want to leverage the 
input side of Forrest. However, since publication is the easier part (at 
least to me as a Forrest dev) lets focus on that first.



 when we look at the sitemaps of lenya and forrest we will see that they
look alike
 
 take a look at the publication-sitemap.xmap

@lenya-1.2.x/build/lenya/webapp/lenya/pubs/default/
 of a clean lenya lines 120ff.





[Note I am confused about this publication-sitemap.xmap file. Does 
publication in its title mean the publication of documents, or is it the 
publication that make up a Lenya site? I suspect it is the later very 
confusing!]



and compare this to forrest sitemap.xmap @forrest/main/sitemap





  our plan is to integrate forrest into lenya (hope that is okay
with you forrest guys :) )
  to do so marcin mentioned that:
 
  lenya should do the matching on the first level than

  forrest should receive the content like (menus, tabs, body) from lenya
  and transform this content into forrest conform content (so this
content could be used in forrest)
  after this step lenya lets forrest do the all the styling


For Forrest a request of http://localhost:/index.html is processed 
as follows:


src -> [input plugin] -> core -> skin -> [output plugin]

Forrest core would make additional requests for different parts of the 
page (such as navigation and tabs). So this one reqest would actually 
create a number of the above processes to be executed.


You sugest (below) that we create a new sitemap to enable Forrest to 
publish content, I'm not sure this is the right approach. Both Lenya and 
Forrest are moving targets and keeping these sitemaps synchronised will 
require maintenance by someone with a foot in both camps. What we really 
need is a way of integrating things in a much more maintainable way.


In the new Locationmap functionality in Forrest 0.8-dev (see 
http://forrest.apache.org/docs_0_80/locationmap.html ) we can map a 
request for a particular file to a defined location. So for example.


FORREST FILE   |   LENYA FILE
---+-
site.xml   |   
tabs.xml   |   
*.xml  |   

If lenya can expose the relevant equivalent files via a URL then we 
simply map the forrest rquired files to the relevant Lenya URL. Then we 
create a forrest:view that will produce the output that Lenya needs and 
we are done.


Since all data is request directly from Lenya there is no complexities 
with user management and the like as Lenya still has control over all 
this stuff. However, I've not yet thought about how Forrest will pass 
authentication information back and forth. I'd have to explore the 
authentication used in Lenya first.


All the existing publication (as in creating the output) pipelines in 
lenyas sitemaps are removed. All publication is handled by Forrest.


I created a very simple demo of this some time back as a result of a 
discussion with Gregor see

http://marc.theaimsgroup.com/?l=forrest-dev&m=111814596828488&w=2

Ross

Quick glimpse at Forrest's build times

[Ron Blaschke]

I did a quick comparison of Forrest revision 231407 (before Cocoon
update) and revision 230867 (somewhere near HEAD).

Unfortunately, very little showed up.  Here's what I did.

I ran a CPU profile on both revisions, which wasn't very helpful at
all.  Nothing interesting showed up.  "chaperon" seems to eat a
significant amount of CPU time, though.


Then I tried something else: Taking a look at the numbers output by
Cocoon, which prints statements like the following.

* [3/43][8/25]1.892s 5.4Kb   pluginDocs/index.html
* [4/43][1/25]0.962s 5.7Kb   issues.html
* [6/42][1/29]0.971s 6.2Kb   tools/index.html
  ^^

I decided to compare the time reported between the two revisions,
using a single run on each revision.
First the totals.

Revision 231407  Total time: 20 minutes 31 seconds ( 624 seconds)
Revision 230867  Total time: 10 minutes 24 seconds (1231 seconds)

Seems to be similar to the time difference reported by others.

There's a difference of about 607 seconds to account for (on my box).
I matched the individual times for each document, using a simple
script.  The result is like this:
Page Old   New  Diff
/docs_0_60/changes.html  4.487s -> 9.534s5.047s
/docs_0_60/changes.pdf   5.538s -> 9.914s4.376s
/docs_0_60/changes.rss   0.170s -> 0.110s   -0.060s
/docs_0_60/compliance.html   0.942s -> 1.722s0.780s
/docs_0_60/compliance.pdf0.440s -> 0.241s   -0.199s
/docs_0_60/faq.html  1.712s -> 8.232s6.520s
/docs_0_60/faq.pdf   0.882s -> 6.359s5.477s
...

I pulled everything into a spreadsheet, and took the total of all time
differences.  The total is about 602 seconds, in my opinion close
enough to the expected 607.

Below are the pages that contribute 5 seconds or more to the
difference.  All numbers are in seconds.
Be warned that I currently don't know if these numbers have any
significance at all.  They may mean a lot, or nothing at all!  The
main reason I am presenting them is that I'll probably don't
have any more time for this issue this week, and they may (or may
not!) be useful to someone.

Note that many pages seem to be generated twice, because of slightly
different URLs; eg
/docs_0_80/changes.pdf  2,453   14,411  11,958
docs_0_80/changes.pdf   3,184   14,772  11,588
(second and third line in the table below)

Also note that the times (generation and difference) may be close
together, like above.  But they may also differ quite significantly.
docs_0_60/changes.html  2,003   13,409  11,406
/docs_0_60/changes.html 4,487   9,534   5,047
Not quite unexpected, as these times are wall clock. There are other
processes running on my box, the garbage collector, ...


PageOld New Difference
docs_0_60/changes.pdf   2,653   15,673  13,020
/docs_0_80/changes.pdf  2,453   14,411  11,958
docs_0_80/changes.pdf   3,184   14,772  11,588
docs_0_60/changes.html  2,003   13,409  11,406
/docs_0_80/changes.html 1,973   12,718  10,745
/docs_0_70/changes.html 2,684   13,339  10,655
docs_0_70/changes.pdf   5,188   15,623  10,435
docs_0_80/faq.html  1,312   11,386  10,074
/docs_0_80/faq.pdf  2,043   12,077  10,034
/docs_0_70/changes.pdf  2,623   11,757  9,134
docs_0_70/changes.html  1,592   9,934   8,342
index.html  1,221   9,184   7,963
index.pdf   2,073   10,004  7,931
docs_0_80/changes.html  3,115   10,815  7,700
/docs_0_80/faq.html 0,811   8,352   7,541
/docs_0_70/faq.html 1,322   8,172   6,850
docs_0_70/your-project.html 1,301   7,871   6,570
docs_0_70/faq.pdf   1,102   7,641   6,539
/docs_0_60/faq.html 1,712   8,232   6,520
docs_0_80/faq.pdf   1,232   7,741   6,509
docs_0_60/your-project.pdf  1,302   7,561   6,259
docs_0_60/sitemap-ref.pdf   0,931   7,181   6,250
/docs_0_60/your-project.pdf 0,752   6,980   6,228
docs_0_80/your-project.pdf  1,091   7,240   6,149
/docs_0_60/sitemap-ref.html 1,241   7,260   6,019
/docs_0_70/sitemap-ref.html 1,262   7,180   5,918
docs_0_70/sitemap-ref.pdf   1,191   6,879   5,688
docs_0_60/your-project.html 1,282   6,789   5,507
/docs_0_60/faq.pdf  0,882   6,359   5,477
docs_0_70/faq.html  1,803   7,271   5,468
/docs_0_70/faq.pdf  2,403   7,601   5,198
/docs_0_60/changes.html 4,487   9,534   5,047

Ron

[jira] Mis-à-jour: (FOR-583) Pelt compatible [views/templates] skin

[Cyriaque Dupoirieux (JIRA)]

 [ http://issues.apache.org/jira/browse/FOR-583?page=all ]

Cyriaque Dupoirieux updated FOR-583:


Attachment: FOR-583-ViewHelperUpdatedLeatherDevTemplates.diff

Updated Leather-dev Templates.
Summary :
  - branding-fontsize.ft - add of a div for presentation
  - nav-section.ft - Complex update in order to have the expand/collapse 
behaviour that we have on menus in Pelt. (Still needs to work...)
  - nav-main-sub.ft - updated because of the empty div tags problem (cf. 
http://marc.theaimsgroup.com/?t=11225626114&r=1&w=2)
  - branding-grouplogo.ft - change an unused div id by a usefull div class
  - search-input.ft - totally recreated but fully compliant - add of the 
input-size argument, add of search-input-head to include javascript.
  - content-xml-link.ft - change an unused div class="dida" by a usefull div 
class="format"
  - branding-projectlogo.ft - Id becomes class
  - content-abstract.ft - add a normalize-space test on abstract div in order 
to avoid empty div tag again
  - siteinfo-credits.ft - totally recreated but compliant 
  + add of box-location parameter to filter the credits to display (in Pelt 
you can display credits at three different location and I wanted to keep this 
Idea)
   This argument is actually used to define the name of the embbeding 
div class for the presentation. To have a good result you should not have 
   box-location="alt" or "alt2" like previously with Pelt skin but 
rather box-location="credit" or "credit2" !
  + add of top-separator parameter - not sure it's a good idea, but it let 
you have an horizontal separator before your credits (only if there are credits 
to display)
  + add of use-role-as-prefix parameter - not used yet
   - the idea is to filter again credits in order to display different 
lists of credits depending the page...
   - in that case I would like to use the role attribute of credits to 
filter - for instance : if use-role-as-prefix="Linux", I will display the 
credits which roles starts-with "Linux"...
  - content-motd-page.ft - totally recreated but compliant, Leather-dev MOTD 
was a very old fashion (only one motd for the whole site), so I updated with 
the Pelt one...
  - content-title.ft - add of the sub-title management
  - content-main.ft - replace a copy-of by an apply-templates in order to 
manage the different header styles (boxed, underlined...)
+ I think I have forgotten skinconf-heading-2...

Ok, everything here and all the previous patches needs rework, it just a 
beginning.

   

> Pelt compatible [views/templates] skin
> --
>
>  Key: FOR-583
>  URL: http://issues.apache.org/jira/browse/FOR-583
>  Project: Forrest
> Type: Improvement
>   Components: Views
> Versions: 0.8-dev
> Reporter: Diwaker Gupta
> Assignee: Diwaker Gupta
>  Attachments: FOR-583-ViewHelperNewCSS4Pelt.diff, 
> FOR-583-ViewHelperNewTemplates4Pelt.diff, 
> FOR-583-ViewHelperUpdatedLeatherDevCSS.diff, 
> FOR-583-ViewHelperUpdatedLeatherDevTemplates.diff, 
> FOR-583-ViewHelperXmap.diff, FOR-583-ViewPlugin.diff
>
> Ross had rightly observed that unless [views/templates] provide a Pelt 
> look-alike package, it will be a substantial hurdle in migrating to 0.8. I 
> understand that over the next few weeks vies/templates are going to be under 
> discussion and potentially major/minor changes. Still, I believe the core 
> architecture will not deviate substantially from where it stands right now -- 
> and so I think atleast we should start working towards a Pelt look-alike.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: FOR-592 - pelt and i18n clarifications

[Gav....]

- Original Message - 
From: "David Crossley" <[EMAIL PROTECTED]>
To: 
Sent: Monday, August 08, 2005 10:58 PM
Subject: Re: FOR-592 - pelt and i18n clarifications


|
| > | > Should there be an if statement added to pelt skin to check for
| > | > project.i18n=true and act accordingly, as in provide an alternative 
if
| > it is
| > | > turned off -- which it is by default.?
| > |
| > | Could do that. That would be a an immediate solution.
| > | This ablility to add translation for certain parts
| > | of the skin such as "Search", was only added very
| > | recently. Perhaps it does need better implementation.
| >
| > I will look into it, I somehow feel this is a quick-fix and not the 
proper
| > solution. If I do not find the proper solution soon I will implement 
this
| > fix as an interim and see what you think.
|
| This is definitely the best way to go at this stage.
| Yep, i reckon do the workaround above, then get on to
| something else. This excursion to understand i18n has
| given you a little more grasp of how to work with
| Forrest internals.
|

Well, I'm working on this and need a bit of help to complete it.

I am using  block and then an  in the pelt 
site2xtml.xsl but the
when statement is causing me problems.

How do I check for project.i18n=true (from forrest.properties created by 
forrest seed) from this when statement.

I have :-

 
 /* also tried $config/i18n 
and a few others, this is where I'm stuck */
(i18n compatible stuff)
  
   
   (Remove i18n stuff)

 

Thanks

Gav... 



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.5/68 - Release Date: 10/08/2005

[jira] Mis-à-jour: (FOR-583) Pelt compatible [views/templates] skin

[Cyriaque Dupoirieux (JIRA)]

 [ http://issues.apache.org/jira/browse/FOR-583?page=all ]

Cyriaque Dupoirieux updated FOR-583:


Attachment: FOR-583-ViewHelperUpdatedLeatherDevCSS.diff

Update of default.css in order to facilitate then Pelt/Leather dev compliance.
(Nothing important ;-) )

> Pelt compatible [views/templates] skin
> --
>
>  Key: FOR-583
>  URL: http://issues.apache.org/jira/browse/FOR-583
>  Project: Forrest
> Type: Improvement
>   Components: Views
> Versions: 0.8-dev
> Reporter: Diwaker Gupta
> Assignee: Diwaker Gupta
>  Attachments: FOR-583-ViewHelperNewCSS4Pelt.diff, 
> FOR-583-ViewHelperNewTemplates4Pelt.diff, 
> FOR-583-ViewHelperUpdatedLeatherDevCSS.diff, FOR-583-ViewHelperXmap.diff, 
> FOR-583-ViewPlugin.diff
>
> Ross had rightly observed that unless [views/templates] provide a Pelt 
> look-alike package, it will be a substantial hurdle in migrating to 0.8. I 
> understand that over the next few weeks vies/templates are going to be under 
> discussion and potentially major/minor changes. Still, I believe the core 
> architecture will not deviate substantially from where it stands right now -- 
> and so I think atleast we should start working towards a Pelt look-alike.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Mis-à-jour: (FOR-583) Pelt compatible [views/templates] skin

[Cyriaque Dupoirieux (JIRA)]

 [ http://issues.apache.org/jira/browse/FOR-583?page=all ]

Cyriaque Dupoirieux updated FOR-583:


Attachment: FOR-583-ViewHelperNewCSS4Pelt.diff

New css for Pelt Theme...

> Pelt compatible [views/templates] skin
> --
>
>  Key: FOR-583
>  URL: http://issues.apache.org/jira/browse/FOR-583
>  Project: Forrest
> Type: Improvement
>   Components: Views
> Versions: 0.8-dev
> Reporter: Diwaker Gupta
> Assignee: Diwaker Gupta
>  Attachments: FOR-583-ViewHelperNewCSS4Pelt.diff, 
> FOR-583-ViewHelperNewTemplates4Pelt.diff, FOR-583-ViewHelperXmap.diff, 
> FOR-583-ViewPlugin.diff
>
> Ross had rightly observed that unless [views/templates] provide a Pelt 
> look-alike package, it will be a substantial hurdle in migrating to 0.8. I 
> understand that over the next few weeks vies/templates are going to be under 
> discussion and potentially major/minor changes. Still, I believe the core 
> architecture will not deviate substantially from where it stands right now -- 
> and so I think atleast we should start working towards a Pelt look-alike.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Mis-à-jour: (FOR-583) Pelt compatible [views/templates] skin

[Cyriaque Dupoirieux (JIRA)]

 [ http://issues.apache.org/jira/browse/FOR-583?page=all ]

Cyriaque Dupoirieux updated FOR-583:


Attachment: FOR-583-ViewHelperNewTemplates4Pelt.diff

Add of new contracts (templates) for Pelt :
-
I don't give here the list, the names are clear enough...

> Pelt compatible [views/templates] skin
> --
>
>  Key: FOR-583
>  URL: http://issues.apache.org/jira/browse/FOR-583
>  Project: Forrest
> Type: Improvement
>   Components: Views
> Versions: 0.8-dev
> Reporter: Diwaker Gupta
> Assignee: Diwaker Gupta
>  Attachments: FOR-583-ViewHelperNewTemplates4Pelt.diff, 
> FOR-583-ViewHelperXmap.diff, FOR-583-ViewPlugin.diff
>
> Ross had rightly observed that unless [views/templates] provide a Pelt 
> look-alike package, it will be a substantial hurdle in migrating to 0.8. I 
> understand that over the next few weeks vies/templates are going to be under 
> discussion and potentially major/minor changes. Still, I believe the core 
> architecture will not deviate substantially from where it stands right now -- 
> and so I think atleast we should start working towards a Pelt look-alike.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Mis-à-jour: (FOR-583) Pelt compatible [views/templates] skin

[Cyriaque Dupoirieux (JIRA)]

 [ http://issues.apache.org/jira/browse/FOR-583?page=all ]

Cyriaque Dupoirieux updated FOR-583:


Attachment: FOR-583-ViewHelperXmap.diff

Update of viewHelper plugin :

1) update of output.xmap to search for contracts as follows : 
- first in {project:resources}/templates/{1}.ft
- if not found then in resources/templates/{forrest:skin}/{1}.ft (New)
- if not found then in resources/templates/{1}.ft

2) update of resources.xmap to search for resources (css...) as follows : 
- first in {project:skins-dir}{path}
- then in resources/skin/{path}/{forrest:skin}/ (New)
- then in resources/skin/{path}/
- then in {forrest:context}/skins/common/{path}/

in fact, this patch is not yet used...
we need to use the forrest:theme indeed cf. 
http://marc.theaimsgroup.com/?l=forrest-dev&m=112361309014245&w=2


> Pelt compatible [views/templates] skin
> --
>
>  Key: FOR-583
>  URL: http://issues.apache.org/jira/browse/FOR-583
>  Project: Forrest
> Type: Improvement
>   Components: Views
> Versions: 0.8-dev
> Reporter: Diwaker Gupta
> Assignee: Diwaker Gupta
>  Attachments: FOR-583-ViewHelperXmap.diff, FOR-583-ViewPlugin.diff
>
> Ross had rightly observed that unless [views/templates] provide a Pelt 
> look-alike package, it will be a substantial hurdle in migrating to 0.8. I 
> understand that over the next few weeks vies/templates are going to be under 
> discussion and potentially major/minor changes. Still, I believe the core 
> architecture will not deviate substantially from where it stands right now -- 
> and so I think atleast we should start working towards a Pelt look-alike.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Mis-à-jour: (FOR-583) Pelt compatible [views/templates] skin

[Cyriaque Dupoirieux (JIRA)]

 [ http://issues.apache.org/jira/browse/FOR-583?page=all ]

Cyriaque Dupoirieux updated FOR-583:


Attachment: FOR-583-ViewPlugin.diff

Update of view plugin :
---
1) update of prepare.xhtml.xsl now take into account for link tag :
- rel attribute in order to define rel="alternate stylesheet" (if not 
supplied then rel="stylesheet")
- title attribute in order to distinguish alternate style sheets - 
title="Leather-dev" for all stylesheets used by leather-dev...
- media attribute in order to distinguish screen or print stylesheets 
(needed for Pelt)

2) add pelt.fv

> Pelt compatible [views/templates] skin
> --
>
>  Key: FOR-583
>  URL: http://issues.apache.org/jira/browse/FOR-583
>  Project: Forrest
> Type: Improvement
>   Components: Views
> Versions: 0.8-dev
> Reporter: Diwaker Gupta
> Assignee: Diwaker Gupta
>  Attachments: FOR-583-ViewPlugin.diff
>
> Ross had rightly observed that unless [views/templates] provide a Pelt 
> look-alike package, it will be a substantial hurdle in migrating to 0.8. I 
> understand that over the next few weeks vies/templates are going to be under 
> discussion and potentially major/minor changes. Still, I believe the core 
> architecture will not deviate substantially from where it stands right now -- 
> and so I think atleast we should start working towards a Pelt look-alike.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: How to find things to contribute (was: Re: Reducing Forrest build time)

[Gav....]

| 
| In particular, a good way of getting a handle on where Forrest *may* 
| head in the next few releases would be to address 
| http://issues.apache.org/jira/browse/FOR-618 "Create issues for items 
| discussed at Apachecon"
| 
| Ross

Thanks, I will take a look at this.

Gav...


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.5/68 - Release Date: 10/08/2005

joinin LENYA and FORREST

[David Podunavac]

Hi devs,

I am David, some of you might remember me from the ApacheCon this year,
anyway I heard the need of joinin LENYA and FORREST and the discussion
monday late night.
As Ross encouraged me to post or to help you out, with the stuff I know
about LENYA. So here it is the things that came to my mind on how stuff
works or the things i know about to let you know, in order to make this
MARRIAGE possible.
I hope this will help:
-
the entry point for lenya is the sitemap.xmap @LENYA_HOME/build/lenya/webapp

-this sitemap defines all the components used, can be compared to the
root sitemap in forrest as far as i can see
-then the authorizer action is being called which mounts the
global-sitemap.xmap
-the global-sitemap handles all the modules i call it modules i dont
know if it is the right name
 but what i mean with modules is e.g. the built-in wysiwyg editors, the
search engine, usecases, the i18n stuff the admin-area etc
 for all this modules an extra sitemap is mounted
 
 the same with the actual publication as lenya has different
publications (<-- is this the same as your forrest seeds?)
 and different areas: areas is the level of published documents e.g if a
document is created it is in the authoring area
 when the editor is done writing the doc he submits it and the reviewer
has to publish it
 so this document is copied from the authoring area to live and the
visitor can finally view the page
 
 so if your uri looks like this
 http://localhost:/default/authoring/
 http:///{PUBLICATION}/{AREA}/
 
 so the sitemap.xmap @LENYA_HOME/build/webapp/lenya/pubs/{PUBLICATION}
is called
 which mounts the publication-sitemap.xmap in the same directory 
 
 this publication-sitemap.xmap mounts the doctypes.xmap and handles the
document aggregation
 like navigational elements (breadcrumb, tabs, menus) with the actual
content of the document
 after this aggregation it calls the transformation for the doctype
requested
 
 this is when the authorizer checks if the requested url is only for
certain users
 i am skippin the long description how lenya might work on this
 loading the global-sitemap.xmap @LENYA_HOME/build/webapp
 the global-sitemap.xmap is used only internal
 
 
 here are some tries or ideas on how lenya and forrest could/should work
together

 this MARRIAGE(joining lenya and forrest) what i call it now could be
done on the publication-sitemap.xmap level
 
 when we look at the sitemaps of lenya and forrest we will see that they
look alike
 
 take a look at the publication-sitemap.xmap
@lenya-1.2.x/build/lenya/webapp/lenya/pubs/default/
 of a clean lenya lines 120ff.
 
 

  
  

  
  
  
  
  


  
  
  
  
  

 
  
   

  
  
  
  


  

   
and compare this to forrest sitemap.xmap @forrest/main/sitemap
   


  

  
  
  
  
  

   

  
  

  

  

  
  
  
  
  


  
  

  
  ...
 
 
  our plan is to integrate forrest into lenya (hope that is okay
with you forrest guys :) )
  to do so marcin mentioned that:
 
  lenya should do the matching on the first level than
  forrest should receive the content like (menus, tabs, body) from lenya
  and transform this content into forrest conform content (so this
content could be used in forrest)
  after this step lenya lets forrest do the all the styling
 
 
 
  so here is the pseudo pipeline as far as we understood forrest and
lenya
 
  
  

 
   


 


  
  
  

  
 
 
  
 
 
  
  
   

  
  
  


  
  


  


sure there are alot of things to do in order to make this run
like adjusting pipelines, parameters etc etc
but we want to help you guys on that but we NEED YOUR HELP and FEEDBACK
   
   
  please let me know if this thinking makes sense or if there are
things we did not understood or thought about right
  if you guys agree with this approach or have any hints or problems
which we haven't thought about let us know
  or things you want us to do
  feel free
 
  we definitely want to help and wait for some any feedback if this
all makes sense
 
 
  regards
 
  marcin and david

Hope that helps somehow : )

[jira] Created: (FOR-620) Create interactive Forrest command

[Ross Gardler (JIRA)]

Create interactive Forrest command
--

 Key: FOR-620
 URL: http://issues.apache.org/jira/browse/FOR-620
 Project: Forrest
Type: New Feature
  Components: Core operations  
Reporter: Ross Gardler
Priority: Minor


New users will often just type "forrest" to try and see what is happening. 
However, this command behacves differently under different circumstances. It 
would be better to have an interactive Forrest command that gives sensible 
options for the current situation.

See http://marc.theaimsgroup.com/?l=forrest-dev&m=112368671329083&w=2 for some 
ideas

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: spelling: main/var/pluginlist2echo.xsl (functionlaity)

[Ross Gardler]

scott hutinger wrote:


Index: main/var/pluginlist2echo.xsl
===
--- main/var/pluginlist2echo.xsl(revision 231292)
+++ main/var/pluginlist2echo.xsl(working copy)



Thanks for the patch, I've applied it.

It's always best to put patches in the issue tracker where they can't 
get forgotten about.


Ross

Re: Reducing Forrest build time

[David Crossley]

Juan Jose Pablos wrote:
> David Crossley wrote:
> >
> >Would you please explain what you found.
> >
> Sure
> 
> the cocoon-core.xconf and the forrest-core.xconf differ in content.

Ah, i see. Of course we can all help to synchronise
those configurations. Step 9 of the README.

> What I did was to add  a source-factory. But I see that there still more 
>  WARNING that I need to review.
> 
> >I see that the build time for our "site-author" docs
> >has dropped from 32 minutes to 19 minutes. However
> >that is still a long way from the 7 minutes that
> >it was prior to the Cocoon upgrade.
> ok, nice to know. I will try to find sometime to bring this number 
> down...

Thanks mate, we can all help. Great to see the profiling
that Ron is doing.

I am going to learn the Cocoon upgrade process.
I gather that the etc/cocoon_upgrade/README.txt
is not up-to-date now (i can do that) and there
is now the ant build script instead of the
upgrade_cocoon_jars.sh script.

-David

Re: Reducing Forrest build time

[Juan Jose Pablos]

David Crossley wrote:

Juan Jose Pablos wrote:

By the way, I found the problem with the performance, I will commit 
later today...



Would you please explain what you found.


Sure

the cocoon-core.xconf and the forrest-core.xconf differ in content.
What I did was to add  a source-factory. But I see that there still more 
 WARNING that I need to review.




I see that the build time for our "site-author" docs
has dropped from 32 minutes to 19 minutes. However
that is still a long way from the 7 minutes that
it was prior to the Cocoon upgrade.
ok, nice to know. I will try to find sometime to bring this number 
down...

Re: [OT] Getting an old mail ?

[David Crossley]

Cyriaque Dupoirieux wrote:
> 
>Is it possible to get again an old message from the list which I 
> have deleted ?
>Ezmlm writes in the help of the list that we can do something like :
> 
> To receive all messages with the same subject as message 12345,
> send an empty message to:
>   <[EMAIL PROTECTED]>
> 
> But how to find the 12345 in marc.theaimsgroup.com ?

Don't know sorry. I think that the numbers are
local to ezmlmn.

Does the help at ezmlm.org help?
There is a dev-index@ command, gives subject/Id
then work backwards from there.

If you know the year and month, then you can get
everything for the whole month gzipped at:
http://forrest.apache.org/mail/

-David

[Fwd: Re: Deeper Look at Memory Issue, Maybe Successful [FOR-572]]

[Thorsten Scherler]

-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)
--- Begin Message ---
Thanks Ron,

that is some very useful work for us. Keep it up. :)

salu2

On Thu, 2005-08-11 at 09:17 +0200, Ron Blaschke wrote:
> Thursday, August 11, 2005, 4:21:50 AM, David Crossley wrote:
> > Ron Blaschke wrote:
> >> I've had another look at Forrest's memory issue, this time more
> >> deeply.  I still only understand parts of it, and hope someone can
> >> help fill in the missing pieces.
> >>
> >> Now, my question is: How do you guys usually proceed if you have
> >> issues like this with Cocoon?
> 
> > Thanks so much for doing this Ron. The best thing would
> > be to create an issue at Cocoon's issue tracker [1].
> [snip]
> 
> Thanks, will do.
> 
> > Using your workaround, do you still see the massive slowdown
> > with Forrest building "site-author" that we are seeing after
> > our recent Cocoon upgrade [2]?
> 
> Yes, not much of a change.  The plain numbers on my box are:
> 
>   Original: Total time: 20 minutes 8 seconds
>   Modified: Total time: 19 minutes 46 seconds
> 
> These numbers are from Forrest revision 231407, using JRE 5.
> 
> > [2] http://marc.theaimsgroup.com/?t=11235712761
> > "Reducing Forrest build time"
> 
> Thanks, this thread also answers my mediator question.
> 
> I'll run a CPU profile for this second issue, maybe some hints show
> up.
> 
> Ron
> 
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)
--- End Message ---

Re: [jira] Updated: (FOR-617) Forrest DOAP file

[David Crossley]

Diwaker Gupta wrote:
> David Crossley wrote:
> > It would be better to have it in our SVN.
> > In that way, if you are absent at the time that we do
> > the next release, then we will still be able to update it.
> > No rush with that part of course, but that would be preferable.
> 
> I can put it in SVN, thats not a problem. But it still needs to be published 
> *somewhere* -- that was my main concern. Is there a way to host it under 
> forrest.apache.org somehow?

Aha, i see that you have been misunderstanding
something fundamental. It needs to be published
via our normal document publishing, just like
any other document.

We have other files there too, e.g. mirrors.cgi
and .htaccess file, and raw files linked from some
pages, e.g. there are some pre-prepared dtdx/*.pdf
There are various ways of delivering raw files. See FAQ.
Just linking to daof.xml seems to work.

Maybe you do understand the mechanism for
publishing our website, but i will describe
it anyway. One day i will put it into a howto.

The source files go in our site-author
and then after one of us generates the site then
we would 'svn commit' to the separate "site" repository,
which gets automatically 'svn up' on the server to
form our website.

So we have these two repositories (and more):
https://svn.apache.org/repos/asf/forrest/trunk ... forrest-trunk
https://svn.apache.org/repos/asf/forrest/site ... forrest-site

To publish the website manually, do the following.
It is good to get a feel for how it all happens,
then use the forrestbot most times after that.

svn update forrest-trunk
svn update forrest-site
cd forrest-trunk/site-author
svn add content/whatever (adding entries to site.xml etc.)
forrest site
diff -rq build/site ../../forrest-site | grep -v "\.svn"
... Ensure that the differences are what you expect.
cp -Rf build/site ../../forrest-site
... Now do the usual stuff in your forrest-site working copy:
'svn update' 'svn status' 'svn add' 'svn diff' 'svn commit'

Or use the forrestbot as described in
trunk/etc/publishing_our_site.txt
which you already did sucessfully recently.


If the doaf.xml file was not going to be linked anywhere
then could take a shortcut and not do 'forrest site'.
Can keep the two files synchronised manually.
The same as what happens with the .htaccess file.
The source is at forrest-trunk/site-author/content/.htaccess
and the "generated" file is at forrest-site/.htaccess

-David

[OT] Getting an old mail ?

[Cyriaque Dupoirieux]

Hi,

   Is it possible to get again an old message from the list which I 
have deleted ?

   Ezmlm writes in the help of the list that we can do something like :

To receive all messages with the same subject as message 12345,
send an empty message to:
  <[EMAIL PROTECTED]>

But how to find the 12345 in marc.theaimsgroup.com ?

--

Regards,
Cyriaque,

Re: Deeper Look at Memory Issue, Maybe Successful [FOR-572]

[Nicola Ken Barozzi]

Ron Blaschke wrote:
...
> After compiling Coccon and replacing cocoon-2.2.0-dev-r230820.jar, I
> changed forrest.properties in site-author to "forrest.maxmemory=32m,"
> and ran "forrest site," with sucess.  I also compared two memory
> snapshots taken during the run, and they look good.

WOW!

Well done :-)

-- 
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

Re: Interactive Forrest command

[Cyriaque Dupoirieux]

David Crossley a écrit :


Johannes Schaefer wrote:
 


...


Somebody typing just 'forrest' does not know how it is
used. She would maybe expect some help or even better:
an interactive guide to getting started with forrest.
   


Yes that is a better place for the interactive target I described. So
options would be things like:

site - build a forrest site in the current directory
run - run forrest in dynamic mode in the current directory
seed - create a simple starter site in the current directory
seed-sample - create a sample site...
seed-business - create a simple site template for a business
available-plugins - list all the plugins available for Forrest
 


Should add default values to go faster (just type enter key) :
(Based on properties to be able to change them...)


If the guide was intelligent, options would be like:

$forrest
"This directory does not contain a forrest project.
You can:
 0 . Get more help on options (forrest project-help)
[1]. Seed an example project with content (forrest seed or seed-sample)
 2 . Seed a project skeleton  (forrest seed-basic)
 3 . Seed a business example  (forrest seed-business)
 4 . ...
Your choice: _ ([1] Default)"

$forrest
"This directory contains a forrest project.
You can:
 0 . Get more help on options (forrest project-help)
[1]. Start forrest in live mode   (forrest run)
 2 . Create a static site (forrest site)
 3 . Create a webapp to deplay in tomcat  (forrest webapp)
 4 . ...
Your choice: _ ([1] Default)"

But then, this looks like a wizard ;-)
   



 


Command-line wizards can be useful too.
 


Of course - always separate "GUI" and behaviours.

Amicalement,
Cyriaque,


-David

 


Doing this will hekp users learn/remember the targets available and does
not prevent them from running any of the targets directly, i.e. "forrest
seed", "forrest run", "forrest site"

Ross
 


Johannes
   




 

Re: [Who we are] How to become an inactive commiter ;-)

[Nicola Ken Barozzi]

Diwaker Gupta wrote:
> On Wednesday 10 August 2005 7:28 am, Ferdinand Soethe wrote:
> 
>>I think we'll do fine having people adjust their status as they see
>>fit in most cases. No need to create more work around that.
> 
> +1

Furthermore, if we feel that someone has gone inactive, we should ask
him. If he doesn't respond, then we can set him inactive.

In any case, it's something that one can get out of by just coming back :-)

-- 
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

Re: Deeper Look at Memory Issue, Maybe Successful [FOR-572]

[Ron Blaschke]

Thursday, August 11, 2005, 4:21:50 AM, David Crossley wrote:
> Ron Blaschke wrote:
>> I've had another look at Forrest's memory issue, this time more
>> deeply.  I still only understand parts of it, and hope someone can
>> help fill in the missing pieces.
>>
>> Now, my question is: How do you guys usually proceed if you have
>> issues like this with Cocoon?

> Thanks so much for doing this Ron. The best thing would
> be to create an issue at Cocoon's issue tracker [1].
[snip]

Thanks, will do.

> Using your workaround, do you still see the massive slowdown
> with Forrest building "site-author" that we are seeing after
> our recent Cocoon upgrade [2]?

Yes, not much of a change.  The plain numbers on my box are:

  Original: Total time: 20 minutes 8 seconds
  Modified: Total time: 19 minutes 46 seconds

These numbers are from Forrest revision 231407, using JRE 5.

> [2] http://marc.theaimsgroup.com/?t=11235712761
> "Reducing Forrest build time"

Thanks, this thread also answers my mediator question.

I'll run a CPU profile for this second issue, maybe some hints show
up.

Ron