t; 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
Regards,
Ferdinand Soethe
---
Fischerzug 3a
21522 Hohnstorf
Germany
ph +4139/696244
mob +1772507870
Tax-ID.: 2326 02613903524
http://soethe.net/ferdinandSoethe.vcf
renamed to something more general.
Hmmm. I think this really depends. If this div is the container for
the box on the left side of the page, the name is
correct and clear. If is was the container for the menu it should be
changed. But since the menu is contained in
nav-section. Why change?
Regards,
Gav schrieb:
Hi All,
This was going to be an email about how PDF was not
working with Dispatcher,
more accurately that it did not work using Pelt Theme or
any theme that does
not over-ride FO from /common/ .
Usually, when I copy over Pelt Theme for over-riding to my
project, I also
copy
"cocoon://" protocol.
Now I did. And it works like a charm. Thank you kindly.
Best regards,
Ferdinand Soethe
I have some trouble using xi:include with head.
When I last used it it 0.7 something like
xmlns:xi="http://www.w3.org/2001/XInclude"/>
would include a document from the same directory that the
including file is in.
Now when I use this in head I get an error
Resource not found: file:/C:/forr
BTW, where can I find this "forrest-sample-2" so I could run it myself? I've only run
"forrest seed" now.
run "build test" in main to test all the test cases.
test sites will then be created in forrest/build directory.
Best regards,
Ferdinand Soethe
Thanks Jeremias,
some great improvements as far as I can see. Especially the
keep together for notes.
I have tested the patch but not committed it because it
broke trunk. Here is the list of problems Forrest reported:
^samples-b/
^
Since we need a lot more properties for pdf soon (as
Johannes already documented earlier on, the alternative
would be for users of older Forrests to add all these new
settings as soon as they upgrade.
Best regards,
Ferdinand Soethe
ore properties files (if all the places are used).
Perfect, hopefully somebody can find the time to document the outcoming
of the thread.
I volunteer to document the properties mechanism.
Best regards,
Ferdinand Soethe
I need to learn more about structurer and dispatcher quickly
to understand what you are saying but I agree to having
default properties for contracts.
Best regards,
Ferdinand Soethe
Thorsten Scherler wrote:
...
Meaning each contract would have publish his
own original properties
No
using the property
what values he or she has to deal with.
Thanks Thorsten for taking the time. Now I can actually
understand what you are trying to so and help move those
pdf-specific settings into the plugin-properties.
Best regards,
Ferdinand Soethe
Let me know if this is completely off track, but I'm
thinking about how best to store properties
with so many different components needing to store and
access properties.
Here are some of my thoughts:
Who needs to be able to create properties?
=
- Core
creates pr
Since Jeremias is about to release fop 0.95 with yet more
significant improvements, I amend my proposal as follows
Ferdinand Soethe wrote:
OK, so I'll wait for Johannes to finish his tests, fix what needs to be
fixed then
- copy the missing libs into the plugin, publish it a
believed the solution was so close.
Best regards,
Ferdinand Soethe
David Crossley wrote:
Ferdinand Soethe wrote:
OK, so I'll wait for Johannes to finish his tests, fix what
needs to be fixed then
- copy the missing libs into the plugin, publish it as 0.3
requiring Forrest 0.8
And deploy/release it before moving on with code.
yes, of course.
This problem was fixed by adding a height attribute.
You might have to increase the height.
See rev 627102
Best regards,
Ferdinand Soethe
Thorsten Scherler wrote:
Hi all,
I think I found a bug in footerinfo.xsl.
In a fresh site add in skinconf (to ):
Built with Apache Forrest
http
Best regards,
Ferdinand Soethe
Thorsten Scherler wrote:
On Mon, 2008-02-18 at 11:44 +, Ross Gardler wrote:
Ferdinand Soethe wrote:
The pdf-plugin will not work with 0.8 as is because it was decided to
move critical libs from the plugin back into core.
I must have missed that. Why were they moved back in?
I think
I guess Ross was referring to me. Had to look up "top post"
to know that he was referring to excessive quoting.
And yes, I did. Was in a hurry and didn't clean up.
Sorry!
Add it to the sentence for merging my branch and temporarily
breaking trunk assuming lazy consensus.
Asche auf mein Haupt
ution.
wdot?
Best regards,
Ferdinand Soethe
Johannes Schaefer wrote:
would it do any harm to deliver the libs twice?
i.e. include in the 0.8 plugin (throw out for the later
versions) and in core?
I haven't had the time to test with 0.8, yet :-(
Johannes
Ferdinand Soethe schrieb:
The
arked for 0.9?
Or would somebody wanting to use the new plugin with 0.8
also have to patch the value="0.8"/>?
Does anybody know or can anybody suggest a better solution?
Best regards,
Ferdinand Soethe
Thorsten Scherler wrote:
On Thu, 2008-02-07 at 23:36 +, Ross Gardler wrote:
...
Great! Now we don't have to maintain two versions of this
code. Thanks.
Best regards,
Ferdinand Soethe
Thorsten Scherler wrote:
On Sun, 2008-02-17 at 09:49 +0100, Ferdinand Soethe wrote:
Since the dispatcher test is still breaking trunk, I have
now fixed some of the problems with fo us
pace.
If trunk remains broken, can we perhaps take the test
involving the whiteboard plugin (dispatcher) out of the
standarf build test?
Best regards,
Ferdinand Soethe
Ferdinand Soethe wrote:
Thorsten Scherler wrote:
The FOP94 should provide this contracts directly, this way we can remove
. But it is still broken. Did I do something wrong reverting changes from 628175?
Btw. Do you know what broke trunk. Can I re-merge now that
we know that trunk was broken before?
Best regards,
Ferdinand Soethe
] [0/0] 0.313s 105.3Kb samples1/usemap.pdf
ERROR - Image not available:
cocoon://cocoon-pyramid.png
* [67/24] [0/0] 0.125s 104.9Kb samples1/ascii-art.pdf
Thanks for helping on this.
Best regards,
Ferdinand Soethe
gards,
Ferdinand Soethe
Ferdinand Soethe wrote:
Hmmm. That is strange. I just reverted my merger thinking that I had
broken trunk. But it is still broken. Did I do something wrong reverting
changes from 628175?
Best regards,
Ferdinand Soethe
Hmmm. That is strange. I just reverted my merger thinking
that I had broken trunk. But it is still broken. Did I do
something wrong reverting changes from 628175?
Best regards,
Ferdinand Soethe
solves the problem in committed.xml. Why it
does is completely beyond me.
Best regards,
Ferdinand Soethe
[EMAIL PROTECTED] wrote:
Author: ferdinand
Date: Fri Feb 15 12:29:05 2008
New Revision: 628164
URL: http://svn.apache.org/viewvc?rev=628164&view=rev
Log:
Changed image handling to s
I think we are ready to merge fop94 now.
Several bugs in documents and stylesheets have been fixed.
Build test for site-author and seed side passed without
critical errors.
The remaining problem of some broken images will not break
trunk and probably requires some more input from the communit
Thorsten Scherler wrote:
The FOP94 should provide this contracts directly, this way we can remove
them from the core themes.
I'd appreciate if you could contribute this ideally using
the stylesheets already in the plugin.
Is that possible?
Best regards,
Ferdinand Soethe
.
Any ideas how to fix that?
Best regards,
Ferdinand Soethe
Thanks Thorsten and Jeremias for your comments.
But now I'm really lost.
Can anybody who understands this perhaps suggest a solution
to this problem that is reasonable easy to implement and not
a hack?
Best regards,
Ferdinand Soethe
I'm currently testing site-author with fop94 and came across
this strange problem that in rendering
/committed.html
the aart-image
committed-1.aart (located in xdocs, being called as
committed-1.png) renders fine in html but causes this error
in rendering fop.
ERROR - Image not available:
test="normalize-space(@id)!=''">
> - -name="id">
> - -select="@id" />
> -
> -
> +
>
I can remember that having empty @id had caused me some
trouble in the
past.
salu2
Thanks Thorsten, I will fix that.
Best regards,
Ferdinand Soethe
David Crossley wrote:
Ferdinand Soethe wrote:
Actually I regret having moved them back.
If we do, the plugin won't work with Forrest 0.8 w/o manual
copying of libraries.
Therefore I'd suggest to move them back into the plugin-in
dir at least until Forrest 0.9 is released.
w
Actually I regret having moved them back.
If we do, the plugin won't work with Forrest 0.8 w/o manual
copying of libraries.
Therefore I'd suggest to move them back into the plugin-in
dir at least until Forrest 0.9 is released.
wdyt?
Ferdinand
David Crossley wrote:
Ferdinand So
If I understand you correctly I would have to add that
pipeline to the plugins sitemap so that it looks for
skinconf settings elsewhere and than what?
Where and how would I have to store the settings formerly in
skinconf?
Best regards,
Ferdinand Soethe
David Crossley wrote:
Ferdinand Soethe wrote:
Thinking again: I'd also need to merge the pdf-plugin dir
back into trunk so that change history of files is preserved.
Can I do such a partial merge?
Yes, see the svn book for instructions. Merge can operate at
any level of the tree.
Ho
x27;d like to leave for a next release of the plugin
Any comments?
Best regards,
Ferdinand Soethe
stead (see side note on the other mail) and I guess you
get back the fo.
Thanks Thorsten. That did the trick.
- removed the fo-pipeline from main sitemap
- changed build.xml
What did you change? Did not see a commit.
I actually had not committed build.xml yet.
Done now.
Best regards,
Ferd
Thorsten Scherler wrote:
That should not include common libs:
Thanks Thorsten. I had some doubts about these as well. But
since I had added them I figured that pdf must be the only
one using them atm.
Will move them back in core.
Best regards,
Ferdinand Soethe
I have prepared the pdf-plugin and done all the steps that I
thought were needed:
- moved the libs from lib/core to the plugin-lib-dir
- moved the style-sheets from common skin to
plugin-resources-dir
- adjusted output.xmap to the best of my understanding
- removed the fo-pipeline from main si
Thinking again: I'd also need to merge the pdf-plugin dir
back into trunk so that change history of files is preserved.
Can I do such a partial merge?
Best regards,
Ferdinand Soethe
Ferdinand Soethe wrote:
If I manage to build everything into the plugin, I would like to apply
thos
If I manage to build everything into the plugin, I would
like to apply those few remaining changes
- delete main\webapp\skins\common\xslt\fo
- remove fo-pipeline from sitemap
directly to head and throw the branch away.
Best regards,
Ferdinand Soethe
Johannes Schaefer wrote
Johannes Schaefer wrote:
How do I test plugins (in this case the sdocbook one)
before committing?
How about placing the uncommitted plugin code into your
build/plugins directory then test?
Best regards,
Ferdinand Soethe
Thorsten Scherler wrote:
On Sat, 2008-02-02 at 13:00 +0100, Ferdinand Soethe wrote:
So what should I do if I have no time to clean up linkmap
atm? Revert that fix so that trunk works again?
I did this now, but please next time revert it straight away.
salu2
Sorry about that. I was still
: 0.9-dev
Reporter: Ferdinand Soethe
linkmap-to-document creates invalid xml.
to reproduce call linkmap.xmp and validate it.
you will find following problems:
1. a used instead of link. however a is illegal for document 1.2
2. a-elements without (required) href-attribute. This would
Ferdinand Soethe wrote:
So what should I do if I have no time to clean up linkmap atm? Revert
that fix so that trunk works again?
I looked some more into linkmap-to-document.
Problem is that there are a number of illegal situations in
this file such as
a instead of link used
So what should I do if I have no time to clean up linkmap
atm? Revert that fix so that trunk works again?
OK, a is now link and the document validates in principle.
However with Johannes Testproject it still generates 6
error. Some of which are link without href (not legal) one
is an ulo without content.
I guess that stylesheet will need some further cleaning.
Best regards,
Ferdinand Soethe
Thanks, Johannes,
I already took the liberty to apply it:
but did it make any difference in your tests.
I just tested and the problem remains.
linkmap.xml is still invalid.
Best regards,
Ferdinand Soethe
David Crossley wrote:
Ross are you talking about "using" Forrest plugins?
IIUC, Ferdinand is talking about developing the code
in svn trunk. As far as i can see there can only be
one version.
David is right. Is it at all possible to have two separate
versions of a plugin in svn? And how would
ese issues should be
discussed separately to this "graphics too big" issue.
I'll try to find that on the list and see if that was after
I created the branch. If so I'll fix that in the branch to.
Best regards,
Ferdinand Soethe
-version with either Forrest version.
Btw. How can we maintain two plugins of the same name but
with different versions in the plugin directory?
Thanks,
Ferdinand
David Crossley wrote:
Ross Gardler wrote:
Ferdinand Soethe wrote:
We are almost there. The branch with FOP 94 is running
[
https://issues.apache.org/jira/browse/FOR-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564104#action_12564104
]
Ferdinand Soethe commented on FOR-413:
--
looking at linkmap.xml I see a document
[
https://issues.apache.org/jira/browse/FOR-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563975#action_12563975
]
Ferdinand Soethe commented on FOR-413:
--
The problem seems to be within linkmap s
Working on the FOP-Update I started wondering, why
stylesheets and libraries for the pdf-output-plugin are
placed in core instead of the plugin directory.
If it was placed in the plugin-dir one could easily change
back between fop 0.2 and fop 0.94 by simple changing the
line in forrest.proper
We are almost there. The branch with FOP 94 is running
smoothly and I'm planning to merge it back by the end of
this week.
Some questions for the experts remain:
The branch changes Forrest core and the pdf-plugin
Can I do a complete merge or will the plugin have to
become a new version?
I guess
I agree. Will check the sizing if headings and text in
general before I change that.
Best regards,
Ferdinand Soethe
Johannes Schaefer wrote:
I would choose a smaller font size for sans headings
they look too big now, IMHO.
Johannes
[EMAIL PROTECTED] schrieb:
Author: ferdinand
Date: Fri Jan
to trunk by the end
of next week if nobody objects.
Best regards,
Ferdinand Soethe
project.
With that we could actually do away with the context menu
items run and comile and just keep seed.
wdyt?
Best regards,
Ferdinand Soethe
; install-apache-forrest-0.8-in-explorer-context-menu.nsi
;
; Installation script to create context menu items
; for windows explorer that seed, ru
a context menu item for directories
in the windows explorer. That way you simply right-click
any project directory and select menu items such as
"forrest 0.8 run", "forrest 0.8 compile" etc.
Best regards,
Ferdinand Soethe
ted fop-0.94-block in
the current cocoon trunk, this block here should remain a
temporary hack until Forrests is updated to the current
cocoon release.
Best regards,
Ferdinand Soethe
changes.
Sources of the block are included. How best to document
changes of source code we don't maintain?
> Perhaps link to a Jira issue.
Updating to FOP 0.94 is not an issue yet. Should I create one?
Best regards,
Ferdinand Soethe
o the cocoon directory.
> New Revision: 604147
>
> URL: http://svn.apache.org/viewvc?rev=604147&view=rev
> Log:
> Added info on how to retrieve sources
>
> Added:
> forrest/trunk/etc/cocoon_upgrade/GettingCocoonSources.txt
Best regards,
Ferdinand Soethe
termine the rendered
size of the image in the style sheet. So a mode like switch
to scaling when image is too big would have to be done by
FOP, right?
Best regards,
Ferdinand Soethe
reate at least as good a pdf as it did
before.
Btw: The update did not fix FOR-413. Things got worse. Next
step is to check the transformation and make it standard
conforming.
Best regards,
Ferdinand Soethe
Thorsten Scherler wrote:
Thanks Thorsten. That helped quite a bit.
> Did you try to "just" add commons logging as well (drop the lib)?
I'd try if I knew where to find that lib :-)
> ..or (better) update our cocoon version to the current cocoon one or
> switch to cocoon-2.1.x. Otherwise we are r
David Crossley wrote:
> I presume that you will need to operate with our old
> version of Cocoon-2.2 and rework the Cocoon FOP Block.
Actually, Jeremias (who is helping me with this) suggested
to try and compile a new FOP Block from current coccoon
trunk. But having integrated that
(http://svn.ap
I asked Jeremias Maerki to point out where we can look up
this rule.
Best regards,
Ferdinand Soethe
[
https://issues.apache.org/jira/browse/FOR-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ferdinand Soethe reassigned FOR-413:
Assignee: Ferdinand Soethe (was: Johannes Schaefer)
I'm plannung to fix this probl
David Crossley wrote:
> I presume that you will need to operate with our old
> version of Cocoon-2.2 and rework the Cocoon FOP Block.
I'm not sure what needs to be done yet but I'll let you now
as soon as I have done my homework :-)
Ferdinand
n checkout this new branch an work on it.
Would be nice if anybody could check and confirm this before
I mess up something by accident.
Thanks,
Ferdinand
Ross Gardler wrote:
> Ferdinand Soethe wrote:
>> I'm planning to integrate the latest released version of fop
>> (.94) i
I'm planning to integrate the latest released version of fop
(.94) into trunk to solve FOR-413 and improve pdf-generation
in general. (A patch for .8 will also be provided later on.)
Since fop .94 is much closer to the standard, I will also
have to modifiy the transformation to xsl-fo in the
pdf-o
Ignore these last two paras. Thunderbird seems to have
highjacked some lines from another draft message. Arg!!
Ferdinand Soethe wrote:
> Feel free to send my that proposal if you want my comments.
> Curious to see what you are up to.
>
>> Which train do I take? I hate airplanes.
An Apache colleague looking at Forrest 0.8 just noticed that
we have used unreleased Cocoon Code in our release and told
me that this is not longer permitted.
Do we need top change our release procedures to avoid that
in the future?
Feel free to send my that proposal if you want my comments.
Curi
[
https://issues.apache.org/jira/browse/FOR-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ferdinand Soethe updated FOR-1001:
--
Attachment: error2.png
Screenshot of remaining problem with subtab.
> Broken seed site: Loss
[
https://issues.apache.org/jira/browse/FOR-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498151
]
Ferdinand Soethe commented on FOR-1001:
---
Thanks for your help. I did a complete fresh check-out of head and I&#
[
https://issues.apache.org/jira/browse/FOR-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497973
]
Ferdinand Soethe commented on FOR-1001:
---
Check out the screenshot: When a site works ok. the current tab is
[
https://issues.apache.org/jira/browse/FOR-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ferdinand Soethe updated FOR-1001:
--
Attachment: error.png
Screenshot
> Broken seed site: Loss of menu/tab context on Samples-
: Other
Affects Versions: 0.9-dev
Reporter: Ferdinand Soethe
On a freshly seeded site, accessing the samples tab will lead to a complete
loss of context in the menu and tab system that is neither the current tab nor
the current menui tem are emphasized. This problem is usually due to
Thorsten Scherler wrote:
> See "Re: svn commit: r536953 [1/14]" why I would like to change the
> behavior.
Sounds like a bug. Makes sense to fix it.
Not sure about side-effects of removing build completely, so +0
Ferdinand
that creates a direct path for html-documents.
But when I process the documents I get this message from linkrewriter.
After some fiddling everything works fine in dynamic mode but it doesn't
in static mode. Any ideas?
Best regards,
Ferdinand Soethe
ld/.
What's your reason for that proposal?
I had a similar issue some time ago because to many ../ in a link would
create content below the site-dir but that would require some other fix
to make sense.
Best regards,
Ferdinand Soethe
Looking at Cyriaques elegant solution for php-processing and finding a
similar one used for matching fo's in sitemap
>
I wonder why we are not using as similar matcher to get rid of that
redundant code in sitemap
>
>
>
>
>
>
>
>
I'm sorry to have stepped out of line. I hadn't found Cyriaques solution
when I looked for it. So I tracked down the bug on my own (in far too
much time) and wanted to share the work with others. That's all.
What I don't get: Had I found Cyriaques solution and copied it in .7
what would have been
Thanks for that pointer David. Cyriaque actually fixed the same bug in a
different way. So no need to apply this to other versions.
> This seems like a strange place to be handling processing
> instructions and xml comments. The FOR-555 indicate that
> there is a wider issue.
Did look at FOR-555
the point of view. My clients using a production
version of Forrest would certainly like to see bugs fixed in the current
version.
Best regards,
Ferdinand Soethe
If nobody has any objections I'd apply this fix to .8 and head as well
next week.
Best regards,
Ferdinand Soethe
[EMAIL PROTECTED] wrote:
> Author: ferdinand
> Date: Sun May 6 03:24:22 2007
> New Revision: 535593
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=535593
Thanks David,
that was a good lesson in how to track things down.
Nevertheless, adding the previous change into .7 did not change anything.
Any other ideas?
Best regards,
Ferdinand Soethe
I need to debug some site maps in a .7 installation so I tried to
activate the SimpleSitemapExecutor for .7 like David did for .8.
- Looked for and found the class in
cocoon-profiler-block-2.2.0-dev-r125082.jar
in lib/core
- added
to forrest-core.xconf
- checked that I have an entry for
idn't see it anywhere in
the issues scheduled for .9. I'd really like to get this done before any
more work goes into the old core format.
Best regards,
Ferdinand Soethe
Just did a bit of research in the locale issue with seed side:
Turning off project.i18n (to false) in forrest.properties would fix the
issue in both static and dynamic versions of the seed side.
Any chance to change that in the release or is that a nono without doing
an RC3?
Regards,
Ferdinand
Ross Gardler wrote:
> I think it is significant, but I think it will affect so few users it
> should not stop this release. In particular I wonder why no other tester
> found the same problem and whether this is an indicator of how many
> users will hit it.
Perhaps this has to do with the fact tha
0
I don't think the problem with the seed site is minor. Do you?
Ferdinand
Ross Gardler wrote:
> (Yes, there are a few minor problems, but the average user experience
> will be fine)
Finally found some time to download an test RC2.
What I found:
Install
Only minor documentation stuff:
./index.html
- I'd really like it to mention that you should be online when you first
run forrest after install so that the plugins can be downloaded.
Site-Author
Runs and compiles well.
For my projects the broken-links-file has often been important in
identifying the problem. I'd be sad to see it become useless.
Ferdinand
+1
will be online this week and try to put in some time for testing.
Regards,
Ferdinand Soethe
Components: Plugins: Potential new
Reporter: Ferdinand Soethe
It currently requires intimate knowledge of Forrest to find out if a given
resource is still referred to by other parts of a project. Using grep searches
requires a look up of all alternative names of such a resource (such
ap.html
> docs_0_80/howto/sitemap.xmap.html
As far as this doc is concerned yes. But since I didn't know who else
uses it, I haven't done it. (I really miss a function in Forrest that
give you all the links to a given document).
Regards,
Ferdinand Soethe
1 - 100 of 596 matches
Mail list logo
