[tools] Velocity-tools pom not present in repository
The ".pom" file for velocity-tools 1.3 is not present in the main repository: http://repo1.maven.org/maven2/velocity-tools/velocity-tools/1.3/ Can you fix it please? Thanks Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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 59 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: 16 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=12112007 -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-12112007.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-12112007.jar:/srv/gump/public/workspace/apache-commons/lang/commons-lang-12112007.jar:/srv/gump/public/workspace/logging- log4j-12/dist/lib/log4j-12112007.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-12112007.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-dep-12112007.jar:/srv/gump/public/workspace/velocity-anakia/bin/anakia-12112007.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.9 [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 'bin/test/te
[Velocity Wiki] Update of "BoardReports" by WillGlassHusain
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Velocity Wiki" for change notification. The following page has been changed by WillGlassHusain: http://wiki.apache.org/velocity/BoardReports The comment on the change is: link to new board report -- * ["BoardReport-August2007"] + * ["BoardReport-November2007"] + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Velocity Wiki] Update of "BoardReport-November2007" by WillGlassHusain
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Velocity Wiki" for change notification. The following page has been changed by WillGlassHusain: http://wiki.apache.org/velocity/BoardReport-November2007 The comment on the change is: November board report New page: == November 2007 Board Report == Velocity remains a mature product with spurts of developer activity. Developers and power users remain present on the mailing lists. The user list averages 1-2 questions a day from new users, of which almost all are answered immediately. We've been struggling a little with Gump issues in the past month. Commons Lang subtly changed the spec for an API call ( https://issues.apache.org/jira/browse/LANG-363 ) which caused one of the unit tests in Velocity to fail. The lack of debuggability of the gump run led to some very inelegant print statements scattered throughout the unit test until the specific failure was isolated. Very old-style coding. (change a line, wait a day for gump, change a line, wait a day). We still have a Texen gump failure, though hoping to get that straightened out soon. The Velocity project currently has no board-level issues at this time. === Community Changes === No new committers were voted in since the last board report. No new PMC members were voted in since the last board report. === Velocity Engine === There's been some minor activity improving various syntax issues (i.e. adding variable arguments) and fixing user-reported bugs. No beta or final releases were made since the last board report. === Velocity Tools === Velocity Tools is currently the most active project, with development focused on the new 2.0 branch. This is in alpha and moving towards beta. We had a brief discussion on the dev lists whether to continue supporting the 1.x branch (currently on version 1.3), or urge users to adopt 2.0 when it is released. The consensus was to release a 1.3.1 version with minor updates and fixes, then retire that branch. (Seemed the practical direction given the straight-forward upgrade path from 1.3 to 2 and the interests of our small developer community). We hope to release both 2.0-beta1 and 1.3.1 by January. === Velocity Docbook === We committed our first user-submitted patch (DBF-1). Otherwise this product remains stable. It appears to be primarily used internally though there are occasional queries and comments about it on the user list. === Velocity Anakia === No activity this past quarter. === Velocity DVSL === No activity this past quarter. === Velocity Texen === There was a small amount of activity fixing bugs and adding user-submitted patches from JIRA. If enough patches and updates get submitted we will release a version 1.1 by the next quarter. Texen currently has an unresolved Gump issue (see above). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools] Velocity-tools pom not present in repository
On Nov 12, 2007 1:33 AM, Antonio Petrelli <[EMAIL PROTECTED]> wrote: > The ".pom" file for velocity-tools 1.3 is not present in the main repository: > http://repo1.maven.org/maven2/velocity-tools/velocity-tools/1.3/ > Can you fix it please? see http://markmail.org/message/5xm67jzcxtv2q6vn there aren't a lot of maven mavens around here. Henning is closest, but he's generally busy with other ASF stuff. if you know how to get a pom out there, please feel free to help out. :) > Thanks > Antonio > > - > 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]
Re: [tools] Velocity-tools pom not present in repository
2007/11/12, Nathan Bubna <[EMAIL PROTECTED]>: > > On Nov 12, 2007 1:33 AM, Antonio Petrelli <[EMAIL PROTECTED]> > wrote: > > The ".pom" file for velocity-tools 1.3 is not present in the main > repository: > > http://repo1.maven.org/maven2/velocity-tools/velocity-tools/1.3/ > > Can you fix it please? > > see http://markmail.org/message/5xm67jzcxtv2q6vn > > there aren't a lot of maven mavens around here. Henning is closest, > but he's generally busy with other ASF stuff. if you know how to get > a pom out there, please feel free to help out. :) Whooops sorry! I just found out that the "real" artifacts are deployed under "org.apache.velocity" group, so you probably did the right thing (i.e. use the "deploy" phase in Maven). Sorry for my misunderstanding. Thanks Antonio
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 10, 2007 2:54 AM, Claude Brisson <[EMAIL PROTECTED]> wrote:
> Le vendredi 09 novembre 2007 à 12:15 -0800, Nathan Bubna a écrit :
> > - the hasSubKeys things doesn't make any sense to me
>
> Maybe the name isn't appropriate. What I call "subkey" is "foo" or "bar"
> in "foo.bar". Feel free to rename anything, English is not my mother
> tongue...
it's not the name so much as how it's used. it looks to me like once
it searches for subkey "foo", it won't even try to find subkey "bar"
or "woogie" or whatever. either that's wrong or i'm missing
something?
> > i'm also curious about what the advantages are of this approach (as
> > opposed to a ValueParserSub). it's been a while since i've thought
> > through the implementation options for this.
>
> Things have changed since then: the engine is now quite efficient in
> automatic types conversions so the "foo.int" syntax is much less
> necessary than "foo.bar", and you always have "foo.getInt()".
huh? foo.int is the same as foo.getInt(). you can't have the latter
if the former doesn't work. did you mean getInt('foo')? also, the
sub could handle both foo.bar and foo.int, and the engine can only do
a small fraction of the conversions the ValueParser is capable of.
so, while i don't see anything wrong with the current approach (apart
from the hasSubKey thing), i still suspect a Sub has more potential,
since we have complete control of the API.
> But above all, having the generic getter return something else (that is,
> the ValueParserSub) than the underlying basic type leads - at least in
> my experience - to several side effects (like a jdbc driver being unable
> to handle the ValueParserSub class by calling toString on it).
not sure how returning ValueParserSub is that different from returning
ValueParser.
> The proposed implementation only returns a new ValueParser object
> whenever subkeys are allowed and found.
same could be done with a Sub. granted, the implementation would have
to be smarter (i.e. search for a potential matching subkeys first)
than the last implementation for this, but there's no reason it can't
be done.
>
>
> Claude
>
>
> > On Nov 9, 2007 7:15 AM, Claude Brisson <[EMAIL PROTECTED]> wrote:
> > > ValueParser now has protected get/setAllowSubkeys() boolean methods.
> > >
> > > The default value of allowSubkey shoud be the value of deprecatedMode,
> > > but I'm not really sure of how this should be done. But I'm sure Nathan
> > > will be of some help here.
> > >
> > > Also, since ValueParser is used internally by the Tool.configure method,
> > > it may be safer to move all this new stuff in ParameterParser only.
> > >
> > >Claude
> > >
> > >
> > > Le vendredi 09 novembre 2007 à 14:49 +, [EMAIL PROTECTED] a
> > > écrit :
> > >
> > > > Author: cbrisson
> > > > Date: Fri Nov 9 06:49:36 2007
> > > > New Revision: 593549
> > > >
> > > > URL: http://svn.apache.org/viewvc?rev=593549&view=rev
> > > > Log:
> > > > sub keys getter (not yet tested but doesnt break anything at least)
> > > >
> > > > Modified:
> > > >
> > > > velocity/tools/branches/2.x/src/main/java/org/apache/velocity/tools/generic/ValueParser.java
> > > >
> > > > velocity/tools/branches/2.x/src/main/java/org/apache/velocity/tools/view/ParameterTool.java
> > > >
> > > > Modified:
> > > > velocity/tools/branches/2.x/src/main/java/org/apache/velocity/tools/generic/ValueParser.java
> > > > URL:
> > > > http://svn.apache.org/viewvc/velocity/tools/branches/2.x/src/main/java/org/apache/velocity/tools/generic/ValueParser.java?rev=593549&r1=593548&r2=593549&view=diff
> > > > ==
> > > > ---
> > > > velocity/tools/branches/2.x/src/main/java/org/apache/velocity/tools/generic/ValueParser.java
> > > > (original)
> > > > +++
> > > > velocity/tools/branches/2.x/src/main/java/org/apache/velocity/tools/generic/ValueParser.java
> > > > Fri Nov 9 06:49:36 2007
> > > > @@ -21,6 +21,9 @@
> > > >
> > > > import java.util.Map;
> > > > import java.util.Locale;
> > > > +import java.util.Set;
> > > > +import java.util.HashMap;
> > > > +
> > > > import org.apache.velocity.tools.config.DefaultKey;
> > > >
> > > > /**
> > > > @@ -40,6 +43,14 @@
> > > > {
> > > > private Map source = null;
> > > >
> > > > +private boolean allowSubkeys = true; /* default to whatever,
> > > > should be overridden by depreprecatedMode default value anyway */
> > > > +
> > > > +/* when using subkeys, cache at least the presence of any subkey,
> > > > +so that the rendering of templates not using subkeys will only
> > > > +look once for subkeys
> > > > + */
> > > > +private boolean hasSubkeys = true;
> > > > +
> > > > public ValueParser() {}
> > > >
> > > > public ValueParser(Map source)
> > > > @@ -98,7 +109,11 @@
> > > > {
> > > > return null;
> > > > }
> > > > -return getSource().get(key);
> > > > +Object value = getSource().
Re: svn commit: r593549 - in /velocity/tools/branches/2.x/src/main/java/org/apache/velocity/tools: generic/ValueParser.java view/ParameterTool.java
Le lundi 12 novembre 2007 à 10:53 -0800, Nathan Bubna a écrit :
> it's not the name so much as how it's used. it looks to me like once
> it searches for subkey "foo", it won't even try to find subkey "bar"
> or "woogie" or whatever. either that's wrong or i'm missing
> something?
The "hasSubkeys" boolean is here so that we don't search for subkeys
twice if we already know there isn't any (so that the overhead when
looking for inexisting keys, in templates that don't use subkeys, is
reduced to only one indeOf('.') in all key names). The very first
implementation was buggy, it may be the one you read.
> > > i'm also curious about what the advantages are of this approach (as
> > > opposed to a ValueParserSub). it's been a while since i've thought
> > > through the implementation options for this.
> >
> > Things have changed since then: the engine is now quite efficient in
> > automatic types conversions so the "foo.int" syntax is much less
> > necessary than "foo.bar", and you always have "foo.getInt()".
>
> huh? foo.int is the same as foo.getInt(). you can't have the latter
> if the former doesn't work. did you mean getInt('foo')?
Yes, sorry.
> also, the
> sub could handle both foo.bar and foo.int, and the engine can only do
> a small fraction of the conversions the ValueParser is capable of.
> so, while i don't see anything wrong with the current approach (apart
> from the hasSubKey thing), i still suspect a Sub has more potential,
> since we have complete control of the API.
>
> > But above all, having the generic getter return something else (that is,
> > the ValueParserSub) than the underlying basic type leads - at least in
> > my experience - to several side effects (like a jdbc driver being unable
> > to handle the ValueParserSub class by calling toString on it).
>
> not sure how returning ValueParserSub is that different from returning
> ValueParser.
We only return a ValueParser for get("foo") when there are "foo.bar"
keys, and keep returning the integral type otherwise. Since we expect
the same fonctionnalities for $params and $params.foo, the recursive
approach looked simpler to me.
Btw, I hoped that by having ValueParser implement Map I'd see
ValueParser objects displayed like "{ key=value ... }" but I still see
the ugly [EMAIL PROTECTED], I'll dig
into this...
> > The proposed implementation only returns a new ValueParser object
> > whenever subkeys are allowed and found.
>
> same could be done with a Sub. granted, the implementation would have
> to be smarter (i.e. search for a potential matching subkeys first)
> than the last implementation for this, but there's no reason it can't
> be done.
Sure, but it all boils down to the decision to keep the foo.int syntax
or not. If yes, then we definitely need a ValueParserSub object, if no,
then returning either a new ValueParser (when subkeys are found) or the
value in its integral type looks more natural to me.
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.
Claude
> >
> >
> > Claude
> >
> >
> > > On Nov 9, 2007 7:15 AM, Claude Brisson <[EMAIL PROTECTED]> wrote:
> > > > ValueParser now has protected get/setAllowSubkeys() boolean methods.
> > > >
> > > > The default value of allowSubkey shoud be the value of deprecatedMode,
> > > > but I'm not really sure of how this should be done. But I'm sure Nathan
> > > > will be of some help here.
> > > >
> > > > Also, since ValueParser is used internally by the Tool.configure method,
> > > > it may be safer to move all this new stuff in ParameterParser only.
> > > >
> > > >Claude
> > > >
> > > >
> > > > Le vendredi 09 novembre 2007 à 14:49 +, [EMAIL PROTECTED] a
> > > > écrit :
> > > >
> > > > > Author: cbrisson
> > > > > Date: Fri Nov 9 06:49:36 2007
> > > > > New Revision: 593549
> > > > >
> > > > > URL: http://svn.apache.org/viewvc?rev=593549&view=rev
> > > > > Log:
> > > > > sub keys getter (not yet tested but doesnt break anything at least)
> > > > >
> > > > > Modified:
> > > > >
> > > > > velocity/tools/branches/2.x/src/main/java/org/apache/velocity/tools/generic/ValueParser.java
> > > > >
> > > > > velocity/tools/branches/2.x/src/main/java/org/apache/velocity/tools/view/ParameterTool.java
> > > > >
> > > > > Modified:
> > > > > velocity/tools/branches/2.x/src/main/java/org/apache/velocity/tools/generic/ValueParser.java
> > > > > URL:
> > > > > http://svn.apache.org/viewvc/velocity/tools/branches/2.x/src/main/java/org/apache/velocity/tools/generic/ValueParser.java?rev=593549&r1=593548&r2=593549&view=diff
> > > > > ==
> > > > > ---
> > > > > velocity/tools/branches/2.x/src/main/java/org/apache/velocity/tools/generic/ValueParser.java
> > > > > (original)
> > > > > +++
> > > > > velocity/to
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 12, 2007 3:13 PM, Claude Brisson <[EMAIL PROTECTED]> wrote:
> Le lundi 12 novembre 2007 à 10:53 -0800, Nathan Bubna a écrit :
> > it's not the name so much as how it's used. it looks to me like once
> > it searches for subkey "foo", it won't even try to find subkey "bar"
> > or "woogie" or whatever. either that's wrong or i'm missing
> > something?
>
> The "hasSubkeys" boolean is here so that we don't search for subkeys
> twice if we already know there isn't any (so that the overhead when
> looking for inexisting keys, in templates that don't use subkeys, is
> reduced to only one indeOf('.') in all key names). The very first
> implementation was buggy, it may be the one you read.
ah. ok, looked closer at the latest version. looks good. thx. :)
but now i have a new question... why the expandSingletons stuff? we
don't expand them for $params.foo, why should we expand them for
$params.foo.bar?
i'm assuming it's because request params automatically come as arrays
when you iterate over the parameter map. but i would like
ValueParser to be more than just the base for ParameterTool, and it
doesn't make sense for ValueParser.
> > > > i'm also curious about what the advantages are of this approach (as
> > > > opposed to a ValueParserSub). it's been a while since i've thought
> > > > through the implementation options for this.
> > >
> > > Things have changed since then: the engine is now quite efficient in
> > > automatic types conversions so the "foo.int" syntax is much less
> > > necessary than "foo.bar", and you always have "foo.getInt()".
> >
> > huh? foo.int is the same as foo.getInt(). you can't have the latter
> > if the former doesn't work. did you mean getInt('foo')?
>
> Yes, sorry.
no prob. just want to make sure i understand.
> > also, the
> > sub could handle both foo.bar and foo.int, and the engine can only do
> > a small fraction of the conversions the ValueParser is capable of.
> > so, while i don't see anything wrong with the current approach (apart
> > from the hasSubKey thing), i still suspect a Sub has more potential,
> > since we have complete control of the API.
> >
> > > But above all, having the generic getter return something else (that is,
> > > the ValueParserSub) than the underlying basic type leads - at least in
> > > my experience - to several side effects (like a jdbc driver being unable
> > > to handle the ValueParserSub class by calling toString on it).
> >
> > not sure how returning ValueParserSub is that different from returning
> > ValueParser.
>
> We only return a ValueParser for get("foo") when there are "foo.bar"
> keys, and keep returning the integral type otherwise. Since we expect
> the same fonctionnalities for $params and $params.foo, the recursive
> approach looked simpler to me.
perhaps from the standpoint of developing the tool itself, but neither
$params.getInt('foo.bar') nor $params.foo.getInt('bar') is as simple
to a user as $params.foo.bar.int
> Btw, I hoped that by having ValueParser implement Map I'd see
> ValueParser objects displayed like "{ key=value ... }" but I still see
> the ugly [EMAIL PROTECTED], I'll dig
> into this...
nothing special about implementing the Map interface when it comes to
rendering. Velocity simply renders stuff by calling toString().
That's all that needs to change to change the display.
> > > The proposed implementation only returns a new ValueParser object
> > > whenever subkeys are allowed and found.
> >
> > same could be done with a Sub. granted, the implementation would have
> > to be smarter (i.e. search for a potential matching subkeys first)
> > than the last implementation for this, but there's no reason it can't
> > be done.
>
> Sure, but it all boils down to the decision to keep the foo.int syntax
> or not. If yes, then we definitely need a ValueParserSub object, if no,
> then returning either a new ValueParser (when subkeys are found) or the
> value in its integral type looks more natural to me.
yeah. seems like just a question of whether we want the foo.int
syntax or not. since it doesn't seem to be your itch, don't worry
about it. if i get around to it, i'll do it. if not, no big deal.
> 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.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
