[GUMP@vmgump]: Project forrest-test-basic (in module forrest) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project forrest-test-basic has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 7 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - forrest-test-basic : Apache Forrest software is a publishing framework that trans... Full details are available at: http://vmgump.apache.org/gump/public/forrest/forrest-test-basic/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/forrest/forrest-test-basic/gump_work/build_forrest_forrest-test-basic.html Work Name: build_forrest_forrest-test-basic (Type: Build) Work ended in a state of : Failed Elapsed: 9 secs Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Dant.build.clonevm=true -Djava.awt.headless=true -Xbootclasspath/p:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar:/srv/gump/public/workspace/xml-xalan/build/serializer.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only test-basic [Working Directory: /srv/gump/public/workspace/forrest/main] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/forrest/tools/jetty/jetty-4.2.19.jar:/srv/gump/public/workspace/forrest/tools/jetty/servlet-2.3.jar:/srv/gump/public/workspace/forrest/lib/core/chaperon-20040205.jar:/srv/gump/public/workspace/forrest/lib/core/ehcache-core-2.2.0.jar:/srv/gump/public/workspace/forrest/lib/core/slf4j-log4j12-1.5.11.jar:/srv/gump/public/workspace/forrest/lib/core/slf4j-api-1.5.11.jar:/srv/gump/public/workspace/forrest/lib/core/batik-all-1.6.jar:/srv/gump/public/workspace/forrest/lib/core/jing-2009.jar:/srv/gump/public/workspace/forrest/build/xml-forrest.jar:/srv/gump/packages/apache-attic/avalon-framework-api-4.3.jar:/srv/gump/packages/apache-attic/avalon-framework-impl-4.3.jar:/srv/gump/packages/cocoon-2.1.x/cocoon-2.1.11.jar:/srv/gump/packages/cocoon-2.1.x/cocoon-asciiart-2.1.11.jar:/srv/gump/packages/cocoon-2.1.x/cocoon-auth-2.1.11.jar:/srv/gump/packages/cocoon-2.1.x/cocoon-batik-2.1.11.jar:/srv/gump/packages/ cocoon-2.1.x/cocoon-chaperon-2.1.11.jar:/srv/gump/packages/cocoon-2.1.x/cocoon-fop-2.1.11.jar:/srv/gump/packages/cocoon-2.1.x/cocoon-html-2.1.11.jar:/srv/gump/packages/cocoon-2.1.x/cocoon-linkrewriter-2.1.11.jar:/srv/gump/packages/cocoon-2.1.x/cocoon-lucene-2.1.11.jar:/srv/gump/packages/cocoon-2.1.x/cocoon-profiler-2.1.11.jar:/srv/gump/packages/cocoon-2.1.x/cocoon-template-2.1.11.jar:/srv/gump/packages/cocoon-2.1.x/cocoon-validation-2.1.11.jar:/srv/gump/packages/cocoon-2.1.x/cocoon-xsp-2.1.11.jar:/srv/gump/packages/apache-attic/excalibur-component-2.2.1.jar:/srv/gump/packages/apache-attic/excalibur-datasource-2.2.2.jar:/srv/gump/packages/apache-attic/excalibur-instrument-api-2.2.1.jar:/srv/gump/packages/apache-attic/excalibur-logger-2.2.1.jar:/srv/gump/packages/apache-attic/excalibur-pool-api-2.2.1.jar:/srv/gump/packages/apache-attic/excalibur-pool-impl-2.2.1.jar:/srv/gump/packages/apache-attic/excalibur-pool-instrumented-2.2.1.jar:/srv/gump/packages/apache-attic/excalibur-s ourceresolve-2.2.3.jar:/srv/gump/packages/apache-attic/excalibur-store-2.2.1.jar:/srv/gump/packages/apache-attic/excalibur-xmlutil-2.2.1.jar:/srv/gump/packages/apache-attic/excalibur-i18n-1.1.jar:/srv/gump/packages/apache-attic/excalibur-io-1.1.jar:/srv/gump/packages/apache-attic/excalibur-naming-1.0.jar:/srv/gump/packages/nekopull-0.2.4/nekopull.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/ant-contrib/target/ant-contrib-11012011.jar:/srv/gump/public/workspace/jakarta-bcel/target/bcel-5.3-SNAPSHOT.jar:/srv/gump/public/workspace/commons-lang-2.x/target/commons-lang-2.6-SNAPSHOT.jar:/srv/gump/public/workspa
not a CMS
At Apache Incubator it is being discussed to use the new Apache CMS. Someone asked for an explanation of the overlap with Forrest. I tried here: http://s.apache.org/v8 Re: [DISCUSS] starting the CMS migration process -David
Revised dates (was [Proposal] Release Plan for Forrest 0.90)
On Tue, Dec 07, 2010 at 04:59:06PM +1100, David Crossley wrote: The proposed milestones are: [1] end of vote on Release Plan Monday 2010-12-20 at 22:00 UTC http://www.timeanddate.com/worldclock/fixedtime.html?day=20month=12year=2010hour=22min=0sec=0p1=0 [2] create initial release candidate, start testing Monday 2011-01-10 at 22:00 UTC http://www.timeanddate.com/worldclock/fixedtime.html?day=10month=1year=2011hour=22min=0sec=0p1=0 [3] create final release candidate if necessary Saturday 2011-01-15 at 22:00 UTC http://www.timeanddate.com/worldclock/fixedtime.html?day=15month=1year=2011hour=22min=0sec=0p1=0 [4] end of vote on final release candidate and commence the upload phase Monday 2011-01-17 at 22:00 UTC (i.e. planned release date) http://www.timeanddate.com/worldclock/fixedtime.html?day=17month=1year=2011hour=22min=0sec=0p1=0 [2] create initial release candidate, start testing Revised: Monday 2011-01-31 at 22:00 UTC http://www.timeanddate.com/worldclock/fixedtime.html?day=31month=1year=2011hour=22min=0sec=0p1=0 [3] create final release candidate if necessary Revised: Saturday 2011-02-05 at 22:00 UTC http://www.timeanddate.com/worldclock/fixedtime.html?day=5month=2year=2011hour=22min=0sec=0p1=0 [4] end of vote on final release candidate and commence the upload phase Revised: Monday 2011-02-07 at 22:00 UTC http://www.timeanddate.com/worldclock/fixedtime.html?day=7month=2year=2011hour=22min=0sec=0p1=0 Revisions look correct and acceptable? -Brian
Re: Revised dates (was [Proposal] Release Plan for Forrest 0.90)
Brian M Dube wrote: [2] create initial release candidate, start testing Revised: Monday 2011-01-31 at 22:00 UTC http://www.timeanddate.com/worldclock/fixedtime.html?day=31month=1year=2011hour=22min=0sec=0p1=0 [3] create final release candidate if necessary Revised: Saturday 2011-02-05 at 22:00 UTC http://www.timeanddate.com/worldclock/fixedtime.html?day=5month=2year=2011hour=22min=0sec=0p1=0 [4] end of vote on final release candidate and commence the upload phase Revised: Monday 2011-02-07 at 22:00 UTC http://www.timeanddate.com/worldclock/fixedtime.html?day=7month=2year=2011hour=22min=0sec=0p1=0 Revisions look correct and acceptable? Yes thanks Brian. I see that i have caused the confusion by starting a new thread for the VOTE which has the revised dates: http://s.apache.org/sP [Vote] Release Plan for Forrest 0.90 -David
[jira] Updated: (FOR-1104) pdf output warnings paragraph overflows the available area
[ https://issues.apache.org/jira/browse/FOR-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Crossley updated FOR-1104: Fix Version/s: (was: 0.9-dev) 0.10 Moving to v-0.10 ... there is a workaround to edit the source documents to not have such long lines with no spaces to wrap at. Note that the PDF output is already word-wrapped if possible. pdf output warnings paragraph overflows the available area Key: FOR-1104 URL: https://issues.apache.org/jira/browse/FOR-1104 Project: Forrest Issue Type: Bug Components: Plugin: output.pdf Affects Versions: 0.9-dev Reporter: David Crossley Fix For: 0.10 Warnings are issued such as the following from our site-author: WARN - Line 1 of a paragraph overflows the available area. (fo:block, project.required.plugins=org.apache.forrest.plugin.input.OpenOffice.o) These come from source elements with content that has lines that are too wide, e.g. pluginDocs/plugins_0_90/usingPlugins.xml Perhaps there some way that we can word-wrap or break the long text lines. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FOR-752) Forrestbot build workstage creates spurious build/webapp/WEB-INF/logs directory
[
https://issues.apache.org/jira/browse/FOR-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Crossley updated FOR-752:
---
Fix Version/s: 0.10
Affects Version/s: 0.9-dev
Scheduling this for next version 0.10
However if someone can manage it for upcoming 0.9 that would be better.
Forrestbot build workstage creates spurious build/webapp/WEB-INF/logs
directory
---
Key: FOR-752
URL: https://issues.apache.org/jira/browse/FOR-752
Project: Forrest
Issue Type: Bug
Components: Tool: Forrestbot
Affects Versions: 0.7, 0.8, 0.9-dev
Reporter: Richard Calmbach
Priority: Minor
Fix For: 0.10
When running Forrestbot with the default value for property build.work-dir
(namely work/${ant.project.name}), project.build-dir is set to the same
value and consequently, project.webapp is set to
work/${ant.project.name}/webapp. However, one of the two logs directories
continues to be created at build/webapp/WEB-INF/logs, suggesting that
somewhere a hardcoded value is used instead of ${project.webapp}. The mkdir
command for this logs directory is not in any of the Ant build files in the
Forrest distribution; it must be in one of the Java classes, probably in a
class related to logging. I forced an I/O failure by turning off all
permissions on build/webapp and running forrest -f build.xml build. This
yielded a stacktrace that originated 7 calls before:
org.apache.avalon.excalibur.logger.factory.FileTargetFactory.createTarget(FileTargetFactory.java:160)
The remaining 7 invokations were not displayed (just ... 7 more).
The upshot of this bug is that running forrest -f build.xml clean misses
the logs directory in the unexpected location. My workaround right now is
to use a custom clean-all target that depends on clean and that deletes
the spurious build/webapp directory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FOR-752) Forrestbot build workstage creates spurious build/webapp/WEB-INF/logs directory
[
https://issues.apache.org/jira/browse/FOR-752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12980566#action_12980566
]
Brian M Dube commented on FOR-752:
--
Breakpoint hit: thread=main, java.io.File.mkdirs(), line=1,145 bci=0
main[1] dump this.path
this.path = /tmp/seed/build/webapp/WEB-INF/logs
main[1] where
[1] java.io.File.mkdirs (File.java:1,145)
[2] org.apache.log.output.io.FileTarget.openFile (FileTarget.java:103)
[3] org.apache.log.output.io.FileTarget.init (FileTarget.java:55)
[4] org.apache.avalon.excalibur.logger.factory.FileTargetFactory.createTarget
(FileTargetFactory.java:164)
[5] org.apache.avalon.excalibur.logger.factory.FileTargetFactory.createTarget
(FileTargetFactory.java:145)
[6] org.apache.avalon.excalibur.logger.DefaultLogTargetManager.configure
(DefaultLogTargetManager.java:92)
[7] org.apache.avalon.framework.container.ContainerUtil.configure
(ContainerUtil.java:201)
[8] org.apache.avalon.excalibur.logger.LogKitLoggerManager.setupTargetManager
(LogKitLoggerManager.java:457)
[9] org.apache.avalon.excalibur.logger.LogKitLoggerManager.configure
(LogKitLoggerManager.java:403)
[10] org.apache.cocoon.bean.CocoonWrapper.initialize (CocoonWrapper.java:144)
[11] org.apache.cocoon.bean.CocoonBean.initialize (CocoonBean.java:102)
[12] org.apache.cocoon.Main.main (Main.java:320)
Forrestbot build workstage creates spurious build/webapp/WEB-INF/logs
directory
---
Key: FOR-752
URL: https://issues.apache.org/jira/browse/FOR-752
Project: Forrest
Issue Type: Bug
Components: Tool: Forrestbot
Affects Versions: 0.7, 0.8, 0.9-dev
Reporter: Richard Calmbach
Priority: Minor
Fix For: 0.10
When running Forrestbot with the default value for property build.work-dir
(namely work/${ant.project.name}), project.build-dir is set to the same
value and consequently, project.webapp is set to
work/${ant.project.name}/webapp. However, one of the two logs directories
continues to be created at build/webapp/WEB-INF/logs, suggesting that
somewhere a hardcoded value is used instead of ${project.webapp}. The mkdir
command for this logs directory is not in any of the Ant build files in the
Forrest distribution; it must be in one of the Java classes, probably in a
class related to logging. I forced an I/O failure by turning off all
permissions on build/webapp and running forrest -f build.xml build. This
yielded a stacktrace that originated 7 calls before:
org.apache.avalon.excalibur.logger.factory.FileTargetFactory.createTarget(FileTargetFactory.java:160)
The remaining 7 invokations were not displayed (just ... 7 more).
The upshot of this bug is that running forrest -f build.xml clean misses
the logs directory in the unexpected location. My workaround right now is
to use a custom clean-all target that depends on clean and that deletes
the spurious build/webapp directory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (FOR-752) Forrestbot build workstage creates spurious build/webapp/WEB-INF/logs directory
[
https://issues.apache.org/jira/browse/FOR-752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12980566#action_12980566
]
Brian M Dube edited comment on FOR-752 at 1/12/11 12:33 AM:
I included this stacktrace because I thought it showed the directory being
created in a different part of the code, but I didn't read the issue
description closely enough. Leaving it in since the original description is
truncated.
[1] java.io.File.mkdirs (File.java:1,145)
[2] org.apache.log.output.io.FileTarget.openFile (FileTarget.java:103)
[3] org.apache.log.output.io.FileTarget.init (FileTarget.java:55)
[4] org.apache.avalon.excalibur.logger.factory.FileTargetFactory.createTarget
(FileTargetFactory.java:164)
[5] org.apache.avalon.excalibur.logger.factory.FileTargetFactory.createTarget
(FileTargetFactory.java:145)
[6] org.apache.avalon.excalibur.logger.DefaultLogTargetManager.configure
(DefaultLogTargetManager.java:92)
[7] org.apache.avalon.framework.container.ContainerUtil.configure
(ContainerUtil.java:201)
[8] org.apache.avalon.excalibur.logger.LogKitLoggerManager.setupTargetManager
(LogKitLoggerManager.java:457)
[9] org.apache.avalon.excalibur.logger.LogKitLoggerManager.configure
(LogKitLoggerManager.java:403)
[10] org.apache.cocoon.bean.CocoonWrapper.initialize (CocoonWrapper.java:144)
[11] org.apache.cocoon.bean.CocoonBean.initialize (CocoonBean.java:102)
[12] org.apache.cocoon.Main.main (Main.java:320)
was (Author: brian):
Breakpoint hit: thread=main, java.io.File.mkdirs(), line=1,145 bci=0
main[1] dump this.path
this.path = /tmp/seed/build/webapp/WEB-INF/logs
main[1] where
[1] java.io.File.mkdirs (File.java:1,145)
[2] org.apache.log.output.io.FileTarget.openFile (FileTarget.java:103)
[3] org.apache.log.output.io.FileTarget.init (FileTarget.java:55)
[4] org.apache.avalon.excalibur.logger.factory.FileTargetFactory.createTarget
(FileTargetFactory.java:164)
[5] org.apache.avalon.excalibur.logger.factory.FileTargetFactory.createTarget
(FileTargetFactory.java:145)
[6] org.apache.avalon.excalibur.logger.DefaultLogTargetManager.configure
(DefaultLogTargetManager.java:92)
[7] org.apache.avalon.framework.container.ContainerUtil.configure
(ContainerUtil.java:201)
[8] org.apache.avalon.excalibur.logger.LogKitLoggerManager.setupTargetManager
(LogKitLoggerManager.java:457)
[9] org.apache.avalon.excalibur.logger.LogKitLoggerManager.configure
(LogKitLoggerManager.java:403)
[10] org.apache.cocoon.bean.CocoonWrapper.initialize (CocoonWrapper.java:144)
[11] org.apache.cocoon.bean.CocoonBean.initialize (CocoonBean.java:102)
[12] org.apache.cocoon.Main.main (Main.java:320)
Forrestbot build workstage creates spurious build/webapp/WEB-INF/logs
directory
---
Key: FOR-752
URL: https://issues.apache.org/jira/browse/FOR-752
Project: Forrest
Issue Type: Bug
Components: Tool: Forrestbot
Affects Versions: 0.7, 0.8, 0.9-dev
Reporter: Richard Calmbach
Priority: Minor
Fix For: 0.10
When running Forrestbot with the default value for property build.work-dir
(namely work/${ant.project.name}), project.build-dir is set to the same
value and consequently, project.webapp is set to
work/${ant.project.name}/webapp. However, one of the two logs directories
continues to be created at build/webapp/WEB-INF/logs, suggesting that
somewhere a hardcoded value is used instead of ${project.webapp}. The mkdir
command for this logs directory is not in any of the Ant build files in the
Forrest distribution; it must be in one of the Java classes, probably in a
class related to logging. I forced an I/O failure by turning off all
permissions on build/webapp and running forrest -f build.xml build. This
yielded a stacktrace that originated 7 calls before:
org.apache.avalon.excalibur.logger.factory.FileTargetFactory.createTarget(FileTargetFactory.java:160)
The remaining 7 invokations were not displayed (just ... 7 more).
The upshot of this bug is that running forrest -f build.xml clean misses
the logs directory in the unexpected location. My workaround right now is
to use a custom clean-all target that depends on clean and that deletes
the spurious build/webapp directory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FOR-752) Forrestbot build workstage creates spurious build/webapp/WEB-INF/logs directory
[
https://issues.apache.org/jira/browse/FOR-752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12980579#action_12980579
]
Brian M Dube commented on FOR-752:
--
This seems to work. It's the same idea as Mathieu's proposed change, but it
avoids changing the visibility of ForrestConfUtils.getSystemProperty().
Index: main/java/org/apache/forrest/log/ForrestLogTargetFactory.java
===
--- main/java/org/apache/forrest/log/ForrestLogTargetFactory.java
(revision 1057988)
+++ main/java/org/apache/forrest/log/ForrestLogTargetFactory.java
(working copy)
@@ -42,7 +42,7 @@
if(!projectHome.startsWith(ForrestConfUtils.defaultHome)){
DefaultContext newContext = new DefaultContext(context);
-newContext.put(context-root,projectHome + /build/webapp);
+newContext.put(context-root,
ForrestConfUtils.getProjectWebappHome());
currentContext = newContext;
}
} catch (Exception e) {
Index: main/java/org/apache/forrest/conf/ForrestConfUtils.java
===
--- main/java/org/apache/forrest/conf/ForrestConfUtils.java (revision
1057988)
+++ main/java/org/apache/forrest/conf/ForrestConfUtils.java (working copy)
@@ -89,6 +89,10 @@
return contextHome;
}
+public static String getProjectWebappHome() {
+ return getSystemProperty(project.webapp);
+}
+
/**
* For backwards compatibility, alias old skin names to new ones. This must
* be kept in sync with aliasing in forrest.build.xml/init-props
Forrestbot build workstage creates spurious build/webapp/WEB-INF/logs
directory
---
Key: FOR-752
URL: https://issues.apache.org/jira/browse/FOR-752
Project: Forrest
Issue Type: Bug
Components: Tool: Forrestbot
Affects Versions: 0.7, 0.8, 0.9-dev
Reporter: Richard Calmbach
Priority: Minor
Fix For: 0.10
When running Forrestbot with the default value for property build.work-dir
(namely work/${ant.project.name}), project.build-dir is set to the same
value and consequently, project.webapp is set to
work/${ant.project.name}/webapp. However, one of the two logs directories
continues to be created at build/webapp/WEB-INF/logs, suggesting that
somewhere a hardcoded value is used instead of ${project.webapp}. The mkdir
command for this logs directory is not in any of the Ant build files in the
Forrest distribution; it must be in one of the Java classes, probably in a
class related to logging. I forced an I/O failure by turning off all
permissions on build/webapp and running forrest -f build.xml build. This
yielded a stacktrace that originated 7 calls before:
org.apache.avalon.excalibur.logger.factory.FileTargetFactory.createTarget(FileTargetFactory.java:160)
The remaining 7 invokations were not displayed (just ... 7 more).
The upshot of this bug is that running forrest -f build.xml clean misses
the logs directory in the unexpected location. My workaround right now is
to use a custom clean-all target that depends on clean and that deletes
the spurious build/webapp directory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FOR-752) Forrestbot build workstage creates spurious build/webapp/WEB-INF/logs directory
[
https://issues.apache.org/jira/browse/FOR-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian M Dube updated FOR-752:
-
Other Info: (was: [Patch available])
Forrestbot build workstage creates spurious build/webapp/WEB-INF/logs
directory
---
Key: FOR-752
URL: https://issues.apache.org/jira/browse/FOR-752
Project: Forrest
Issue Type: Bug
Components: Tool: Forrestbot
Affects Versions: 0.7, 0.8, 0.9-dev
Reporter: Richard Calmbach
Priority: Minor
Fix For: 0.9-dev
When running Forrestbot with the default value for property build.work-dir
(namely work/${ant.project.name}), project.build-dir is set to the same
value and consequently, project.webapp is set to
work/${ant.project.name}/webapp. However, one of the two logs directories
continues to be created at build/webapp/WEB-INF/logs, suggesting that
somewhere a hardcoded value is used instead of ${project.webapp}. The mkdir
command for this logs directory is not in any of the Ant build files in the
Forrest distribution; it must be in one of the Java classes, probably in a
class related to logging. I forced an I/O failure by turning off all
permissions on build/webapp and running forrest -f build.xml build. This
yielded a stacktrace that originated 7 calls before:
org.apache.avalon.excalibur.logger.factory.FileTargetFactory.createTarget(FileTargetFactory.java:160)
The remaining 7 invokations were not displayed (just ... 7 more).
The upshot of this bug is that running forrest -f build.xml clean misses
the logs directory in the unexpected location. My workaround right now is
to use a custom clean-all target that depends on clean and that deletes
the spurious build/webapp directory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (FOR-752) Forrestbot build workstage creates spurious build/webapp/WEB-INF/logs directory
[
https://issues.apache.org/jira/browse/FOR-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian M Dube closed FOR-752.
Resolution: Fixed
Fix Version/s: (was: 0.10)
0.9-dev
Contributed patch applied with thanks.
Forrestbot build workstage creates spurious build/webapp/WEB-INF/logs
directory
---
Key: FOR-752
URL: https://issues.apache.org/jira/browse/FOR-752
Project: Forrest
Issue Type: Bug
Components: Tool: Forrestbot
Affects Versions: 0.7, 0.8, 0.9-dev
Reporter: Richard Calmbach
Priority: Minor
Fix For: 0.9-dev
When running Forrestbot with the default value for property build.work-dir
(namely work/${ant.project.name}), project.build-dir is set to the same
value and consequently, project.webapp is set to
work/${ant.project.name}/webapp. However, one of the two logs directories
continues to be created at build/webapp/WEB-INF/logs, suggesting that
somewhere a hardcoded value is used instead of ${project.webapp}. The mkdir
command for this logs directory is not in any of the Ant build files in the
Forrest distribution; it must be in one of the Java classes, probably in a
class related to logging. I forced an I/O failure by turning off all
permissions on build/webapp and running forrest -f build.xml build. This
yielded a stacktrace that originated 7 calls before:
org.apache.avalon.excalibur.logger.factory.FileTargetFactory.createTarget(FileTargetFactory.java:160)
The remaining 7 invokations were not displayed (just ... 7 more).
The upshot of this bug is that running forrest -f build.xml clean misses
the logs directory in the unexpected location. My workaround right now is
to use a custom clean-all target that depends on clean and that deletes
the spurious build/webapp directory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
