Re: [VOTE] Move Apache Forrest to the Attic
+1 El lun., 11 nov. 2019 6:46, David Crossley escribió: > The Apache Forrest project has seen little activity for a long time, and > there has not been a release since 2011. > > As noted in the quarterly Board reports [1], for years the Forrest PMC has > been keeping the project in maintenance mode. > > Recent board reports have indicated a move to the Apache Attic. A thread > was commenced on the project mailing lists to provide an opportuntity for > people to discuss that possibility and to re-engage [2]. There was no > further discussion. > > Note that the project resources would still be available. There would be > no further releases. The Apache Forrest PMC would be terminated by Board > resolution, and the Apache Attic PMC would instead have the oversight. > > This vote thread is to confirm the desire of the project, being the next > step in the Attic process [3]. > > The general voting process is explained at the Forrest project guidelines > [4]. This situation was not anticipated by the guidelines. So in this case > anyone can vote. > > So please vote whether Apache Forrest will be retired and moved to the > Attic: > +1 yes move to the Attic > -1 the project should continue, and indicates commitment to revitalise the > project > > The three outcomes could be: > > A) There are three or more people voting -1, saying that they would > instead like the project to continue and agree to be involved. > In this case, a probable course would be to go via the Apache Incubator > [5] to revitalise the community. > > B) The normal positive outcome, with three or more +1 votes. > C) Insufficent votes indicates a dormant PMC. > > So in those latter cases, the remainder of the Attic process would ensue. > > Also note that even after moving to the Attic, there are processes defined > there regarding moving out again. > > The vote will run for one month to be summarised on 11 December. > > > [1] https://whimsy.apache.org/board/minutes/Forrest.html > > [2] > https://lists.apache.org/thread.html/fda24957e049f10d282037594d2aa61ce9a31cf8fc5313959aa81672@%3Cdev.forrest.apache.org%3E > Subject: Forrest possibly retiring? > Date: 2019-06-11 > > [3] https://attic.apache.org/process.html > > [4] https://forrest.apache.org/guidelines.html > > [5] https://incubator.apache.org/ > >
Re: please add your PGP key
El 30/11/10 14:03, David Crossley escribió: Please add your PGP key to the Forrest KEYS file. See http://forrest.apache.org/procedures/release/How_to_release.html and Find in Page KEYS -David Hi David, Mine is there... do you want me to update to this one: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCD53A63D5CE5BDF9
[jira] Closed: (FOR-900) forrest requires a running X-server on UNIX
[ http://issues.apache.org/jira/browse/FOR-900?page=all ] Juan Jose Pablos closed FOR-900: Resolution: Invalid There is already documented a solution on the forrest.properties file # Any other arguments to pass to the JVM. For example, to run on an X-less # server, set to -Djava.awt.headless=true repopen de bug if this solution does not work for you. forrest requires a running X-server on UNIX --- Key: FOR-900 URL: http://issues.apache.org/jira/browse/FOR-900 Project: Forrest Type: Bug Components: Launch 'forrest' Versions: 0.7 Reporter: Erik van Zijst When the forrest command is used to compile the site on a server machine that does not run a graphical display (no X server running), it fails with the stacktrace below. When an X server is (temporarily) started, it works. snip Lazy mode: true Lazy mode: true Lazy mode: true * [1/20][20/20] 9.222s 7.2Kb linkmap.html Lazy mode: true Lazy mode: true * [2/19][0/0] 0.631s 1.0Kb skin/print.css Lazy mode: true * [3/18][0/0] 8.943s 0b skin/images/rc-b-l-15-1body-2menu-3menu.png Exception in thread main java.lang.InternalError: Can't connect to X11 window server using 'localhost:0.0' as the value of the DISPLAY variable. at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) at sun.awt.X11GraphicsEnvironment.access$000(X11GraphicsEnvironment.java:53) at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:142) at java.security.AccessController.doPrivileged(Native Method) at sun.awt.X11GraphicsEnvironment.clinit(X11GraphicsEnvironment.java:131) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:164) at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:68) at java.awt.image.BufferedImage.createGraphics(BufferedImage.java:1141) at org.apache.batik.ext.awt.image.GraphicsUtil.createGraphics(GraphicsUtil.java:515) at org.apache.batik.gvt.filter.GraphicsNodeRed8Bit.genRect(GraphicsNodeRed8Bit.java:120) at org.apache.batik.gvt.filter.GraphicsNodeRed8Bit.copyData(GraphicsNodeRed8Bit.java:108) at org.apache.batik.ext.awt.image.rendered.TileCacheRed.genRect(TileCacheRed.java:53) at org.apache.batik.ext.awt.image.rendered.AbstractTiledRed.drawBlockInPlace(AbstractTiledRed.java:594) at org.apache.batik.ext.awt.image.rendered.AbstractTiledRed.drawBlock(AbstractTiledRed.java:527) at org.apache.batik.ext.awt.image.rendered.AbstractTiledRed.copyToRasterByBlocks(AbstractTiledRed.java:420) at org.apache.batik.ext.awt.image.rendered.AbstractTiledRed.copyData(AbstractTiledRed.java:287) at org.apache.batik.ext.awt.image.rendered.TranslateRed.copyData(TranslateRed.java:97) at org.apache.batik.ext.awt.image.rendered.PadRed.copyData(PadRed.java:87) at org.apache.batik.gvt.renderer.StaticRenderer.repaint(StaticRenderer.java:390) at org.apache.batik.gvt.renderer.StaticRenderer.repaint(StaticRenderer.java:340) at org.apache.batik.transcoder.image.ImageTranscoder.transcode(ImageTranscoder.java:105) at org.apache.batik.transcoder.XMLAbstractTranscoder.transcode(XMLAbstractTranscoder.java:132) at org.apache.cocoon.serialization.SVGSerializer.notify(SVGSerializer.java:206) at org.apache.cocoon.xml.dom.SVGBuilder.endDocument(SVGBuilder.java:131) at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:55) at org.apache.cocoon.components.sax.XMLTeePipe.endDocument(XMLTeePipe.java:67) at org.apache.xml.serializer.ToXMLSAXHandler.endDocument(ToXMLSAXHandler.java:180) at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1287) at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3383) at org.apache.xalan.transformer.TransformerHandlerImpl.endDocument(TransformerHandlerImpl.java:389) at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:55) at org.apache.cocoon.transformation.TraxTransformer.endDocument(TraxTransformer.java:562) at org.apache.xml.serializer.ToXMLSAXHandler.endDocument(ToXMLSAXHandler.java:180) at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1287) at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3383) at org.apache.xalan.transformer.TransformerHandlerImpl.endDocument(TransformerHandlerImpl.java:389) at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:55) at org.apache.cocoon.transformation.TraxTransformer.endDocument
Re: demo and explanation for i18n (Was: Translations in Dutch)
David Crossley escribió: BTW is the blog entry by Cheche still valid for 0.8? Don't know. Someone needs to follow it and hopefully enhance our demo. After todays change on the repository, I can confirm that they seem to work. Please report back if you find any trouble. Cheers, cheche
[jira] Commented: (FOR-876) locationmap demo in fresh-site is broken
[
http://issues.apache.org/jira/browse/FOR-876?page=comments#action_12415573 ]
Juan Jose Pablos commented on FOR-876:
--
Both fail in the same way:
on main/webapp/forrest.xmap:265:48
map:generate src={lm:project.{0}}/
goes to
match pattern=project.**
location src={project:content.xdocs}{1} /
/match
But I am guessing, I had not looked to this stuff for a while.
locationmap demo in fresh-site is broken
Key: FOR-876
URL: http://issues.apache.org/jira/browse/FOR-876
Project: Forrest
Type: Bug
Components: Core operations, Locationmap
Versions: 0.8-dev
Reporter: David Crossley
Priority: Critical
Fix For: 0.8-dev
See
Re: locationmap demo is broken
http://marc.theaimsgroup.com/?t=11468186513
--
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] Commented: (FOR-876) locationmap demo in fresh-site is broken
[ http://issues.apache.org/jira/browse/FOR-876?page=comments#action_12415629 ] Juan Jose Pablos commented on FOR-876: -- well, this must be an enviromental problem. I can see this problem: WARN(2006-06-10) 02:24.59:460 [access] (/samples/remoteDemo/index.html) PoolThread-3/CocoonServlet: Resource not found. at map:serialize type=xml - file:/home/cheche/xml/forrest/trunk/main/webapp/forrest.xmap:267:37 at map:generate - file:/home/cheche/xml/forrest/trunk/main/webapp/forrest.xmap:265:48 at map:serialize - file:/home/cheche/xml/forrest/trunk/main/webapp/sitemap.xmap:326:23 at map:transform - file:/home/cheche/xml/forrest/trunk/main/webapp/sitemap.xmap:324:73 at map:transform - file:/home/cheche/xml/forrest/trunk/main/webapp/sitemap.xmap:318:72 at map:transform - file:/home/cheche/xml/forrest/trunk/main/webapp/sitemap.xmap:296:42 at map:transform - file:/home/cheche/xml/forrest/trunk/main/webapp/sitemap.xmap:571:65 at map:transform type=linkrewriter - file:/home/cheche/xml/forrest/trunk/main/webapp/sitemap.xmap:570:79 at map:transform type=xinclude - file:/home/cheche/xml/forrest/trunk/main/webapp/sitemap.xmap:569:41 at map:transform type=idgen - file:/home/cheche/xml/forrest/trunk/main/webapp/sitemap.xmap:568:38 at map:generate - file:/home/cheche/xml/forrest/trunk/main/webapp/sitemap.xmap:567:49 at map:serialize - file:/home/cheche/xml/forrest/trunk/main/webapp/sitemap.xmap:326:23 at map:transform - file:/home/cheche/xml/forrest/trunk/main/webapp/sitemap.xmap:324:73 at map:transform - file:/home/cheche/xml/forrest/trunk/main/webapp/sitemap.xmap:318:72 at map:transform - file:/home/cheche/xml/forrest/trunk/main/webapp/sitemap.xmap:296:42 locationmap demo in fresh-site is broken Key: FOR-876 URL: http://issues.apache.org/jira/browse/FOR-876 Project: Forrest Type: Bug Components: Core operations, Locationmap Versions: 0.8-dev Reporter: David Crossley Priority: Critical Fix For: 0.8-dev See Re: locationmap demo is broken http://marc.theaimsgroup.com/?t=11468186513 -- 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] Reopened: (FOR-876) locationmap demo in fresh-site is broken
[ http://issues.apache.org/jira/browse/FOR-876?page=all ] Juan Jose Pablos reopened FOR-876: -- When I try to access http://localhost:/samples/remoteDemo/index.html I got the error, maybe is a problem with the $COCOON_HOME ? locationmap demo in fresh-site is broken Key: FOR-876 URL: http://issues.apache.org/jira/browse/FOR-876 Project: Forrest Type: Bug Components: Core operations, Locationmap Versions: 0.8-dev Reporter: David Crossley Priority: Critical Fix For: 0.8-dev See Re: locationmap demo is broken http://marc.theaimsgroup.com/?t=11468186513 -- 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: Using browser headers for i18n? (was: Per-project i18n LocaleAction and LocaleMatcher configuration)
Bertrand Delacretaz escribió:
...but It does not work in my side. I am not able to produce local
content,
I will investigate the reason...
ok, if you come up with failure scenarios please post them here so
that we can find out what's wrong.
My scenario is already documented here:
http://casa.che-che.com/blog/2005/05/10/internalization-a-site-using-forrest-07-dev/
Agreed, in that case, and when you want to have explicit locale
selection in the URLs, it's better to use something like
de/somecontent.html
fr/somecontent.html
I was using a configuration on the cli to create a static site
Which is what I'm after in fact, and currently it seems to work fine
with a matcher such as
map:match type=regexp pattern=(de|fr|en|it)/(**).html
map:generate src:=cocoon://{2}.html?locale={1}/
!-- post-process links here to get the right locale in them --
map:serialize type=html/
/map:match
What about using the i18nMatcher for this?
What is your use case, what is not working for you?
what is not working for me is what is describe in Locale
Identification on this page
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/matching/LocaleMatcher.html
Locale provided by the user agent, or server default, if use-locale is
set to true
It was not working, so I had to set {request:locale} to get it working.
I think the goal would be to get either
a) browser-based locale selection
or
b) URL-based locale selection (parameter or path)
to work, based on configurable options (sitemap patching at worst).
But maybe you have another use-case in mind?
I agree with you in the goal. I had some code already on svn to detect
alternate language (in i18n.xmap) but is it no used as default.
I use Forrest to create static content, that is why I am happy to create
a index.html.{LANG} so we let httpd do their magic.
WDYT?
cheche
about Thorsten credit and expression
Hi, I am a bit worry about the incident with Thorsten tag line for his website. It Seem that David was wrong to change that line without a bit of discussion. And we need to find a way for Thorsen to express this work on the Dispacher, Now I proposed this: Everyone write down a tag line for this website that includes Thorsten Scherler and Dispacher. mine: - know the unknown. The original idea of this site is to be a service broker. It is the website of the dispatcher artificer: Thorsten Scherler. I am guessing here but It must be a mix of words that makes everyone happy. WDYT? Cheche
Re: Patch for daisy-to-html.xsl (forrest daisy plugin)
I'm interested in seeing this applied to Forrest as Cocoon's documentation is published via Forrest from Daisy, and I'd like to update Cocoon's Daisy instance to a new release soon. Therefore, I'd also like to request if someone could look into updating that file on the Forrest zone. Done
Re: user-list is subscriber postings only
Thorsten Scherler wrote: Can we set the user list like our dev - to moderation? wdyt? I think that we better add your other address on the allow database.
Re: svn commit: r371034 - /forrest/trunk/etc/cocoon_upgrade/README.txt
David Crossley wrote: There is recent discussion in [EMAIL PROTECTED] that gives some indication of the last buildable SVN revision of Cocoon. I am happy to wait and learn a bit about maven, If I see that we can get some benefict I will code something for us.
Re: svn commit: r371034 - /forrest/trunk/etc/cocoon_upgrade/README.txt
Ross Gardler wrote: [EMAIL PROTECTED] wrote: Author: cheche Date: Sat Jan 21 05:45:57 2006 New Revision: 371034 URL: http://svn.apache.org/viewcvs?rev=371034view=rev Log: FIXME: cocoon uses Maven to build Is the Cocoon move to Maven complete? I thought it was still a work in progress. you are right, it is not complete, I could not build latest cocoon with our stuff, that is why I added this note. Cheers, cheche
[jira] Commented: (FOR-215) site.lucene name colaps with site.html request
[ http://issues.apache.org/jira/browse/FOR-215?page=comments#action_12359901 ] Juan Jose Pablos commented on FOR-215: -- Hey Ross, I can not remember right now. Posibly because this is just a work around moving site.lucene to site-creation.lucene, means the it does not collaps with a site.html but with a site-creation.html so it only reduces the changes that this collaps takes place :-) Anyway, because I am not able to retrieve the patch, I am going to modify and added to the svn. site.lucene name colaps with site.html request -- Key: FOR-215 URL: http://issues.apache.org/jira/browse/FOR-215 Project: Forrest Type: Bug Components: Launch 'forrest run' Versions: 0.6 Reporter: Juan Jose Pablos Assignee: Juan Jose Pablos Fix For: 0.8-dev Attachments: index-creation.patch Any link called site.html or site.pdf produce a loop on the search funcionality. The reason is an internal request called cocoon://site.lucene a work around would be to choose another name for this internal request. But this means that a request called /index-creation.html would have the same problem. -- 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] Resolved: (FOR-215) site.lucene name colaps with site.html request
[ http://issues.apache.org/jira/browse/FOR-215?page=all ] Juan Jose Pablos resolved FOR-215: -- Resolution: Fixed site.lucene name colaps with site.html request -- Key: FOR-215 URL: http://issues.apache.org/jira/browse/FOR-215 Project: Forrest Type: Bug Components: Launch 'forrest run' Versions: 0.6 Reporter: Juan Jose Pablos Assignee: Juan Jose Pablos Fix For: 0.8-dev Attachments: index-creation.patch Any link called site.html or site.pdf produce a loop on the search funcionality. The reason is an internal request called cocoon://site.lucene a work around would be to choose another name for this internal request. But this means that a request called /index-creation.html would have the same problem. -- 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
[Fwd: [XXE] XMLmind XML Editor V3.0]
FYI. I do not know if that is useful for anyone in the list. It talks a bit about personalize the user interface. Cheers, cheche ---BeginMessage--- XMLmind XML Editor V3.0 can be downloaded from http://www.xmlmind.com/xmleditor/download.shtml -- V3.0 (October 6, 2005) XMLmind XML Editor V3 is a complete rewrite of the ``tip of the iceberg'': the application layer. For the end-user, there is not much difference with XXE V2.11 and by consequence, V3 is fully compatible with the previous release. To make it short, the end-user will just notice that the windows displaying the document views are at the same time more powerful and more convenient to use. For the integrator and for the power-user, the situation is different: the user interface of XXE V3 can now be fully customized. Previously it was only possible to customize the document view (special commands, special bindings, etc), the XML (placeholder) menu and the standard tool bar for a given document type. For more information, please read XMLmind XML Editor - Customizing the User Interface. Enhancements: - * Documents are now displayed in tabs. Each document has its own tab. That is, the same document cannot be displayed in several different tabs. A tab can contain up to five different views of the same document. More info on this below. * The document tab area can be split in two parts, horizontally or vertically (Options|Split Windows Vertically). This allows to see two different documents side by side, very quickly and very conveniently. (To do this, simply click on the dashed line of a document tab.) If you need to see more than two documents side by side, you are out of luck. * Using Options|Options, Window section, Show both tree and styled views toggle, it is now possible to force XXE to open documents in a tab automatically containing the tree view and the styled view side by side. Using the tree view in conjunction with the styled view is still not recommended by XMLmind. You can do everything you want using the styled view and the node path bar alone. If this is not the case, then you have missed something in the tutorial. * Using View|Add, it is now possible to add up to four views (top, bottom, left, right) around the default central view of a document tab. A CSS style sheet called Document Structure has been developed for DocBook to demo this feature. For example, it is possible to add a tree view at the left of the central styled view and then, to add the Document Structure view below the central styled view. * Automating the above action is possible using the new windowLayout configuration element. Example: ++ windowLayout left / center css=DocBook / bottom css=Document structure size=0.15 / /windowLayout ++ * XXE can now automatically save modified documents. By default, this facility is disabled. You need to enable it by turning on Options|Options, Save section, Automatically save modified documents. * Upgraded XMLmind FO Converter to version 2.2 Patch 1. XMLmind FO Converter is used to convert XSL-FO to RTF and to WordprocessingML (for use by Microsoft® Office Word 2003). Bug fixes: -- * XXE raised a NullPointerException when attempting to join an empty element to its preceding sibling. Now this case is detected and therefore joining an empty element to its preceding sibling is no longer possible. * When a document was saved, a lot of whitespace was added to xi:include elements containing an xi:fallback child. * When add-ons are centralized on a HTTP or FTP server, spell checker dictionaries were detected (i.e. listed by Help|About XMLmind XML Editor) but not properly loaded. Note that loading such remote dictionaries now works but still has the following limitation. Example: if the URL of the .dar file (autodetected by XXE) is: http://lupo/~hussein/addon/spell/en.dar, XXE will just find the plain English dictionary (en) and not en and en-US and en-GB and en-CA. The workaround is to rename en.dar to en-US.dar if, for example, you prefer to use US spelling of words. Of course, there is no such limitation when the .dar file is located on the local file system. * Generated content object label(xpath,...) did not update itself when the document was about to be saved, checked for validity, etc. * Changed the detect rule in the XHTML configuration in order to allow adding xmlns=http://www.w3.org/1999/xhtml; to the html root element. Note that adding such attribute does not make a document conforming to the XHTML DTD namespace
should we publish our forrestbot log on forrest.zones.apache.org?
Hi, I think that it would be positive to publish these logs on the web so you would know the outcome of latest forrest build. Ideally a green/red message on this page would be nice: http://forrest.zones.apache.org/ WDTY? cheers, cheche
Re: current forrest trunk seems to be broken
Mark Eggers wrote: This is on Windows/2000 Professional. I've not tried it on Fedora Core 4 yet. It looks a problem with classpath on your system. our forrestbot builds fine. Cheers, cheche
Re: how to upgrade our cocoon
David Crossley wrote: I am trying to upgrade my version of Cocoon in Forrest. Following etc/cocoon_upgrade/ and have questions about the Cocoon properties files in there. Do you copy these local.*.properties over to $COCOON_HOME? It is automatic check line 107 on etc/cocoon_upgrade/build.xml Why do we also have blocks.properties and build.properties? Should these all be synchronised? There seem to be a lot of diffs between ours and also compared to Cocoon's. we do not use them right now. It is safe to remove them. We have source.vm=1.3 ... shouldn't that be 1.4 ? I do not know the effect of that parameter.. Cheers, cheche
Re: svn commit: r289909 - in /forrest/trunk/lib/core: cocoon-2.2.0-dev.jar cocoon-linkrewriter-block-2.2.0-dev.jar cocoon-template-block-2.2.0-dev.jar
David, Log: Upgrade to cocoon revision 289904 Modified: forrest/trunk/lib/core/cocoon-2.2.0-dev.jar forrest/trunk/lib/core/cocoon-linkrewriter-block-2.2.0-dev.jar forrest/trunk/lib/core/cocoon-template-block-2.2.0-dev.jar Just 3 jars were needed :-)
Re: ForrestBot build for forrest-seed FAILED
[EMAIL PROTECTED] wrote: Automated build for forrest-seed FAILED I am sure that if was the upgrade of the libraries (Avalon, Excalibur) what caused that.. There was an ok build at forrest-seed-20050918095503.log I can revert that, but it makes harder to see the problem in order to resolved. WDYT? Cheers, cheche
[jira] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.
[ http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12329738 ] Juan Jose Pablos commented on FOR-675: -- If we need to enable debug to fix this issue. Please let me know... I can do that very easily. upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc. -- Key: FOR-675 URL: http://issues.apache.org/jira/browse/FOR-675 Project: Forrest Type: Bug Components: Core operations Versions: 0.8-dev, 0.7 Reporter: David Crossley Fix For: 0.8-dev upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc. This happens in both modes: 'forret run' and 'forrest'. -- 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] Commented: (FOR-675) upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.
[ http://issues.apache.org/jira/browse/FOR-675?page=comments#action_12329750 ] Juan Jose Pablos commented on FOR-675: -- Done. Cocoon is build right now with debug=on please re-test this if you can and report back. upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc. -- Key: FOR-675 URL: http://issues.apache.org/jira/browse/FOR-675 Project: Forrest Type: Bug Components: Core operations Versions: 0.8-dev, 0.7 Reporter: David Crossley Fix For: 0.8-dev upgrading from commons-jxpath-20030909.jar to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc. This happens in both modes: 'forret run' and 'forrest'. -- 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: Forrestbot will notify about failures
David Crossley wrote: Finally the forrestbot on zones.apache.org can send mail when it fails. It runs every hour and only sends mail to [EMAIL PROTECTED] when it fails. http://forrest.zones.apache.org/ The first run is coming up in a few minutes. It will send one report that it succeeded. After that i will switch the configuration so that it will only notify a failure. -David nice one man!
Re: JX in forrest
Thorsten Scherler wrote: On Thu, 2005-09-15 at 10:06 +1000, David Crossley wrote: Anyway, not so. Did you run 'build test' after making such a drastic change? No sorry, I only tested the dynamic mode. Will be more careful in the future. I removed the offending lib again. BTW you have write access as well, right? Hey come on guys, There is not big dealt!. I made the same mistake a while ago. It is very normal to break something without intention and reversed this change is so easy sith SVN :-) Peace man! :-)
[Fwd: Serious bug in tree processor]
Hi, I think that this bug would affect us, so I decided to upgrade to cocoon revision as for today. Let me know if you find any trouble... Cheers, cheche ---BeginMessage--- I just found a big bug in our treeprocessor (2.1.8-dev and 2.2 are effect, in 2.1.7 this works perfectly): if you have several pipeline sections in the sitemap using different pipeline implementations, always the first configured is used. For example: map:pipeline type=expires ... /map:pipeline map:pipeline type=noncaching map:match pattern=a ... /map:pipeline In the example above, the expires pipeline us even used if you request a. The problem is in the PipelineNode, line . The getProcessingPipeline() method is called to set the error handler in each encountered pipeline section. The InvokeContext checks in this method if a pipeline has already been instantiated and only creates one if not. I just checked in a quick fix which resets the processing pipeline in the inform() method of the InvokeContext, but I'm not sure if this is the best way. Imho we should only lookup the pipeline component if it is really used. Perhaps this is as well the cause of Reinhard's problem wrt caching. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ ---End Message---
Tedios work and revision number
Hi,
In order to save network traffic and history, I move our jars on the
lib/core instead of removing and adding a new version.
As you know there is this historical convention pre-SVN of having a date
in the name of the library if this library comes from a non-released copy.
Because of that, every time I have to upgrade cocoon to a newest
revision number I have to do these steps that are a bit tedious:
7a. For each cocoon-{name}-{cocoon.version}-{cocoon.revision}.jar:
svn mv cocoon-{name}-{cocoon.version}-{cocoon.OLDrevision}.jar
cocoon-{name}-{cocoon.version}-{cocoon.NEWrevision}.jar
svn ci -m prework for upgrade to {cocoon.NEWrevision}
I would like to simplify this for cocoon and other libraries (jtidy and jcs)
can anyone remember why has to be like that?
would it be enough to have it on the svn history?
Cheers,
cheche
Re: Forrest Tuesday on 6 September
David Crossley wrote: Ross Gardler wrote: David Crossley wrote: So the start time is just under 23 hours away. I will be there from the start 7am my time, 6am UTC. But only for an hour. Will anyone else be present at that time, if so do you know how to start the IRC channel? I will be there. I will open the channel. Is there a reason of why the name of channel is not public? Cheers,
Re: [Vote] giving svn access to lenya commiters
Thorsten Scherler wrote: Hi all, even if I running in the danger to have called this vote (again) too early but see http://marc.theaimsgroup.com/?t=11255179263r=1w=2. Michael Wechner wrote http://marc.theaimsgroup.com/?l=lenya-devm=112551727916047w=2: I think the Lenya community should give commit access to the Forrest community if people agree to enhance the default publication of Lenya. If it is going to be a specific Forrest-Lenya publication, then I think it doesn't really matter where it's being housed as long as both communities have commit access ;-) I think the same and we already discussed it. +1 to give svn accesss to lenya commiters...
Re: End of Summer of Code
Anil Ramnanan wrote: Again thank you for your help and support. Although the Summer of Code is finished, I am not and I intend to continue contributing. Nice to know Anil :-)
Re: Forrest Tuesday (Was: Bug Days (Was Re: better use of Jira for Forrest))
David Crossley wrote: The other thing that we need to do is to log the session. I will do that locally this time, unless someone knows how to do a logger bot. We can put the result into our events SVN. I can setup a eggdrop bot to listen in whatever irc channel that you want.
[HEAD UPS] Upgrade cocoon version and xalan
Hi guys, I am in the middle of upgrade cocoon because sylvain has added Cocoon stack traces [1] to the cocoon trunk. I notice that just only 3 new jar files needs to be updated. M core/cocoon-2.2.0-dev-r230820.jar M core/cocoon-xsp-block-2.2.0-dev-r230820.jar M core/cocoon-profiler-block-2.2.0-dev-r230820.jar But in order to change the file name with the revision number (r230820) I have to commit those files and then move them ONE BY ONE to the new revision number. Seems like a process that we could improve. So can anyone have a though on this? Cheers, cheche [1] http://www.anyware-tech.com/blogs/sylvain/archives/000207.html
[jira] Created: (FOR-640) investigate [ERROR] unknown font sans,normal,normal so defaulted font to any
investigate [ERROR] unknown font sans,normal,normal so defaulted font to any -- Key: FOR-640 URL: http://issues.apache.org/jira/browse/FOR-640 Project: Forrest Type: Bug Reporter: Juan Jose Pablos An error on error.log saying: ERROR (2005-08-19) 22:07.48:909 [cocoon.manager.fop] (Unknown-URI) Unknown-Thread/MessageHandler: unknown font sans,normal,normal so defaulted font to any Seems to appear very often. I did a bit of investigation, and most of then comes from this style sheet: main/webapp/skins/common/xslt/fo/document2fo.xsl If you comment out xsl:template match=section mode=toc some out these errors disapear -- 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: [Vote] deprecated seed (was Re: svn commit: r231130)
Thorsten Scherler wrote: On Tue, 2005-08-09 at 22:55 +, [EMAIL PROTECTED] wrote: Author: thorsten Date: Tue Aug 9 15:54:59 2005 New Revision: 231130 URL: http://svn.apache.org/viewcvs?rev=231130view=rev Log: Added new seed targets seed-basic and seed-sample. That closes FOR-253. We should call a official vote that 'seed' is deprecated. http://issues.apache.org/jira/browse/FOR-253 There are some more mails around that topic in the archive. Here my +1 to deprecated the seed target and use seed-sample instead. -0 you have to type more... would not be better to have seed and skeletor or something else? I do not see much benefict on removing seed just for fun. If you want a seed without sample then seed-nosamples would do.. Cheers, cheche
Re: svn commit: r230883 - /forrest/trunk/etc/cocoon_upgrade/build.xml
Thorsten Scherler wrote:
On Mon, 2005-08-08 at 20:40 +, [EMAIL PROTECTED] wrote:
Author: cheche
Date: Mon Aug 8 13:40:42 2005
New Revision: 230883
URL: http://svn.apache.org/viewcvs?rev=230883view=rev
Log:
update info and cocoon tag
...
=== --
copy todir=${forrest.home}/lib/core
fileset dir=${cocoon.home}/lib/core defaultexcludes=yes
+!-- FIXME: why jxpath upgrade has to be ignored?? --
exclude name=commons-jxpath-*.jar/
since the update I get:
Caused by: java.lang.Exception: Cannot find class
org.apache.cocoon.generation.JXTemplateGenerator for component at
file:/home/thorsten/apache/forrest-trunk/build/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml/output.xmap:35:175
I commented it out because ATM it is not used, anyway we need JX*. Any
ideas what the problem is that Cheche is pointing out with the FIXME
note?
It was a problem with a version of JXpath and the site: links
Re: Reducing Forrest build time
Thorsten Scherler wrote: On Tue, 2005-08-09 at 10:23 +0200, Juan Jose Pablos wrote: Diwaker Gupta wrote: As Forrest grows and becomes more complex, we really have to watch out for the build times, and think of ways to reduce the build time. I was doing a build today of site-author, and it took ** 35 minutes ** I notice as well that the core.log goes huge, this is from the freshsite: [EMAIL PROTECTED]:/var/tmp/fs/build/webapp/WEB-INF/logs$ du -sh core.log 123Mcore.log Yes, I think that it was deployed with DEBUG on. I have just commited a version with debug=off. but I do not see huge benefics... just around 6% improved. please test. Cheers, cheche
Re: Reducing Forrest build time
Gav wrote: . | | We cannot just upgrade our version of Cocoon | trunk and expect everything to be the same. | One of us needs to investigate the Cocoon changes. | | -David I don't know the full ins and outs of these Apache Projects, but shouldn't there be maybe people dedicated to bridging the gaps between projects. Or at least someone who knows Cocoon working on Forrest and vice-versa. This may seem as asking someone to do two jobs and work on two projects, but what I mean is someone (x?) to work purely on crossover issues. Maybe somebody is already doing this. you need to give time to people to work on issues we do not have dedicated people. We have voluters :-) By the way, I found the problem with the performance, I will commit later today... Cheers, cheche
Component for key not found.
Hi, Can anyone tell me if you know what this warning message means? WARN(2005-08-09) 10:21.34:173 [cocoon.manager] (Unknown-URI) Unknown-Thread/CoreServiceManager: ComponentLocator exception from parent SM during lookup. org.apache.avalon.framework.service.ServiceException: Component for key 'org.apache.excalibur.source.SourceFactory/file' not found. (Key='Cocoon') Cheers, cheche
Re: [Fwd: Re: Cocoon stack traces]
Thorsten Scherler wrote: and till now only committed to BRANCH_2_1_X: Author: sylvain Date: Mon Aug 1 09:52:50 2005 New Revision: 226838 URL: http://svn.apache.org/viewcvs?rev=226838view=rev Log: Yeah! Real exceptions with Xalan rather than a useless RuntimeException! Modified: cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/transformation/TraxTransformer.java cocoon/branches/BRANCH_2_1_X/status.xml ... hum... that explain why I could not see a change on the trunk. Maybe you should drop Sylvain a line. It could be a mistake. ( I should take you the honor of the discovery :-) ) Cheers, cheche
Re: svn commit: r226552 - in /forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.voice/src/documentation/content/xdocs: index.xml site.xml
[EMAIL PROTECTED] wrote: + warningOpera with Voice is currently not available for Linux./warning There is not any alternative for linux users? Cheers, cheche
[jira] Assigned: (FOR-578) i18n working only for menus/tabs, not document
[ http://issues.apache.org/jira/browse/FOR-578?page=all ] Juan Jose Pablos reassigned FOR-578: Assign To: Juan Jose Pablos i18n working only for menus/tabs, not document -- Key: FOR-578 URL: http://issues.apache.org/jira/browse/FOR-578 Project: Forrest Type: Bug Components: Core operations Versions: 0.7 Environment: MacOS X 10.4.2, Java 1.4.2 Reporter: Sjur N. Moshagen Assignee: Juan Jose Pablos Here's the steps I took: - Installed Forrest 0.7 - seeded a new project - turned on i18n in forrest.properties - added index_es.xml and index_en.xml (besides the existing index.xml) - started forrest (forrest run) - configured FireFox to have 'es' as first language - opened the newly seeded and i18n-ed site Result: menus and tabs are in 'es', but the index page served is coming from index.xml. Expected result: the page served should be the 'es' version, to adhere to the requested locale -- 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] Assigned: (FOR-580) Default language in forrest.properties
[ http://issues.apache.org/jira/browse/FOR-580?page=all ] Juan Jose Pablos reassigned FOR-580: Assign To: Juan Jose Pablos Default language in forrest.properties -- Key: FOR-580 URL: http://issues.apache.org/jira/browse/FOR-580 Project: Forrest Type: New Feature Components: Core operations Versions: 0.8-dev Reporter: Sjur N. Moshagen Assignee: Juan Jose Pablos When developing a multilingual site, it would be beneficial if the default/fallback language could be configured from forrest.properties. This would imply that, given 'no' as fallback, one of the following two scenarios would be true: 1) files: index.xml, index_es.xml, index_en.xml Requests for both index.html and index_no.html would generate the returned page from index.xml 2) files: index_no.xml, index_es.xml, index_en.xml Requests for both index.html and index_no.html would generate the returned page from index_no.xml In both cases the end result would be that there would be no need to maintain more than one file for the fallback language. I would prefer the second alternative just for the sake of symmetry and equality of languages. It has the additional benefit of making it very easy to change the default/fallback language - just change the forrest.properties setting. The second alternative would also make it easier to create a language override menu, as all the available languages/locales would be encoded explicitly in the file name. -- 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] Commented: (FOR-580) Default language in forrest.properties
[ http://issues.apache.org/jira/browse/FOR-580?page=comments#action_12316266 ] Juan Jose Pablos commented on FOR-580: -- I feel that a filename without any language extension is right for a default language. WDYT? Default language in forrest.properties -- Key: FOR-580 URL: http://issues.apache.org/jira/browse/FOR-580 Project: Forrest Type: New Feature Components: Core operations Versions: 0.8-dev Reporter: Sjur N. Moshagen Assignee: Juan Jose Pablos When developing a multilingual site, it would be beneficial if the default/fallback language could be configured from forrest.properties. This would imply that, given 'no' as fallback, one of the following two scenarios would be true: 1) files: index.xml, index_es.xml, index_en.xml Requests for both index.html and index_no.html would generate the returned page from index.xml 2) files: index_no.xml, index_es.xml, index_en.xml Requests for both index.html and index_no.html would generate the returned page from index_no.xml In both cases the end result would be that there would be no need to maintain more than one file for the fallback language. I would prefer the second alternative just for the sake of symmetry and equality of languages. It has the additional benefit of making it very easy to change the default/fallback language - just change the forrest.properties setting. The second alternative would also make it easier to create a language override menu, as all the available languages/locales would be encoded explicitly in the file name. -- 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] Assigned: (FOR-579) Language override menu
[ http://issues.apache.org/jira/browse/FOR-579?page=all ] Juan Jose Pablos reassigned FOR-579: Assign To: Juan Jose Pablos Language override menu -- Key: FOR-579 URL: http://issues.apache.org/jira/browse/FOR-579 Project: Forrest Type: New Feature Components: Core operations Versions: 0.8-dev Reporter: Sjur N. Moshagen Assignee: Juan Jose Pablos The present i18n features of Forrest is a good start, but to be really useful there has to be a way to present the available language variants of a page/site to readers to choose from. To be as flexible as possible, this menu should be generated pr document, and should reflect the available language variants of that document (this as opposed to a fixed set of available languages for the whole site). That is, given the following documents, the corresponding language override menus should be generated: index_es.xml index_en.xml index_no.xml index_se.xml should give the menu: Spanish (es) English (en) Norwegian (no) North Sámi (se) whereas the following document list: index2_es.xml index2_no.xml index2_se.xml should give the menu: Spanish (es) Norwegian (no) North Sámi (se) In the best case the language of the displayed document should be highlighted and unavailable for selection. The location and display of this menu should be configurable from skinconf.xml. I would sugggest the following defaults: Location: same bar as the document track, but on the right end of that bar Display: as a list of language links (that is, the default should not be a popup menu, although that could of course be a skin/skinconf alternative) -- 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: [i18n] again...
Cyriaque Dupoirieux wrote: I'm really sorry to ask the question but I cannot retrieve the answer in the archive. How can I change the language of the static site using i18n ? I tried to set -Duser.language=fr in the ant call, and it's Ok for the folder structure : site/fr/... But my labels are still in English (ie: Search button is called Search...) My problem is that i am not able to reproduce your problem in my laptop. I will try to test it on another computer and i will report it back. I am using: [EMAIL PROTECTED]:/var/tmp/fs$ java -version java version 1.4.2_04 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode)
[jira] Updated: (FOR-394) html2document.xsl misses content before first h1 element
[ http://issues.apache.org/jira/browse/FOR-394?page=all ] Juan Jose Pablos updated FOR-394: - Component: Skins (general issues) Environment: html2document.xsl misses content before first h1 element Key: FOR-394 URL: http://issues.apache.org/jira/browse/FOR-394 Project: Forrest Type: Bug Components: Skins (general issues) Versions: 0.7-dev Reporter: Ross Gardler Priority: Minor Fix For: 0.8 The html2document.xsl stylesheet does not transform content that precedes the first H1 element. -- 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] Updated: (FOR-365) Allow for different Top-of-page-images depending on selected tab
[ http://issues.apache.org/jira/browse/FOR-365?page=all ] Juan Jose Pablos updated FOR-365: - Component: Skins (general issues) Description: I'd like to have different images at the top of my pages, depending on the tab or menu that is chosen. Example a serious looking photo on top of my business pages, a kayak at the top of my kayaking pages etc. was: I'd like to have different images at the top of my pages, depending on the tab or menu that is chosen. Example a serious looking photo on top of my business pages, a kayak at the top of my kayaking pages etc. Environment: Allow for different Top-of-page-images depending on selected tab Key: FOR-365 URL: http://issues.apache.org/jira/browse/FOR-365 Project: Forrest Type: New Feature Components: Skins (general issues) Reporter: Ferdinand Soethe Priority: Minor I'd like to have different images at the top of my pages, depending on the tab or menu that is chosen. Example a serious looking photo on top of my business pages, a kayak at the top of my kayaking pages etc. -- 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] Closed: (FOR-212) java.lang.NoSuchMethodError on Windows XP
[ http://issues.apache.org/jira/browse/FOR-212?page=all ] Juan Jose Pablos closed FOR-212: Resolution: Cannot Reproduce java.lang.NoSuchMethodError on Windows XP - Key: FOR-212 URL: http://issues.apache.org/jira/browse/FOR-212 Project: Forrest Type: Bug Components: XML grammars validation Versions: 0.5.1 Environment: Java SDK 1.4.1, Windows XP Reporter: Lukas Zapletal Priority: Minor I get many these error while building the site (static HTML) But it renders fine... It is just a cosmetic bug. java.lang.NoSuchMethodError: EDU.oswego.cs.dl.util.concurrent.LinkedNode: method init()V not found at EDU.oswego.cs.dl.util.concurrent.SynchronousChannel.take(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:534) -- 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: svn commit: r190796 - in /forrest/trunk: main/fresh-site/forrest.properties main/webapp/sitemap.xmap site-author/status.xml
David Crossley wrote:
Ross Gardler wrote:
Author: cheche
Date: Wed Jun 15 12:53:39 2005
New Revision: 190796
URL: http://svn.apache.org/viewcvs?rev=190796view=rev
Log:
Add a config selector so the i18n transformer only works whrn i18n is true
We are in a code freeze. This looks like a non-essential commit to me.
Should it be reverted?
I don't profess to know anything about i18n, but part of this commit
looks like a bugfix (skins/common/messages/ = /translations/).
The remainder looks like an efficiency issue, which might be relevant.
Please explain a bit more Cheche.
sure,
there are two issues:
1) (skins/common/messages/ = /translations/)
The new directory to keep the commomMessages_{language}.xml is under
skins/commons/translations so it the same as the project language files
that are under {project.home}/src/documentation/translations
2) I18nTransformer that was added for the skins messages did not check
if a i18n property was set to true, so in the case that you are building
a English site within a foreigner locale, then the messages would be
translated which is wrong.
Cheers,
cheche
Re: svn commit: r190796 - in /forrest/trunk: main/fresh-site/forrest.properties main/webapp/sitemap.xmap site-author/status.xml
Ross Gardler wrote: [EMAIL PROTECTED] wrote: Author: cheche Date: Wed Jun 15 12:53:39 2005 New Revision: 190796 URL: http://svn.apache.org/viewcvs?rev=190796view=rev Log: Add a config selector so the i18n transformer only works whrn i18n is true We are in a code freeze. This looks like a non-essential commit to me. It looks like a bugfix to me. :-) Should it be reverted? Unless you want to deploy broken funcionality, it should not been reverted.
Re: FOR 363
Dick Hollenbeck wrote: What are the issues that make fixing FOR 363 so difficult that it appears not be slated for fixing in the 0.7 release? Thanks, Dick Hollenbeck I personally think that this was not been review properly. yesterday I had moved all the issues with no components so they get better visibility. I have added a patch as well, it makes easier to understant the suggested fix. I would like others to have a look and vote if this change should be in the 0.7 release this is my +1 Cheers, cheche
[jira] Updated: (FOR-363) figure-elements within aggregated pdf-pages are not displayed
[ http://issues.apache.org/jira/browse/FOR-363?page=all ] Juan Jose Pablos updated FOR-363: - Attachment: for-363.patch Patch to allow other to review in a standard way. figure-elements within aggregated pdf-pages are not displayed --- Key: FOR-363 URL: http://issues.apache.org/jira/browse/FOR-363 Project: Forrest Type: Bug Components: Plugin: pdf-output Versions: 0.6 Environment: Linux Reporter: Stephan E. Schlierf Priority: Minor Attachments: for-363.patch With Forrest 0.6 I encountered a problem during the creation of a pdf-file that is aggregated from a group of documents: All my graphics are in project-dir]/src/documentation/resources/images (and its subdiretories). Now if I use figure-elements in these documents the graphics are not displayed in the aggregated pdf-file. If I use img-elements everything's ok. As far as I can see this problem is located in src/core/context/resources/stylesheets/aggregates/doc2doc-uniqueids.xsl: Around line 45 the follwoing template is defined: xsl:template match=section/document//figure|img[starts-with(@src, 'my-images')] !-- fix my-images/** links, which break as they are not relative to the site root -- ... /xsl:template If you change the match condition to match=section/document//figure[starts-with(@src, 'my-images')]| img[starts-with(@src, 'my-images')] even the figure-elements are displayed. -- 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: [Testing 0.7rc1] Possible troubles with simplified-docbook plugin
Ross Gardler wrote: Ron Blaschke wrote: My current guess is that the name simplified-docbook collides with the versioned plugins naming, so that docbook is interpreted as a version number, and there is no plugin simplified. That is correct. In fact I added a warning to the docs saying plugin names cannot have a hyphen. It never occured to me that the simplified-docbook has a hyphen in it. Doh! should we change that to sdocbook ?
Re: [Testing 0.7rc1] Possible troubles with simplified-docbook plugin
Ross Gardler wrote: Ron Blaschke wrote: My current guess is that the name simplified-docbook collides with the versioned plugins naming, so that docbook is interpreted as a version number, and there is no plugin simplified. That is correct. In fact I added a warning to the docs saying plugin names cannot have a hyphen. It never occured to me that the simplified-docbook has a hyphen in it. Doh! should be change that to sdocbook ?
Re: FOR 363
Ross Gardler wrote: There is a typo in the patch: match=section/document//figure[starts-with(@src, 'my-images')]|img[starts-with(@src, 'my-images')] . /|\ | fixed thanks! I've not tested the solution, but it looks sensible. if no one has other objection i will apply it tonight. Cheers, cheche
Re: [Testing 0.7rc1] Possible troubles with simplified-docbook plugin
Ross Gardler wrote: Juan Jose Pablos wrote: Ross Gardler wrote: Ron Blaschke wrote: My current guess is that the name simplified-docbook collides with the versioned plugins naming, so that docbook is interpreted as a version number, and there is no plugin simplified. That is correct. In fact I added a warning to the docs saying plugin names cannot have a hyphen. It never occured to me that the simplified-docbook has a hyphen in it. Doh! should we change that to sdocbook ? I just changed to simplifiedDocbook, hope that is OK with everyone. well, sdocbook is shorter and that is used already on the stylesheet: sdocbook2document.xsl I've redeployed the plugin and plugins.xml file so that 'forrest availablePlugins' reports the correct name.
[jira] Updated: (FOR-363) figure-elements within aggregated pdf-pages are not displayed
[ http://issues.apache.org/jira/browse/FOR-363?page=all ] Juan Jose Pablos updated FOR-363: - Attachment: for-363.patch added proper patch. figure-elements within aggregated pdf-pages are not displayed --- Key: FOR-363 URL: http://issues.apache.org/jira/browse/FOR-363 Project: Forrest Type: Bug Components: Plugin: pdf-output Versions: 0.6 Environment: Linux Reporter: Stephan E. Schlierf Priority: Minor Attachments: for-363.patch With Forrest 0.6 I encountered a problem during the creation of a pdf-file that is aggregated from a group of documents: All my graphics are in project-dir]/src/documentation/resources/images (and its subdiretories). Now if I use figure-elements in these documents the graphics are not displayed in the aggregated pdf-file. If I use img-elements everything's ok. As far as I can see this problem is located in src/core/context/resources/stylesheets/aggregates/doc2doc-uniqueids.xsl: Around line 45 the follwoing template is defined: xsl:template match=section/document//figure|img[starts-with(@src, 'my-images')] !-- fix my-images/** links, which break as they are not relative to the site root -- ... /xsl:template If you change the match condition to match=section/document//figure[starts-with(@src, 'my-images')]| img[starts-with(@src, 'my-images')] even the figure-elements are displayed. -- 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] Commented: (FOR-32) Generating content pages with non .html extensions
[ http://issues.apache.org/jira/browse/FOR-32?page=comments#action_12313744 ] Juan Jose Pablos commented on FOR-32: - There is a way to append another extension using cli.xconf add this uri type=insert src-prefix= src=index.html follow-links=false dest=/var/tmp/fs/build/*.php / the output would be something like /var/tmp/build/index.html.php Generating content pages with non .html extensions -- Key: FOR-32 URL: http://issues.apache.org/jira/browse/FOR-32 Project: Forrest Type: Improvement Components: Skins (general issues) Versions: 0.4 Environment: any Reporter: Brill Pappin I would really (really, really) like to be able to tell forest what file extension to use during output. In my case, I want to use forrest to define the structure of a site... however I want it to output JSP files. I've tried just doing it and of course it did't work. The optimal thing would be to add a stylesheet for JSP, so you could create the site as a JSP site, and have forrest output it... however I don't have the time (for this project anyway) to write up the stylesheets (I'd have to learn xsl as well, which would not be quick task). Just an enhancement... in my case not having it prevents me from using forrest (this time; I'm rather sad about that), but I see a future version where I can use it to make life easier. -- 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] Assigned: (FOR-215) site.lucene name colaps with site.html request
[ http://issues.apache.org/jira/browse/FOR-215?page=all ] Juan Jose Pablos reassigned FOR-215: Assign To: Juan Jose Pablos (was: Juan Jose Pablos) site.lucene name colaps with site.html request -- Key: FOR-215 URL: http://issues.apache.org/jira/browse/FOR-215 Project: Forrest Type: Bug Components: Launch 'forrest run' Versions: 0.6 Reporter: Juan Jose Pablos Assignee: Juan Jose Pablos Fix For: 0.8 Attachments: index-creation.patch Any link called site.html or site.pdf produce a loop on the search funcionality. The reason is an internal request called cocoon://site.lucene a work around would be to choose another name for this internal request. But this means that a request called /index-creation.html would have the same problem. -- 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] Updated: (FOR-318) match db anchor to a element with @id
[ http://issues.apache.org/jira/browse/FOR-318?page=all ] Juan Jose Pablos updated FOR-318: - Component: Plugin: Simplified Docbook (was: Core operations) Description: From Docbook TDG An anchor identifies a single spot in the content. This may serve as the target for a cross reference, for example, from a Link. The Anchor element may occur almost anywhere. was: From Docbook TDG An anchor identifies a single spot in the content. This may serve as the target for a cross reference, for example, from a Link. The Anchor element may occur almost anywhere. Environment: belongs to docbook match db anchor to a element with @id - Key: FOR-318 URL: http://issues.apache.org/jira/browse/FOR-318 Project: Forrest Type: Bug Components: Plugin: Simplified Docbook Versions: 0.6 Reporter: Sean Wheller Priority: Trivial Attachments: db-article.xml, docbook2document.xsl.diff From Docbook TDG An anchor identifies a single spot in the content. This may serve as the target for a cross reference, for example, from a Link. The Anchor element may occur almost anywhere. -- 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] Updated: (FOR-480) The Cocoon cli.xconf generates its extra documents into main/site/
[ http://issues.apache.org/jira/browse/FOR-480?page=all ] Juan Jose Pablos updated FOR-480: - Component: Launch 'forrest' Description: Extra URIs (additional to those in site.xml) can be processed by declaring them in a project-based conf/cli.xconf However, the final documents are not being generated into build/site/ but instead are going into main/site/ was: Extra URIs (additional to those in site.xml) can be processed by declaring them in a project-based conf/cli.xconf However, the final documents are not being generated into build/site/ but instead are going into main/site/ Environment: The Cocoon cli.xconf generates its extra documents into main/site/ -- Key: FOR-480 URL: http://issues.apache.org/jira/browse/FOR-480 Project: Forrest Type: Bug Components: Launch 'forrest' Versions: 0.6, 0.7-dev Reporter: David Crossley Priority: Minor Fix For: 0.8 Extra URIs (additional to those in site.xml) can be processed by declaring them in a project-based conf/cli.xconf However, the final documents are not being generated into build/site/ but instead are going into main/site/ -- 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] Updated: (FOR-423) Forrest crashes without an xdoc/index.xml file
[ http://issues.apache.org/jira/browse/FOR-423?page=all ] Juan Jose Pablos updated FOR-423: - Component: Core operations Description: Forrest (Head, revision 125624) seems to assume there's an index.xml file in the xdoc root directory. Without this file, Forrest throws a nasty Java exception shown below; however, the site seems to render correctly. Additionally, in brokenlinks, there's this message that I cannot find a reference for: cocoon://index.html. To reproduce this error, seed a fresh project, rename index.xml, and then update site.xml tab.xml and all other references to index.html accordingly. An easy workaround is to include a dummy index.xml file, which stops the exception. But, I'm not sure if there's some undiscovered side-effect. For additional information, please see User thread Forrest crashes without an xdoc/index.xml file org.apache.cocoon.CascadingIOException: SourceException: org.apache.excalibur.source.SourceException: Exception during processing of cocoon://index.html: org.apache.excalibur.source.SourceException: Exception during processing of cocoon://index.html at org.apache.cocoon.environment.commandline.AbstractCommandLineEnvironment.redirect(AbstractCommandLineEnvironment.java:124) at org.apache.cocoon.environment.ForwardRedirector.doRedirect(ForwardRedirector.java:158) at org.apache.cocoon.environment.ForwardRedirector.redirect(ForwardRedirector.java:64) was: Forrest (Head, revision 125624) seems to assume there's an index.xml file in the xdoc root directory. Without this file, Forrest throws a nasty Java exception shown below; however, the site seems to render correctly. Additionally, in brokenlinks, there's this message that I cannot find a reference for: cocoon://index.html. To reproduce this error, seed a fresh project, rename index.xml, and then update site.xml tab.xml and all other references to index.html accordingly. An easy workaround is to include a dummy index.xml file, which stops the exception. But, I'm not sure if there's some undiscovered side-effect. For additional information, please see User thread Forrest crashes without an xdoc/index.xml file org.apache.cocoon.CascadingIOException: SourceException: org.apache.excalibur.source.SourceException: Exception during processing of cocoon://index.html: org.apache.excalibur.source.SourceException: Exception during processing of cocoon://index.html at org.apache.cocoon.environment.commandline.AbstractCommandLineEnvironment.redirect(AbstractCommandLineEnvironment.java:124) at org.apache.cocoon.environment.ForwardRedirector.doRedirect(ForwardRedirector.java:158) at org.apache.cocoon.environment.ForwardRedirector.redirect(ForwardRedirector.java:64) Forrest crashes without an xdoc/index.xml file -- Key: FOR-423 URL: http://issues.apache.org/jira/browse/FOR-423 Project: Forrest Type: Bug Components: Core operations Versions: 0.7-dev Environment: WinXP generating static site. Reporter: Greg Jenci Priority: Minor Forrest (Head, revision 125624) seems to assume there's an index.xml file in the xdoc root directory. Without this file, Forrest throws a nasty Java exception shown below; however, the site seems to render correctly. Additionally, in brokenlinks, there's this message that I cannot find a reference for: cocoon://index.html. To reproduce this error, seed a fresh project, rename index.xml, and then update site.xml tab.xml and all other references to index.html accordingly. An easy workaround is to include a dummy index.xml file, which stops the exception. But, I'm not sure if there's some undiscovered side-effect. For additional information, please see User thread Forrest crashes without an xdoc/index.xml file org.apache.cocoon.CascadingIOException: SourceException: org.apache.excalibur.source.SourceException: Exception during processing of cocoon://index.html: org.apache.excalibur.source.SourceException: Exception during processing of cocoon://index.html at org.apache.cocoon.environment.commandline.AbstractCommandLineEnvironment.redirect(AbstractCommandLineEnvironment.java:124) at org.apache.cocoon.environment.ForwardRedirector.doRedirect(ForwardRedirector.java:158) at org.apache.cocoon.environment.ForwardRedirector.redirect(ForwardRedirector.java:64) -- 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] Updated: (FOR-261) no external-link icons when group-url=
[ http://issues.apache.org/jira/browse/FOR-261?page=all ] Juan Jose Pablos updated FOR-261: - Component: Core operations no external-link icons when group-url= Key: FOR-261 URL: http://issues.apache.org/jira/browse/FOR-261 Project: Forrest Type: Bug Components: Core operations Versions: 0.6 Environment: all Reporter: Johannes Schaefer Priority: Minor When setting group-url in skinconf.xml to (empty string) or deleting it at all (!-- ... --) the icons after the external links are no longer displayed (although disable-external-link-image=false). group-url= suffices to show them again. -- 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] Updated: (FOR-180) Update forrestbar to be installablein Mozilla Firefox 0.9
[ http://issues.apache.org/jira/browse/FOR-180?page=all ] Juan Jose Pablos updated FOR-180: - Component: Forrestbar Update forrestbar to be installablein Mozilla Firefox 0.9 - Key: FOR-180 URL: http://issues.apache.org/jira/browse/FOR-180 Project: Forrest Type: Bug Components: Forrestbar Environment: Mozilla Firefox 0.9 Reporter: Nicola Ken Barozzi Assignee: Nicola Ken Barozzi Priority: Minor Firefox 0.9 will get a new extension install system, with which we must be compatible to be usable there. Being listed in the standard toolbars could be cool too. -- 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] Updated: (FOR-353) build target expand-dtd is broken: perhaps incompatible nekodtd and xerces
[ http://issues.apache.org/jira/browse/FOR-353?page=all ] Juan Jose Pablos updated FOR-353: - Component: Plugins (general issues) Description: -- BUILD FAILED /usr/local/svn/forrest/main/build.xml:325: taskdef class org.cyberneko.dtd.anttasks.DTD2XML cannot be found -- In forrest.build.xml The taskdef points to the class org.cyberneko.dtd.anttasks.DTD2XML, whereas in the nekodtd-0.1.10.jar located in lib\core the DTD2XML class seems to be in the org.cyberneko.dtd.ant package. However, changing that to org.cyberneko.dtd.ant.DTD2XML causes other errors to show for each DTD that is processed ... -- Exception in thread main java.lang.NoClassDefFoundError: org/apache/xerces/util/ObjectFactory at xni.Writer.main(Unknown Source) -- Thanks to Arik Kfir for reporting the issue. was: -- BUILD FAILED /usr/local/svn/forrest/main/build.xml:325: taskdef class org.cyberneko.dtd.anttasks.DTD2XML cannot be found -- In forrest.build.xml The taskdef points to the class org.cyberneko.dtd.anttasks.DTD2XML, whereas in the nekodtd-0.1.10.jar located in lib\core the DTD2XML class seems to be in the org.cyberneko.dtd.ant package. However, changing that to org.cyberneko.dtd.ant.DTD2XML causes other errors to show for each DTD that is processed ... -- Exception in thread main java.lang.NoClassDefFoundError: org/apache/xerces/util/ObjectFactory at xni.Writer.main(Unknown Source) -- Thanks to Arik Kfir for reporting the issue. Environment: i can not find the dtd plugin build target expand-dtd is broken: perhaps incompatible nekodtd and xerces Key: FOR-353 URL: http://issues.apache.org/jira/browse/FOR-353 Project: Forrest Type: Bug Components: Plugins (general issues) Versions: 0.7-dev Reporter: David Crossley Priority: Minor -- BUILD FAILED /usr/local/svn/forrest/main/build.xml:325: taskdef class org.cyberneko.dtd.anttasks.DTD2XML cannot be found -- In forrest.build.xml The taskdef points to the class org.cyberneko.dtd.anttasks.DTD2XML, whereas in the nekodtd-0.1.10.jar located in lib\core the DTD2XML class seems to be in the org.cyberneko.dtd.ant package. However, changing that to org.cyberneko.dtd.ant.DTD2XML causes other errors to show for each DTD that is processed ... -- Exception in thread main java.lang.NoClassDefFoundError: org/apache/xerces/util/ObjectFactory at xni.Writer.main(Unknown Source) -- Thanks to Arik Kfir for reporting the issue. -- 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] Updated: (FOR-528) Add version control to plugins
[ http://issues.apache.org/jira/browse/FOR-528?page=all ] Juan Jose Pablos updated FOR-528: - Component: Plugins (general issues) Add version control to plugins -- Key: FOR-528 URL: http://issues.apache.org/jira/browse/FOR-528 Project: Forrest Type: Test Components: Plugins (general issues) Versions: 0.7-dev Reporter: Ross Gardler Assignee: Ross Gardler Priority: Blocker Fix For: 0.7-dev David Crossley wrote: Ross, are you able to explain what needs to happen with the plugins at release-time. I mean do they all need to have -0.7 appended to the names of the zip files? Blast I forgot that entirely (again!). Yes we need two zipped versions, a pluginname-0.7.zip and a pluginname-0.8-dev.zip The system will then download the correct version for the currently installed version of Forrest. This will allow us to have a separate release cycle for plugins, if we deploy from a 0.8-dev version of Forrest then we will have the 0.8-dev zip file. However, now I write that down I don't like it because there is no distinction between a 0.1 version of a plugin for Forrest 0.7 and a 1.0 version of a plugin for Forrest 1.0 (for example) How about I change it to put the plugins in a directory so we have: 0.7/plugingOne-0.1.zip 0.7/plugingTwo-0.2.zip 0.8-dev/pluginOne-0.2-dev.zip 0.8-dev/plugingTwo-0.2.zip We only allow *-dev plugins in the current *-dev branch of Forrest We can worry about the release process for plugins after this release (just get them out there for 0.7, we can blow the trumpet on subsequent upgrade releases) Do we need to add something to our RELEASE_BOTES.txt file? Yes, a section on plugins with a link to the plugins page, I'll add to project-info plugin Does someone need to tweak the build file? Yes, leave it with me, I'll implement the above with whatever modifications people think we need. Ross (for follow ups see http://marc.theaimsgroup.com/?l=forrest-devm=111821546807300w=2 -- 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] Updated: (FOR-505) Allow the retrieval of raw html files
[ http://issues.apache.org/jira/browse/FOR-505?page=all ] Juan Jose Pablos updated FOR-505: - Component: Core operations Description: With the merging of the raw content directory and the xdocs directory it is no longer possible to retrieve the raw, unprocessed version of an HTML file. The raw HTML files were removed from the fresh-site in revision 178279. When we have added support for raw HTML files back into the system we should revive these files as a demo. was: With the merging of the raw content directory and the xdocs directory it is no longer possible to retrieve the raw, unprocessed version of an HTML file. The raw HTML files were removed from the fresh-site in revision 178279. When we have added support for raw HTML files back into the system we should revive these files as a demo. Environment: Allow the retrieval of raw html files - Key: FOR-505 URL: http://issues.apache.org/jira/browse/FOR-505 Project: Forrest Type: Improvement Components: Core operations Versions: 0.7-dev Reporter: Ross Gardler Assignee: Ross Gardler Priority: Minor Fix For: 0.7-dev With the merging of the raw content directory and the xdocs directory it is no longer possible to retrieve the raw, unprocessed version of an HTML file. The raw HTML files were removed from the fresh-site in revision 178279. When we have added support for raw HTML files back into the system we should revive these files as a demo. -- 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] Updated: (FOR-150) whole_site_html/pdf create needless heading at end of doc
[ http://issues.apache.org/jira/browse/FOR-150?page=all ] Juan Jose Pablos updated FOR-150: - Component: Skins (general issues) Environment: whole_site_html/pdf create needless heading at end of doc - Key: FOR-150 URL: http://issues.apache.org/jira/browse/FOR-150 Project: Forrest Type: Bug Components: Skins (general issues) Versions: 0.6 Reporter: Armin Waibel Priority: Minor The whole_site_html/pdf task create needless heading All at end of doc -- 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] Closed: (FOR-153) Removing unneed Jar on forrest distribution.
[ http://issues.apache.org/jira/browse/FOR-153?page=all ] Juan Jose Pablos closed FOR-153: Resolution: Fixed as far as I can see all the setup created on the etc/cocoon_upgrade/build.xml seems to works and not extra jar comes from that side. Removing unneed Jar on forrest distribution. Key: FOR-153 URL: http://issues.apache.org/jira/browse/FOR-153 Project: Forrest Type: Task Components: Compile Reporter: Juan Jose Pablos Assignee: Juan Jose Pablos There are 71 Jar on our distribution. I am not 100% sure that all these jar are needed. -- 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] Updated: (FOR-200) Locationmap for Forrest and Users
[ http://issues.apache.org/jira/browse/FOR-200?page=all ] Juan Jose Pablos updated FOR-200: - Component: Locationmap Description: The locationmap gives us the ability to specify where sources are, both for Forrest and for the users. Beware that it will not work for raw files that are not linked, as this feature currently uses a fixed dir being being copied by Ant. was: The locationmap gives us the ability to specify where sources are, both for Forrest and for the users. Beware that it will not work for raw files that are not linked, as this feature currently uses a fixed dir being being copied by Ant. Environment: Locationmap for Forrest and Users - Key: FOR-200 URL: http://issues.apache.org/jira/browse/FOR-200 Project: Forrest Type: New Feature Components: Locationmap Reporter: Nicola Ken Barozzi Fix For: 0.9 Attachments: for-200-resources.patch, lm_branch_patch.patch The locationmap gives us the ability to specify where sources are, both for Forrest and for the users. Beware that it will not work for raw files that are not linked, as this feature currently uses a fixed dir being being copied by Ant. -- 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] Updated: (FOR-278) Extend the forrest webapp with lenya functionality or vice versa
[ http://issues.apache.org/jira/browse/FOR-278?page=all ] Juan Jose Pablos updated FOR-278: - Component: Tools (general issues) Description: Link: http://marc.theaimsgroup.com/?l=forrest-devm=109411643128812w=2 +-lenya should be integrated into forrest or vice versa. That makes it possible to edit the content in a WYSWYG editor! Again writing in tags can not be our aim! Lenya should take care of creating new, editing and archiving existing content. Namly site.xml, tab.xml and all other xdocs. With lenya we have as well workflow! was: Link: http://marc.theaimsgroup.com/?l=forrest-devm=109411643128812w=2 +-lenya should be integrated into forrest or vice versa. That makes it possible to edit the content in a WYSWYG editor! Again writing in tags can not be our aim! Lenya should take care of creating new, editing and archiving existing content. Namly site.xml, tab.xml and all other xdocs. With lenya we have as well workflow! Environment: Extend the forrest webapp with lenya functionality or vice versa -- Key: FOR-278 URL: http://issues.apache.org/jira/browse/FOR-278 Project: Forrest Type: New Feature Components: Tools (general issues) Versions: 0.7-dev Reporter: Thorsten Scherler Link: http://marc.theaimsgroup.com/?l=forrest-devm=109411643128812w=2 +-lenya should be integrated into forrest or vice versa. That makes it possible to edit the content in a WYSWYG editor! Again writing in tags can not be our aim! Lenya should take care of creating new, editing and archiving existing content. Namly site.xml, tab.xml and all other xdocs. With lenya we have as well workflow! -- 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] Closed: (FOR-18) support multiple languages (i18n)
[ http://issues.apache.org/jira/browse/FOR-18?page=all ] Juan Jose Pablos closed FOR-18: --- Fix Version: 0.7-dev Resolution: Fixed Close this issue as forrest has i18n support. most of the information reflected here is not longer to do with the resolution of this issue. support multiple languages (i18n) - Key: FOR-18 URL: http://issues.apache.org/jira/browse/FOR-18 Project: Forrest Type: New Feature Components: Core operations Reporter: Ralf Hauser Assignee: Juan Jose Pablos Priority: Critical Fix For: 0.7-dev Attachments: multLang.zip In my current environment to develop static mulitlingual web-sites, I use an ant build.xml and the m4 macro preprocessor to achieve the following (sample): 1) index.en.m4 gets converted to index.en.html The *.en.m4 contains all language dependent text (similarly *.de.m4 for German) and includes index.m4 that contains the page's content layout. [(^\.)+].m4 includes sitedef.m4 where I define all global parts of the website (e.g. navigation structure, unique content e.g. phone numbers, filenames, etc.). This in turn includes a sitedefs.en or sitedef.de, ... respectively for global, language dependent definitions. 2) Dependencies a) upon change of [(^\.)+].m4, all depending *.*LANG*.html get rebuilt b) upon change of sitedef.m4, build.xml, and alike all *.html gets rebuilt c) upon change of sitedefs.en all *.en.html get rebuilt. Obviously, I could use the exact same approach to create .xml whereever I created .html before, but my long-term goal is to get rid of m4. Has anybody already put some thought into how this would be done with forrest? -- 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] Updated: (FOR-383) Always opens a new browser instance
[ http://issues.apache.org/jira/browse/FOR-383?page=all ] Juan Jose Pablos updated FOR-383: - Component: Tool: Eclipse config Environment: Always opens a new browser instance --- Key: FOR-383 URL: http://issues.apache.org/jira/browse/FOR-383 Project: Forrest Type: Bug Components: Tool: Eclipse config Versions: 0.7-dev Reporter: Ross Gardler Priority: Minor When starting Forrest using the Eclipse plugin a new browser window is opened even if there is already one present within the current instance of Eclipse. We should re-use the browser. -- 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] Assigned: (FOR-15) supporting xhtml/css (as per validator.w3.org) in project directory tree
[ http://issues.apache.org/jira/browse/FOR-15?page=all ] Juan Jose Pablos reassigned FOR-15: --- Assign To: Juan Jose Pablos supporting xhtml/css (as per validator.w3.org) in project directory tree Key: FOR-15 URL: http://issues.apache.org/jira/browse/FOR-15 Project: Forrest Type: New Feature Components: Core operations Versions: 0.6 Reporter: Ralf Hauser Assignee: Juan Jose Pablos Fix For: 0.8 Attachments: valid-xhtml.diff, xhtmlSupport.zip In order to use the w3c.org sanity checks on xhtml11 and css2, I need html files to start with: ?xml version=1.0 encoding=iso-8859-1? !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en head ... The only place I found a reference to HTML 4.01 Transitional//EN... in the myproject directory tree was in build\tmp\context\sitemap.xmap which had no effect. 1) I had to change it in xml-forrest\build\dist\shbat\context\sitemap.xmap which doesn't appear to be the right place to me. 2) In which file would I have to change DOCTYPE HTML PUBLIC to DOCTYPE html PUBLIC? 3) Where would I change META to meta? XHTML doesn't like caps. 4) The end tags need to be ` /` instead of `` where would one change that? 5) Where would I change the margin attributes of the body tag? 6) Where would I change the attributes of the td tag? etc., etc. -- 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] Updated: (FOR-263) docbook anchor does not produce correct output
[ http://issues.apache.org/jira/browse/FOR-263?page=all ] Juan Jose Pablos updated FOR-263: - Component: Plugin: Simplified Docbook (was: Core operations) Description: Putting an anchor id=local_ref into a DocBook-XML doesn't get resolved properly. DocBook.XML anchor id=id000/ becomes HTML a href=/a and DocBook.XML anchor id=id000Test/anchor becomes HTML a name=Test/aa href=/a Note: anchor isn't a simplyfied DocBook element. But it is in DocBook. There is an entry in docbook2document.xsl for it, though, and anchors get transformed but not correctly. see http://issues.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1816784 was: Putting an anchor id=local_ref into a DocBook-XML doesn't get resolved properly. DocBook.XML anchor id=id000/ becomes HTML a href=/a and DocBook.XML anchor id=id000Test/anchor becomes HTML a name=Test/aa href=/a Note: anchor isn't a simplyfied DocBook element. But it is in DocBook. There is an entry in docbook2document.xsl for it, though, and anchors get transformed but not correctly. see http://issues.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1816784 At the moment Sdocbook and docbook use the same stylesheet. docbook anchor does not produce correct output Key: FOR-263 URL: http://issues.apache.org/jira/browse/FOR-263 Project: Forrest Type: Bug Components: Plugin: Simplified Docbook Versions: 0.6 Environment: all Reporter: Johannes Schaefer Priority: Minor Putting an anchor id=local_ref into a DocBook-XML doesn't get resolved properly. DocBook.XML anchor id=id000/ becomes HTML a href=/a and DocBook.XML anchor id=id000Test/anchor becomes HTML a name=Test/aa href=/a Note: anchor isn't a simplyfied DocBook element. But it is in DocBook. There is an entry in docbook2document.xsl for it, though, and anchors get transformed but not correctly. see http://issues.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1816784 -- 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] Updated: (FOR-169) Forrest-skin-bot
[ http://issues.apache.org/jira/browse/FOR-169?page=all ] Juan Jose Pablos updated FOR-169: - Component: Forrestbot Description: One suggestion (right now more a RT) would be to create a kind of forrestskinbot that can help manipulating the appearance of a site. It is just a thought right now. Main function would be to create (online - through a web app) a new skin for a site *without* touching *any code*! ...changing colours, placing logos, manipulate menu style, ... by filling out a form or manipulating a SVG. The forrestskinbot would then create the skin, package it, uploaded it to the server of the page, [maybe publish it to the forrest-skins.xml (after review by a committer this could be published for everyone)] and finally create the forrest.skins.descriptors entry in the local forrest.properties. ...afterwards that site could be even deployed and published on a server through the /normal/ forrestbot. was: One suggestion (right now more a RT) would be to create a kind of forrestskinbot that can help manipulating the appearance of a site. It is just a thought right now. Main function would be to create (online - through a web app) a new skin for a site *without* touching *any code*! ...changing colours, placing logos, manipulate menu style, ... by filling out a form or manipulating a SVG. The forrestskinbot would then create the skin, package it, uploaded it to the server of the page, [maybe publish it to the forrest-skins.xml (after review by a committer this could be published for everyone)] and finally create the forrest.skins.descriptors entry in the local forrest.properties. ...afterwards that site could be even deployed and published on a server through the /normal/ forrestbot. Environment: Forrest-skin-bot Key: FOR-169 URL: http://issues.apache.org/jira/browse/FOR-169 Project: Forrest Type: New Feature Components: Forrestbot Reporter: Thorsten Scherler Priority: Minor One suggestion (right now more a RT) would be to create a kind of forrestskinbot that can help manipulating the appearance of a site. It is just a thought right now. Main function would be to create (online - through a web app) a new skin for a site *without* touching *any code*! ...changing colours, placing logos, manipulate menu style, ... by filling out a form or manipulating a SVG. The forrestskinbot would then create the skin, package it, uploaded it to the server of the page, [maybe publish it to the forrest-skins.xml (after review by a committer this could be published for everyone)] and finally create the forrest.skins.descriptors entry in the local forrest.properties. ...afterwards that site could be even deployed and published on a server through the /normal/ forrestbot. -- 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] Updated: (FOR-535) Create a plugins task for ANT
[ http://issues.apache.org/jira/browse/FOR-535?page=all ] Juan Jose Pablos updated FOR-535: - Component: Plugins (general issues) Create a plugins task for ANT - Key: FOR-535 URL: http://issues.apache.org/jira/browse/FOR-535 Project: Forrest Type: Improvement Components: Plugins (general issues) Versions: 0.7-dev Reporter: Ross Gardler Priority: Minor Fix For: 0.8 The ant file for loading and mounting plugins is horribly complex now that we are using versioned plugins. I've used lots of if elements and mutable properties from the ant-contrib package. In my view when you overuse these tasks it generally means you should have a specialised ANT task to handle the logic. ANT is not supposed to be a programming language. We need to create an ANT task for the handling the installation of plugns so that we have more control over what is going on (for example, we can remove the need to have an unversioned plugin to fall back on). -- 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] Updated: (FOR-190) Add barcoding in Forrest
[ http://issues.apache.org/jira/browse/FOR-190?page=all ] Juan Jose Pablos updated FOR-190: - Component: Plugins (general issues) Description: It's easy using barcodej to add barcoding capability to Forrest. In particular we can add a barcode for every page. was: It's easy using barcodej to add barcoding capability to Forrest. In particular we can add a barcode for every page. Environment: Add barcoding in Forrest Key: FOR-190 URL: http://issues.apache.org/jira/browse/FOR-190 Project: Forrest Type: New Feature Components: Plugins (general issues) Reporter: Nicola Ken Barozzi Assignee: Nicola Ken Barozzi Priority: Trivial It's easy using barcodej to add barcoding capability to Forrest. In particular we can add a barcode for every page. -- 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: [jira] Commented: (FOR-506) Do not hard-code site-visible message strings in skin files
Pedro I. Sanchez wrote:
I can not reproduce this. Forrest site works for me.
Are you on Linux or Windows?
debian 3.1
I don't understand. How can it work for you?
how can it does not work for you?
This line in sitemap.xmap is the one that determines the catalogue to
use and as you can see it is not connected at all with the LANG
environment variable.
no, I do not see why are you making this up.
map:parameter name=locale value={request:locale}/
It is connected instead to the language selection of your browser which
doesn't help much with a static site.
Why are you making that statement without knowledge of how it works?
Locale is determined based on diferent parameters with an order, not
just that one.
have you try to issue export LANG=es ??? I think that I told you
before.
It's the same. In both cases the execution environment has the variable
LANG set to the proper value. Anyhow, I tested using the export with
the same results.
Can you explain why you think 'user.language' does anything when it is
not defined in forrest.build.xml?
Because is part of the JVM properties and it will define the server
default language use. So when you try to build a static site the VM
default locale is used.
Possibly we need to look into the CLI to find out a better way to do
that, ok, but today that know this can work.
I made some notes here:
http://casa.che-che.com/blog/2005/05/10/internalization-a-site-using-forrest-07-dev/
if that does not work for you then it is something that is not quite
right on your enviroment/test
Cheers,
cheche
[jira] Commented: (FOR-530) [views] New contract; compliance-links
[ http://issues.apache.org/jira/browse/FOR-530?page=comments#action_12313146 ] Juan Jose Pablos commented on FOR-530: -- done. ( we need to give a hand to Thorsten with your patches diwaker) [views] New contract; compliance-links -- Key: FOR-530 URL: http://issues.apache.org/jira/browse/FOR-530 Project: Forrest Type: Improvement Components: Skins (general issues) Versions: 0.8 Reporter: Diwaker Gupta Assignee: Thorsten Scherler Attachments: compliance-links.ft This is a new contract to put in the 'Valid XHTML' and 'Valid CSS' links. -- 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: [jira] Commented: (FOR-506) Do not hard-code site-visible message strings in skin files
Pedro I. Sanchez wrote: The string $(env.LANG} works well inside main/forrest.build.xml. It was the default before you made changes to the trunk. But the same string is ignored when you use it inside webapp/sitemap.xmap (skin labels are looked up in the English dictionary, even if LANG=es_ES). are you talking about tabs and menus or are you talking about Last Published: I don't believe what you did is right, sorry if I misunderstand :| You replaced my 'project.language' with 'user.language' but you are not defining 'user.language' in forrest.build.xml. So it does nothing when I use it in my site's 'forrest.properties'. is using the default language for the JVM. In the case of the windows machines, that will work much better. This change only affect the creation of a directory base on the language.. This way you can run export LANG=en forrest site export LANG=es forrest site so diferent languages goes to diferent directories. So, let me rephrase my understanding of this issue so far. Before you made changes to trunk this was the behaviour: 1. Forrest seed; forrest would generate the static site in English, regardless of your LANG env. sure. There is not implementation to seed a project with examples in spanish.. 2. Setting project.i18n=true in forrest.properties and running forrest again would generate your site in build/site/xx, where xx is determined by the LANG env. BUT, the generated static site is still all in English; no look up into the language-specific catalogues ever takes place. I can not reproduce this. Forrest site works for me. My goal for a static site is to be able to issue the command $ LANG=es_ES forrest have you try to issue export LANG=es ??? I think that I told you before. cheers, cheche
Re: svn commit: r189734 [2/3] - in /forrest/site/0.7: ./ docs/ docs/howto/ docs/plugins/
David Crossley wrote: Juan Jose Pablos wrote: David, [EMAIL PROTECTED] wrote: -html +html xmlns:i18n=http://apache.org/cocoon/i18n/2.1; -script type=text/javascript language=JavaScript!-- - document.write(Published: + document.lastModified); - // --/script +script type=text/javascript!-- +document.write(Last Published:?? + document.lastModified); +// --/script both entries looks like an error. Are you sure about both? No, those changes alarmed me too. I was just publishing the site and notices these differences. Some something has changed over the last few days. Would someone please investigate the causes. --David I think that they are related to the i18n stuff...
Re: svn commit: r189734 [2/3] - in /forrest/site/0.7: ./ docs/ docs/howto/ docs/plugins/
David Crossley wrote: Juan Jose Pablos wrote: David, [EMAIL PROTECTED] wrote: -html +html xmlns:i18n=http://apache.org/cocoon/i18n/2.1; -script type=text/javascript language=JavaScript!-- - document.write(Published: + document.lastModified); - // --/script +script type=text/javascript!-- +document.write(Last Published:?? + document.lastModified); +// --/script both entries looks like an error. Are you sure about both? No, those changes alarmed me too. I was just publishing the site and notices these differences. Some something has changed over the last few days. Would someone please investigate the causes. --David I think that they are related to the i18n stuff...
Re: required Java version (Was: Questions about the release instructions)
Ross Gardler wrote: I would prefer to see us test on 1.4.0 but since I'm not doing the release process I'm happy with 1.4.1 if it makes your lives easier (it actually makes mine harder as I don't have 1.4.1, I have 1.4.0 and 1.4.2, but not 1.4.1). I think that this is trivial. When I had been compiled cocoon for forrest I have been using the minimum major (1.4 for 2.2-dev) and the higher patched version (today would be: 1.4.2_08) But I am happy to whatever the person who does the job choose. If there is a company with millions of dollars that can not afford to upgrade their system from 1.4.0 to 1.4.2_08 then they have one choice: As they have all the source: compile it themselves. If that fails they can report a bug and we will follow this discussion then :-) WDYT?
Re: svn commit: r189734 [2/3] - in /forrest/site/0.7: ./ docs/ docs/howto/ docs/plugins/
Thorsten Scherler wrote: Yes, cheche is right that is i18n stuff, but actual do not know why that is happening. I may find time tomorrow to have a look, but you can beat me to it. ;-) -html +html xmlns:i18n=http://apache.org/cocoon/i18n/2.1; done. +document.write(Last Published:?? + document.lastModified); done as well. But I am not sure if that caracted had to be there, It was not ther before the i18n stuff. cheers, cheche
Re: svn commit: r189541 - /forrest/trunk/site-author/status.xml
[EMAIL PROTECTED] wrote: Author: crossley Date: Wed Jun 8 00:29:42 2005 New Revision: 189541 URL: http://svn.apache.org/viewcvs?rev=189541view=rev Log: Add missing @type attribute for one entry. sorry, I was testing jedit for editing status. Do you think that this attribute should be marked as required? Cheers, cheche
default contexts for our project
hi, as you may know the default contexts for our project on status.xml are build|docs|code|admin|design A change in the dtd is going to get in place soon, this change allow any project to define their own contexts, that information has to be in the status file. I would like to replace our default context to: build|docs|core|plugin|tools Please add/remove components if you feel that they are Too many/ too few . Cheers, cheche
[jira] Commented: (FOR-18) support multiple languages (i18n)
[ http://issues.apache.org/jira/browse/FOR-18?page=comments#action_12312856 ] Juan Jose Pablos commented on FOR-18: - I put some information about how to create static site with forrest here: http://casa.che-che.com/blog/2005/05/10/internalization-a-site-using-forrest-07-dev/ support multiple languages (i18n) - Key: FOR-18 URL: http://issues.apache.org/jira/browse/FOR-18 Project: Forrest Type: New Feature Components: Core operations Reporter: Ralf Hauser Assignee: Juan Jose Pablos Priority: Critical Attachments: multLang.zip In my current environment to develop static mulitlingual web-sites, I use an ant build.xml and the m4 macro preprocessor to achieve the following (sample): 1) index.en.m4 gets converted to index.en.html The *.en.m4 contains all language dependent text (similarly *.de.m4 for German) and includes index.m4 that contains the page's content layout. [(^\.)+].m4 includes sitedef.m4 where I define all global parts of the website (e.g. navigation structure, unique content e.g. phone numbers, filenames, etc.). This in turn includes a sitedefs.en or sitedef.de, ... respectively for global, language dependent definitions. 2) Dependencies a) upon change of [(^\.)+].m4, all depending *.*LANG*.html get rebuilt b) upon change of sitedef.m4, build.xml, and alike all *.html gets rebuilt c) upon change of sitedefs.en all *.en.html get rebuilt. Obviously, I could use the exact same approach to create .xml whereever I created .html before, but my long-term goal is to get rid of m4. Has anybody already put some thought into how this would be done with forrest? -- 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] Commented: (FOR-514) Do not limit status.xml contexts in project info plugin
[
http://issues.apache.org/jira/browse/FOR-514?page=comments#action_12312723 ]
Juan Jose Pablos commented on FOR-514:
--
In order to get this validated with actuall dtd, we need to change:
1) remove the contexts entity:
===
--- common-elems-v10.mod(revisin: 180256)
+++ common-elems-v10.mod(copia de trabajo)
@@ -47,7 +47,6 @@
!-- === --
!ENTITY % types add|remove|update|fix
-!ENTITY % contexts build|docs|code|admin|design
!ENTITY % importances high|medium|low
2) use a IDREF instead of an entity:
!-- === --
@@ -61,7 +60,7 @@
!ATTLIST action %common.att;
dev IDREF #REQUIRED
type (%types;) #IMPLIED
- context (%contexts;) #IMPLIED
+ context IDREF #REQUIRED
importance (%importances;) medium
due-to CDATA #IMPLIED
due-to-email CDATA #IMPLIED
3) create context id=docs title=Changes to the documentation element on
the status file.
But: This seem to collapse with the dev IDREF. We can live with it ( It is
unusual that a person has the same id than a context)
Please let me know what do you think, so I can apply this patch.
Do not limit status.xml contexts in project info plugin
---
Key: FOR-514
URL: http://issues.apache.org/jira/browse/FOR-514
Project: Forrest
Type: Improvement
Components: Plugin: projectInfo
Reporter: Ross Gardler
Priority: Minor
Attachments: 514-patch.txt
(This comment brought over from FOR-487)
This improvement of changes page is nice.
I have my own version based on xsl:key definition in order to be able to
simply manage as many contexts as you can define (My Dtd is not limited to
build|docs|code|admin|design.
The advantage - on my opinion - is that my own contexts are very various and
not developpement oriented nor language dependant.
here a short example - using releaseNote... :
http://cyriaque.dupoirieux.free.fr/changes_6.2.1.html
The following code replace the 5 blocks xsl:if test=[EMAIL
PROTECTED]'build'] :
titleVersion xsl:value-of select=@version/ (xsl:value-of
select=@date/)/title
+ xsl:for-each
select=action[generate-id()=generate-id(key('contextes',concat(../@version,
'_', @context)))]
+ xsl:sort select=@context/
+ section
+ titlexsl:value-of select=@context//title
+ ul
+ xsl:apply-templates select=key('contextes',concat(../@version, '_',
@context) )
+ xsl:sort select=@type/
+ /xsl:apply-templates
+ /ul
+ /section
+ /xsl:for-each
Hope you'll like the idea...
Regards,
Cyriaque,
--
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: Use Jira to create workflows for standard processes
Ferdinand Soethe wrote: Can anybody tell if and how we can use Jira to create standards workflows for things like a release. We already use jira for this. You only need to change the fix for version and then It will be displayed on the road map.
Re: [Proposal] reply-to: forrest-dev
Thorsten Scherler wrote: Hello devs, I propose to set the reply-to header of this mailing list to forrest-dev by default. How can I do that (as moderator) and should I call a vote before doing it? salu2 ¿?¿?¿?¿?¿ is not the default behaviour? I can see this: Reply-To: dev@forrest.apache.org
[jira] Commented: (FOR-153) Removing unneed Jar on forrest distribution.
[ http://issues.apache.org/jira/browse/FOR-153?page=comments#action_12312634 ] Juan Jose Pablos commented on FOR-153: -- removed servlet.jar from the chat plugin and from the libe/core. keep only the one in tools/jetty/lib Removing unneed Jar on forrest distribution. Key: FOR-153 URL: http://issues.apache.org/jira/browse/FOR-153 Project: Forrest Type: Task Components: Compile Reporter: Juan Jose Pablos Assignee: Juan Jose Pablos There are 71 Jar on our distribution. I am not 100% sure that all these jar are needed. -- 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: Forrest as an XML repository
FYI: Ricardo Beltran wrote: Hello Forrest developers team: First of all I would like to thank your efforts to bring to reality this great project! I'm planning to use Forrest in a project in Mexico, for a Social Sciences University in Mexico. We have about 10,000 polls about public opinion from the last 18 years of the Mexican history. Those polls were written (and executed) in Clipper (prg). I have a DTD that describes the content and structure of these polls, my plan is to transform those Clipper files to XML and use Forrest to make publicly available this information. As you can imagine there's a lot of information (about 5 GB) and it is very important to have a mechanism to search all this info using keywords. As you can see I'm planning to use Forrest as an XML repository and use Lucene or Google as my search engine. My questions are: Do you think that Forrest is an appropriate framework for this purpose? and Do you think that Lucene or Google will do the job of indexing about (5 GB) of XML files? If not, do you know some other project that could be suitable for this purpose. For your attention to this e-mail thanks a lot. Best Regards Ricardo Beltran [EMAIL PROTECTED] __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail
Re: Meetup at ApacheCon? -- Room nearby!
Thorsten Scherler wrote: On Fri, 2005-06-03 at 10:55 +0200, Nicola Ken Barozzi wrote: Reinhard Poetz wrote: ... If there is no Forrest event on Sunday, we would be more than happy to see you at the Blockathon (http://wiki.apache.org/cocoon/Blockathon) which will start on Sunday. Ah, ok, will see if I can make it :-) I want to go there as well (if possible with you Reinhard). I have not bought the plane tickets yet, but I think that I will stay a whole week... Cheers, cheche
Re: Fussy feelings about 0.7
David Crossley wrote: Thorsten, you started this thread, and Cheche you said me too. However neither of you followed up to tell us what your concerns are. Please say something. Even if your comments are not specific, we need to know why you are making these disruptive statements. sure, I think that FOR-465: Logging Error: Writing event to closed stream. and the output Lazy mode: true and a log4j:WARN Please initialize the log4j system properly. look bad. I think as well that they do not affect to the output site, but in order to fix the first two issues, we would need to upgrade our version of cocoon. At the moment we are not able to do so, Carsten is aware that the command line enviroment is not working, so we need to wait for him to fix it and them test those changes. But I am happy if those changes go to the next release (0.71)
Re: svn commit: r178620 - /forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.Chart/lib/saxpath.license.txt /forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.Chart/lib/servlet_2_2.jar.license.txt
[EMAIL PROTECTED] wrote: Log: Add missing license. Added: forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.Chart/lib/saxpath.license.txt (with props) forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.Chart/lib/servlet_2_2.jar.license.txt - copied unchanged from r178612, forrest/trunk/tools/jetty/servlet-2_3.jar.license.txt uppps... I forgot to email about the servlet library. Do we need the servlet.jar file 3 times on our svn? ./lib/core/servlet-2_3.jar ./whiteboard/plugins/org.apache.forrest.plugin.Chart/lib/servlet_2_2.jar ./tools/jetty/servlet-2.3.jar I am sure that the core one can be removed. But what about the Chart plugin? Cheers, Cheche
Re: Release notes generation
Ross Gardler wrote: I just committed changes to the projectinfo plugin that will generate release notes for a particular version of forrest from status.xml. If you request http://localhost:/releaseNotes_0.7-dev.html you will Let me know if you can see any improvements to be made. Do we need to keep old copies on our svn? why do we need 10 RELEASE-NOTES-0.* files? Cheers, cheche
Re: Fussy feelings about 0.7
Thorsten Scherler wrote: Sure we want to get the 0.7 out the door but it seems there are some *big* bugs that need solutions. On the other hand this solutions will be changed again in 0.8. IMO we should think again about the release and how we want to do it. WDYT? salu2 I have same feelings. But there is nothing that would stop us to release a 0.71 release right?
Re: svn commit: r170845 - /forrest/trunk/lib/core/xml-commons-resolver-1.1.license.txt /forrest/trunk/lib/core/xml-commons-resolver-1.2-dev-20050414T0700.jar.license.txt
[EMAIL PROTECTED] wrote: Author: crossley Date: Wed May 18 17:31:19 2005 New Revision: 170845 URL: http://svn.apache.org/viewcvs?rev=170845view=rev Log: We recently reverted the new entity resolver, so return to its old license. I think that was my mistake. I only put xml-commons-resolver-1.1.jar because it was like that on cocoon. If you think that we should keep xml-commons-resolver-1.2 then we can move that bak I will put a exclude/ on the build script. WDYT? Cheche
NullPointerException building cocoon for forrest
Hi, I need a bit of help building cocoon for forrest. After a succesful build, I am getting this error just for forrest site: Exception in thread main java.lang.NullPointerException at org.apache.cocoon.Cocoon.initialize(Cocoon.java:177) at org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil.java:283) at org.apache.cocoon.bean.CocoonWrapper.initialize(CocoonWrapper.java:175) at org.apache.cocoon.bean.CocoonBean.initialize(CocoonBean.java:98) at org.apache.cocoon.Main.main(Main.java:320) BUILD FAILED /home/cheche/xml/forrest/trunk/main/targets/site.xml:41: Java returned: 1 I have been digging and it seems relate somehow to this commit: http://svn.apache.org/viewcvs.cgi?rev=164112view=rev Can someone put some light on it? Cheers, cheche
