[EMAIL PROTECTED]: Project velocity-dvsl (in module velocity-dvsl) 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 [EMAIL PROTECTED] Project velocity-dvsl has an issue affecting its community integration. This issue affects 7 projects, and has been outstanding for 6 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - ant-xdocs-proposal : Java based build tool - authx-example : Apache Authentication and Authorization Framework - fulcrum-dvsl : Services Framework - portals-bridges-frameworks : Support for JSR168 compliant Portlet development - portals-bridges-velocity : Support for JSR168 compliant Portlet development - velocity-dvsl : Template engine - velocity-tools : VelocityTools project Full details are available at: http://vmgump.apache.org/gump/public/velocity-dvsl/velocity-dvsl/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 -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/velocity-dvsl/velocity-dvsl/gump_work/build_velocity-dvsl_velocity-dvsl.html Work Name: build_velocity-dvsl_velocity-dvsl (Type: Build) Work ended in a state of : Failed Elapsed: 3 mins 11 secs Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -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 org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dproject.version=14112007 jar [Working Directory: /srv/gump/public/workspace/velocity-dvsl] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.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-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-14112007.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-dep-14112007.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/packages/jaxen-1.1-beta-6/jaxen-1.1-beta-6.jar - Buildfile: build.xml set-ant-based-on-sysprop: set-ant-based-on-env: init-classpath: init: [echo] velocity-dvsl-14112007 prepare: [mkdir] Created dir: /srv/gump/public/workspace/velocity-dvsl/target [mkdir] Created dir: /srv/gump/public/workspace/velocity-dvsl/target/classes [mkdir] Created dir: /srv/gump/public/workspace/velocity-dvsl/target/conf [mkdir] Created dir: /srv/gump/public/workspace/velocity-dvsl/target/javadoc [mkdir] Created dir: /srv/gump/public/workspace/velocity-dvsl/target/tests [mkdir] Created dir: /srv/gump/public/workspace/velocity-dvsl/lib [mkdir] Created dir: /srv/gump/public/workspace/velocity-dvsl/dist static: [copy] Copying 1 file to /srv/gump/public/workspace/velocity-dvsl/target/conf download: commons-collections-download: http-download: do-http-download: [get] Getting: http://www.ibiblio.org/maven/commons-collections/jars/commons-collections-3.2.jar [get] To: /srv/gump/public/workspace/velocity-dvsl/lib/commons-collections-3.2.jar [get] Error getting http://www.ibiblio.org/maven/commons-collections/jars/commons-collections-3.2.jar to /srv/gump/public/workspace/velocity-dvsl/lib/commons-collections-3.2.jar BUILD FAILED /srv/gump/public/workspace/velocity-dvsl/build.xml:68: The following error occurred while executing this line: /srv/gump/public/workspace/velocity-dvsl/build.xml:82: The following error occurred while executing this line: /srv/gump/public/workspace/velocity-dvsl/build.xml:361: The following error occurred while executing this line: /srv/gump/public/workspace/velocity-dvsl/build.xml:371: java.net.ConnectException: Connection timed out Total time: 3 minutes 11 seconds - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/velocity-dvsl/velocity-dvsl/rss.xml - Atom: http://vmgump.apache.org/gump/public/velocity-dvsl/velocity-dvsl/atom.xml == Gump Tracking Only === Produced by Gump
Re: svn commit: r593549 - in /velocity/tools/branches/2.x/src/main/java/org/apache/velocity/tools: generic/ValueParser.java view/ParameterTool.java
On Nov 13, 2007 8:52 AM, Nathan Bubna [EMAIL PROTECTED] wrote: On Nov 13, 2007 8:07 AM, Nathan Bubna [EMAIL PROTECTED] wrote: On Nov 13, 2007 3:46 AM, Claude Brisson [EMAIL PROTECTED] wrote: Le lundi 12 novembre 2007 à 16:18 -0800, Nathan Bubna a écrit : snip/ My feeling here is that although foo.int is a cool syntax, it has too many backwards ; especially, we should always return the integral type (string, boolean or number) when available rather than a wrapper around it to avoid nasty side effects. c'mon, ValueParser is no less a wrapper than ValueParserSub would be. even a returning a simple HashMap would be returning a wrapper. as long as we make the subkey business configurable (with it off when in deprecation support mode), and only return the ValueParser/ValueParserSub/HashMap for $params.foo when there are keys that start with foo., then i think we'll be fine. You don't get my point. i would say the same... :) By construction, an application should usually know when expecting a map or an integral type. Let's consider those points separately: - maps: both implementations do wrap them. I guess both are valid but I prefer the new one because I don't see why we should use two different wrappers (ValueParser itself is already a wrapper around a map). Having the wrapper extend Map respects the principle of least surprise for template coders. that helps only for Maps, which i suspect will not often be found inside the source map. - integral types: wrapping them is not a problem as long as they're used directly for display (and it allows the foo.int syntax), but whenever those values will be used as arguments to other tools or objects methods you will encounter side effects (and don't even think of trying to detect the appropriate conversion by reflection, it only works for very simple cases). $list.add($params.foo) would add the ValueParserSub to the list, not the integral type... and there are plenty of examples like this one. In fact, specifying the type (.int, .string, ...) becomes mandatory to get rid of the wrapper. Which is rather cumbersome. and what gets added to the $list in your current implementation when subkeys are allowed and there is also a foo.bar available in the source map? $list.add() receives a ValueParser instead of the integral type, right? so once again, it becomes necessary to get rid of the wrapper. but how? the new ValueParser returned by $params.foo provides no means to unwrap itself, cumbersome or otherwise. if you really just want the foo parameter and not a foo.bar one, then it seems you are out of luck. i just re-examined the current code. i wasn't wrong. in your current implementation, $params.foo *will* return the integral type for foo if there is one. However, the presence of foo means that $params.foo.bar syntax will fail. This unsettles me somewhat as it seems rather fragile and unpredictable. Granted, to do things as i had anticipated (have $params.foo return a wrapper anytime a foo.bar type parameter is available), makes the type returned by $params.foo unpredictable, but this seems less troublesome than making it unpredictable whether anything at all will be returned. i've got to get some other work done now, but i'll be thinking about this more... ok, after much thought, i think i prefer the better backwards compatibility of always having $params.foo return its string value to returning a ValueParser or ValueParserSub when subkeys for foo are available and a string when there are no foo subkeys. the better backwards compatibility is slightly more important to me than having the subkey syntax work consistently. we will, however, need to be sure and document clearly that the subkey syntax is unreliable in such situations. of course, i could be swayed the other way on this in the future if this starts to pose problems, but for now, i'm onboard with the current implementation. thanks for bearing with my obstinance and inattention... :) Re-introducing the foo.int syntax would be cool, of course, but why not try to do it in the engine itself (so it is generalized to every value)? It'd be cool to be able to do $foo.int on every value (once one have checked that int is not a valid key for foo). that is a very interesting idea. it won't solve the problem i describe above, but it could be cool. Claude snip/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To
[EMAIL PROTECTED]: Project velocity-texen-test (in module velocity-texen) 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 [EMAIL PROTECTED] Project velocity-texen-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 62 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - velocity-texen-test : Texen is a general purpose text generating utility based on ... Full details are available at: http://vmgump.apache.org/gump/public/velocity-texen/velocity-texen-test/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/velocity-texen/velocity-texen-test/gump_work/build_velocity-texen_velocity-texen-test.html Work Name: build_velocity-texen_velocity-texen-test (Type: Build) Work ended in a state of : Failed Elapsed: 10 secs Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Ddeprecation=false -Dversion=14112007 -Dskip.jar.loading=true test [Working Directory: /srv/gump/public/workspace/velocity-texen/build] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/velocity-texen/bin/test-classes:/srv/gump/public/workspace/velocity-texen/test/texen-classpath/test.jar:/srv/gump/public/workspace/velocity-texen/bin/texen-14112007.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.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-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/apache-commons/collections/build/commons-collections-14112007.jar:/srv/gump/public/workspace/apache-commons/lang/commons-lang-14112007.jar:/srv/gump/public/workspace/logging- log4j-12/dist/lib/log4j-14112007.jar:/srv/gump/public/workspace/jdom/build/jdom.jar:/srv/gump/packages/werken-xpath/werken-xpath-0.9.4.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-14112007.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-dep-14112007.jar:/srv/gump/public/workspace/velocity-anakia/bin/anakia-14112007.jar:/srv/gump/packages/antlr-2.7.6/antlr.jar - compile-test: [javac] Compiling 5 source files to /srv/gump/public/workspace/velocity-texen/bin/test-classes test-texen: [texen] Using contextProperties file: /srv/gump/public/workspace/velocity-texen/test/texen/service.props [texen] Using contextProperties file: /srv/gump/public/workspace/velocity-texen/test/texen/additional.props [texen] /srv/gump/public/workspace/velocity-texen/test/texen/templates [texen] Generating to file /srv/gump/public/workspace/velocity-texen/bin/test/texen/report [java] .Comparing result file 'bin/test/texen/TurbineWeather.java' with compare file 'test/texen/compare/TurbineWeather.java' [java] Comparing result file 'bin/test/texen/TurbineWeatherService.java' with compare file 'test/texen/compare/TurbineWeatherService.java' [java] Comparing result file 'bin/test/texen/WeatherService.java' with compare file 'test/texen/compare/WeatherService.java' [java] Comparing result file 'bin/test/texen/book.txt' with compare file 'test/texen/compare/book.txt' [java] Comparing result file 'bin/test/texen/Text.txt' with compare file 'test/texen/compare/Text.txt' [java] Passed! [java] [java] Time: 0.1 [java] [java] OK (1 test) [java] test-texen-classpath: [texen] Using contextProperties file: /srv/gump/public/workspace/velocity-texen/service.props [texen] Using classpath [texen] Generating to file /srv/gump/public/workspace/velocity-texen/bin/test/texen-classpath/report [java] .Comparing result file 'bin/test/texen/TurbineWeather.java' with compare file 'test/texen/compare/TurbineWeather.java' [java] Comparing result file 'bin/test/texen/TurbineWeatherService.java' with compare file 'test/texen/compare/TurbineWeatherService.java' [java] Comparing result file 'bin/test/texen/WeatherService.java' with compare file 'test/texen/compare/WeatherService.java' [java] Comparing result file 'bin/test/texen/book.txt' with compare file 'test/texen/compare/book.txt' [java] Comparing result file
Re: [veltools] what next?
Update: So, i just finished going through recent changes to the trunk (aka 1.x branch), and there are more than i'd remembered during the discussion below. As there are a number of new features, not just bug fixes, i think it would be appropriate to release the trunk as 1.4 rather than 1.3.1. I'm going to start preparing to do the release now. If anyone insists on this being 1.3.1, please speak up soon so that i don't have to call for multiple votes and all that. This is also last call for any final tweaks to 1.x. Claude? Christopher? Marino? Bueller? last chance folks, then it's all 2.x... :) stay tuned... On Oct 29, 2007 8:24 AM, Nathan Bubna [EMAIL PROTECTED] wrote: On 10/28/07, Claude Brisson [EMAIL PROTECTED] wrote: Le vendredi 26 octobre 2007 à 11:38 -0700, Nathan Bubna a écrit : Hey Velocity folks (and especially VelocityTools folks), VelocityTools 2 is working well and pretty much ready for another alpha release, but it's not moving as quickly as i'd hoped. In the meantime, VelocityTools 1.x has a few unreleased features and fixes that are overdue for release. This has created something of an impasse for me, and i'd love your input on a few things. Why not target a beta release? I'm already using it and quite happy with it. i'm not comfortable attaching the word beta to a 2.0 release whose docs are almost completely unchange from the last 1.x release. i do agree the code is beta-quality, but the 2.0 docs are truly alpha. I have scratched my main personal itches for VelocityTools 2, but there are still some things i was planning to have before we release 2.0, specifically updated docs, updated showcase examples, Tiles2 support and complete caching for VelocityViewTag. Updating the docs and showcase examples are firm requirements for me, but the other two features are not things i personally need. Me neither... So, question one, what are your thoughts and feelings on the use/importance of: Tiles2 support? caching for the VelocityViewTag? something else i'm forgetting? Now, in regards to VelocityTools 1.x. VelocityTools 2 is almost completely compatible (though with much deprecation) with VelocityTools 1.3. Second question: what should we do with the 1.x series? +1 to Will suggestion: release a 1.3.1 and inform users that they should move to 2.0. i'm ok with that. if anyone out there objects, speak up soon! :) stop now and focus on getting 2.0 out and easing transition from 1.3 to 2.0? release the trunk as 1.4 and be done with it? release the trunk as 1.3.1 (since there's not a ton of new stuff) and be done with it? continue developing both 1.x and 2.x in parallel? some other option? Finally, my third question, will you help? Claude? Marino? Christopher T.? Christopher S.? Will? I know you guys are out there! :) And yeah, i know life is busy, and i've been charging madly ahead with 2.0 development, making it hard to jump in. But, 2.0 has largely gelled at this point, and i could REALLY use some help with filling out tests and updating documentation for it (which are all fairly easy for multiple devs to do in parallel). I'll do my best... in terms of documentation, I'm searching for a way to give more visibility to the VelTools library an an efficient alternative to framework based approaches for small webapp projects. I've got the feeling that newcomers may perceive VelTools at first as a bunch of unordered goodies for Velocity, which it is definitely not. yeah, that would be great. feel free to experiment! i'll chime in as i think of things. Also, i'm seriously lacking in motivation to get the latest stuff in 1.x documented and released, since i'm just using 2.0 now. If any of you guys are still invested in 1.x and interested in seeing another release (or more), now is the time to speak up and help out. I know i told someone months ago that i'd rattle off another 1.x release, but i'm just not sure it's worth it at this point. Sorry. :( Thanks for reading! Please let me know your thoughts and seriously consider helping out. Oh, and if you want to help out with documentation for 2.0, i have actually written quite a bit, but it is all plain text. I mostly need help either integrating it into the old DVSL doc system or (if you're feeling ambitious) Henning's new Maven-based doc system that Engine is using now. Plain text is much more than nothing! :) when code/docs/whatever exists in only one digital location, it is just a small step away from nothing. working to get the text on the wiki for more permanency... peace, nathan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELTOOLS-84) Create .jar dependency documentation as has been done with Velocity project
[ https://issues.apache.org/jira/browse/VELTOOLS-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna updated VELTOOLS-84: - Fix Version/s: 2.0 this will have to wait for a 2.0 release. Create .jar dependency documentation as has been done with Velocity project --- Key: VELTOOLS-84 URL: https://issues.apache.org/jira/browse/VELTOOLS-84 Project: Velocity Tools Issue Type: Task Components: Documentation Reporter: Peter Locke Fix For: 2.0 There are great pages for the velocity engine (links below), something similar would be very handy for the tools subproject for integration into larger applications. Nathan requested a Jira so it does not get forgotten, and here it is. http://velocity.apache.org/engine/devel/jar-dependencies.html http://velocity.apache.org/engine/devel/dependencies.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELTOOLS-83) VelocityViewServlet returns 200 OK on error
[
https://issues.apache.org/jira/browse/VELTOOLS-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Bubna updated VELTOOLS-83:
-
Fix Version/s: 2.0
not going to happen in the 1.x series.
VelocityViewServlet returns 200 OK on error
Key: VELTOOLS-83
URL: https://issues.apache.org/jira/browse/VELTOOLS-83
Project: Velocity Tools
Issue Type: Bug
Components: VelocityView
Affects Versions: 1.3
Reporter: bruce sherrod
Fix For: 2.0
When VelocityViewServlet reports and error (e.g. if an exception is thrown
from a $reference.method()), it returns a detailed error page with status 200.
This interoperates with the web container poorly, as it cannot be caught and
redirected to a nice error page in a production environment (e.g. through the
error-page mechanism in web.xml).
This is complicated by the fact that VelocityViewServlet writes directly to
the HttpResponseServlet writer, so once the template processing has begun, it
is no longer possible to call HttpServletResponse.sendError() and send, say,
a 500 Internal Server Error, which would be more appropriate.
Here is a patch: change VelocityViewServlet.mergeTemplate() so that it
buffers to a StringWriter, and only writes to the HttpServletResponse writer
after the merge is completed.
This way, users can override VelocityViewServlet.error() to call
response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR) if desired.
protected void mergeTemplate(Template template,
Context context,
HttpServletResponse response)
throws ResourceNotFoundException, ParseErrorException,
MethodInvocationException, IOException,
UnsupportedEncodingException, Exception
{
VelocityWriter vw = null;
// write to a temporary string buffer, so that if we have to
bail
// and call HttpServletResponse.sendError(), we still can -- bs
//Writer writer = getResponseWriter(response);
StringWriter sw = new StringWriter();
try
{
vw = (VelocityWriter)writerPool.get();
if (vw == null)
{
vw = new VelocityWriter(sw, 4 * 1024, true);
}
else
{
vw.recycle(sw);
}
performMerge(template, context, vw);
}
finally
{
if (vw != null)
{
try
{
// flush and put back into the pool
// don't close to allow us to play
// nicely with others.
vw.flush();
// really write to the
HttpServletResponse
String output =
sw.getBuffer().toString();
Writer writer =
getResponseWriter(response);
writer.write(output);
/* This hack sets the VelocityWriter's internal ref to the
* PrintWriter to null to keep memory free while
* the writer is pooled. See bug report #18951 */
vw.recycle(null);
writerPool.put(vw);
}
catch (Exception e)
{
velocity.getLog().debug(VelocityViewServlet: +
Trouble releasing VelocityWriter: +
e.getMessage());
}
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Texen patches coming
Hi, on my laptop, I have a number of Texen refactorings sitting for ages (since AC EU 07 to be exact), which I never committed. I took the time at AC US to finish these and will start to apply them to the Texen repo shortly. This brings the Texen codebase to the same level as Anakia. I am aware of the various things that have been going on in the meantime and the FileLRU patches and I try to preserve them. These roll the Texen Ant Tasks into actual unit tests, which will also allow the patches for multifile etc. to be changed to real ant tasks. Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design| Velocity - Turbine Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release VelocityTools 1.4
Ok, folks. I believe it's time to wrap up VelocityTools 1.x and move on. This is the last planned release in the 1.x series. Since i really don't think anyone has other changes waiting in the wings for the release, i went ahead and rolled the test build. Please test thoroughly, so just maybe it can really be the last one without any point releases for typos or build problems. :) The test build for this release is available at: http://people.apache.org/~nbubna/velocity/tools/1.4/ Please vote regarding your support for releasing this test build as VelocityTools 1.4: [ ] +1 Let's do it [ ] +0 Have fun; i don't care. [ ] -0 Not sure about this, but i won't stop you. [ ] -1 No, because __ The voting period is typically 72 hours, putting its close time as roughly 5pm PST on Saturday, Nov 17th. If i do not find time amidst chores that day to finish the release process, then i will do so first thing Monday morning (assuming the vote passes), with the hope that we can announce the release Tuesday morning. My vote is +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
