Re: list renamed [EMAIL PROTECTED]
nabble http://www.nabble.com/forum/Search.jtp?query=velocity&local=y&forum=305&matchingForums=a On 11/10/06, Will Glass-Husain <[EMAIL PROTECTED]> wrote: Thanks, Joe. To the group. I'd like to check the new list gets picked up by all the search engines. To my mind, that includes mail-archives.apache.org/mod_mbox/ gmane.org www.mail-archives.com marc.theaimsgroup.com Are there others? WILL On 11/10/06, Joe Schaefer <[EMAIL PROTECTED]> wrote: > > This list has been renamed to [EMAIL PROTECTED] > > -- > Joe Schaefer > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - 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: Board report for Wednesday morning
Sure. let's see... Velocity Tools is working through a short backlog of patch contributions and bugs hoping to get a 1.3 version released before Velocity 1.5 goes final. It's also the plan to test VelocityStruts 1.3 against Struts 1.3 for compatibility. VelocityTools 1.3 is likely to be the last major release in the 1.x line, as i've already started planning for version 2. On 11/11/06, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: "Henri Yandell" <[EMAIL PROTECTED]> writes: I'll take care of Velocity. Nathan, can you write me a few lines for Velocity Tools? Thanks. Best regards Henning >VELOCITY-470 reminded me that you've not been added to >committee-info.txt, which means you've not been nudged for a board >report for Wednesday. If you can send one in it would be great. >Basically a status of how the move is going and any current >development activity (1.5 right?). >You'll need to report monthly for the next 3 months, settling into a >Feb, May, Aug, Nov cycle after that. >Hen >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design | Velocity - Turbine guy "Save the cheerleader. Save the world." - 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: svn commit: r477914 [1/26] - in /jakarta/velocity/tools/trunk: ./ docs/
Thanks! On 11/21/06, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] writes: >Author: henning >Date: Tue Nov 21 13:52:11 2006 >New Revision: 477914 >URL: http://svn.apache.org/viewvc?view=rev&rev=477914 >Log: >- fix all the copyright headers to match "new style apache licensing" >- add copyrights to files missing them >- remove superflous spaces >- format all java classes to have the package statement first thing > in the files >- make sure that all xml files have a leading - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r477767 - /jakarta/velocity/tools/trunk/src/java/org/apache/velocity/tools/view/tools/ParameterParser.java
Actually, i missed that one. Thanks! On 11/21/06, Will Glass-Husain <[EMAIL PROTECTED]> wrote: Nathan, You might know this, but the copyright no longer needs to go on top of source files. In fact, the required language has changed -- all releases issued after November 1, 2006 need to use the new language. The key change is there is no longer a copyright notice in the source file itself. (From Apache or from any contributor). http://www.apache.org/legal/src-headers.html Henning has a script to automatically convert the files. WILL On 11/21/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Author: nbubna > Date: Tue Nov 21 09:31:56 2006 > New Revision: 477767 > > URL: http://svn.apache.org/viewvc?view=rev&rev=477767 > Log: > update copyright date > > Modified: > jakarta/velocity/tools/trunk/src/java/org/apache/velocity/tools/view/tools/ParameterParser.java > > Modified: jakarta/velocity/tools/trunk/src/java/org/apache/velocity/tools/view/tools/ParameterParser.java > URL: http://svn.apache.org/viewvc/jakarta/velocity/tools/trunk/src/java/org/apache/velocity/tools/view/tools/ParameterParser.java?view=diff&rev=477767&r1=477766&r2=477767 > == > --- jakarta/velocity/tools/trunk/src/java/org/apache/velocity/tools/view/tools/ParameterParser.java (original) > +++ jakarta/velocity/tools/trunk/src/java/org/apache/velocity/tools/view/tools/ParameterParser.java Tue Nov 21 09:31:56 2006 > @@ -1,5 +1,5 @@ > /* > - * Copyright 2003-2005 The Apache Software Foundation. > + * Copyright 2003-2006 The Apache Software Foundation. > * > * Licensed under the Apache License, Version 2.0 (the "License"); > * you may not use this file except in compliance with the License. > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - 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: svn commit: r463298 [1/11] - in /jakarta/velocity/engine/trunk: ./ build/ build/xsl/ convert/ examples/anakia/build/ examples/anakia/xdocs/ examples/anakia/xdocs/about/ examples/anakia/xdocs/style
On 10/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: henning Date: Thu Oct 12 09:10:32 2006 New Revision: 463298 URL: http://svn.apache.org/viewvc?view=rev&rev=463298 Log: The folks over in li-la-legal land require all projects releasing after Nov 1st to update file headers to the new and approved policy at http://www.apache.org/legal/src-headers.html Fixes VELOCITY-462. Hey Henning, Wanna do this magic on VelocityTools? Or give me the script to do it? :) pretty please? thanks, nathan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: beta 2?
No objections! On 11/23/06, Will Glass-Husain <[EMAIL PROTECTED]> wrote: I was waiting for Gump to pass. Nice job on that. Unless there are any objections, let me put it together. WILL On 11/23/06, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: > Will, > > any date set / open issues for the beta 2? > > 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 guy > > "Save the cheerleader. Save the world." > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - 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: JDK for beta building
I'm mostly guessing here, but i'd suspect that building using 1.4 perhaps with target 1.3 would probably be best. Personally, i hope we won't be supporting 1.3 anymore after we get a final release of Velocity 1.5 out. On 11/25/06, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: [hermes fell into bl.spamcop.org *again* and I missed a couple of mail from the list. I'm catching up from the archive] I've built 1.5 beta 1 using 1.4.2_12. It still builds on JDK 1.3 but VelTools66TestCase throws a ClassCircularityError (huh?!?) 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 guy "Save the cheerleader. Save the world." - 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: is Texen orphaned?
On 11/25/06, Will Glass-Husain <[EMAIL PROTECTED]> wrote: Hi, Apparently, the main example in the Texen docs in Velocity 1.4 is broken. Geir broke it in early 2002, and Shinobu found and fixed the problem in early 2005. So while this has been fixed for 1.5, for the past couple of years the docs for the released version 1.4 have been wrong and no one has complained. http://issues.apache.org/bugzilla/show_bug.cgi?id=5183 http://issues.apache.org/bugzilla/show_bug.cgi?id=33206 http://jakarta.apache.org/velocity/docs/texen.html Also, there don't seem to be any experienced users on the mailing list. When a user recently asked about this no one responded until I had a chance to look into it. (I try to be responder-of-last-resort for these type of things). My point... Texen seems like an orphaned project. I'm guessing there's a few embedded users (Torque) so we shouldn't drop it. But I'd like to move it (after 1.5) to a separate subproject. Probably Anakia too. Comments? +1 They definitely need to be extricated from the core and moved to their own projects. WILL -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - 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: Extracting tokens
http://svn.apache.org/repos/asf/jakarta/velocity/engine/trunk/experimental/templatetool/
On 11/28/06, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
Hello,
I'm a velocity newbie. We have a portal framework with a propretary MVC.
We are thinking of using velocity for rendering the views. In our
publishing tool we need to extract all defined variables from a
template. Reading the documentation I cannot find this. A lot of
information exists to do the other way around (extract objects into
Context variables).
Anyone that could give me some pointers.
What I'm looking for really is someting like;
variables[] =
Velocity.getTemplate("mytemplate.vm").extractAllPossibleVariableNamesInT
emplate();
Cheers.
Peter
-
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: Extracting tokens
what do you mean by "dynamic template"?
On 11/28/06, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
Thanks alot! Is this possible to do with dynamic templates?
I havent seen a way for getting the Template object from a dynamic
template.
Peter Larnholt
-Original Message-----
From: Nathan Bubna [mailto:[EMAIL PROTECTED]
Sent: den 28 november 2006 17:44
To: Velocity Developers List
Subject: Re: Extracting tokens
http://svn.apache.org/repos/asf/jakarta/velocity/engine/trunk/experiment
al/templatetool/
On 11/28/06, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> I'm a velocity newbie. We have a portal framework with a propretary
MVC.
> We are thinking of using velocity for rendering the views. In our
> publishing tool we need to extract all defined variables from a
> template. Reading the documentation I cannot find this. A lot of
> information exists to do the other way around (extract objects into
> Context variables).
>
> Anyone that could give me some pointers.
>
> What I'm looking for really is someting like; variables[] =
> Velocity.getTemplate("mytemplate.vm").extractAllPossibleVariableNamesI
> nT
> emplate();
>
> Cheers.
> Peter
>
>
> -
> 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 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: Extracting tokens
ah. the StringResourceLoader should help you. it was recently added
to Velocity 1.5-dev and is included in the Velocity-1.5-beta2 release:
http://svn.apache.org/repos/asf/jakarta/velocity/engine/trunk/src/java/org/apache/velocity/runtime/resource/loader/StringResourceLoader.java
http://www.apache.org/dist/jakarta/velocity/beta/velocity-1.5-beta2/
http://issues.apache.org/jira/browse/VELOCITY-183
On 11/28/06, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
Hi,
Let me explain. I refer to "dynamic template" from the velocity
documentation (template = Velocity.getTemplate("mytemplate.vm")) //non
dynamic template;
I try to illustrate what I want to do with the following fictional code
snippet:
String string = "\nHello $apa";
attributes[] = Velocity.getTemplateFromStringReader(new
StringReader(string)).extractAllPossibleVariableNamesInTemplate();
for(int i=0;imailto:[EMAIL PROTECTED]
Sent: den 28 november 2006 18:28
To: Velocity Developers List
Subject: Re: Extracting tokens
what do you mean by "dynamic template"?
On 11/28/06, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Thanks alot! Is this possible to do with dynamic templates?
> I havent seen a way for getting the Template object from a dynamic
> template.
>
> Peter Larnholt
>
>
>
> -Original Message-
> From: Nathan Bubna [mailto:[EMAIL PROTECTED]
> Sent: den 28 november 2006 17:44
> To: Velocity Developers List
> Subject: Re: Extracting tokens
>
> http://svn.apache.org/repos/asf/jakarta/velocity/engine/trunk/experime
> nt
> al/templatetool/
>
> On 11/28/06, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > I'm a velocity newbie. We have a portal framework with a propretary
> MVC.
> > We are thinking of using velocity for rendering the views. In our
> > publishing tool we need to extract all defined variables from a
> > template. Reading the documentation I cannot find this. A lot of
> > information exists to do the other way around (extract objects into
> > Context variables).
> >
> > Anyone that could give me some pointers.
> >
> > What I'm looking for really is someting like; variables[] =
> > Velocity.getTemplate("mytemplate.vm").extractAllPossibleVariableName
> > sI
> > nT
> > emplate();
> >
> > Cheers.
> > Peter
> >
> >
> >
> > - 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 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 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: svn commit: r480868 -
In 1.3, i've been on something of a push to simplify the syntax and readability of how tools are used in templates. The idea is to make an elegant, simple VTL interface for these tools, even if it looks odd from a java perspective. Given the choice between: $context.context and $context.this i consider the latter to be the most elegant and self-explanatory. On 11/30/06, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] writes: >+public ViewContext getThis() getThis? Do we already have a "getContext()"? 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 guy "Save the cheerleader. Save the world." - 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: svn commit: r480849 -
technically, it would be an empty map not empty list, but even so, i'm
not sure about this. if we can say for sure that no one (especially
us) will ever want to tell the difference between an empty toolbox and
no toolbox being set, then it would be marginally simpler to ensure
that toolbox is never null.
at this point, it's not a great burden to always test for the
toolbox's presence and potentially provides more a more useful
interface.
in other words, i'll think about this...
On 11/30/06, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] writes:
>+public Map getToolbox()
>+{
>+if (this.toolbox != null)
>+{
>+return Collections.unmodifiableMap(this.toolbox);
>+}
Wouldn't it be better (and probably remove a lot of these tests) to make sure
that the toolbox can never be null (but contains an empty List?).
>+return null;
> }
I'd prefer Collections.EMPTY_LIST. Removes the necessity of always
checking for null.
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 guy
"Save the cheerleader. Save the world."
-
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]
Veltools 1.3 - Showcase Example
hey folks, you probably noticed that i just checked in a new example app for VelocityTools to replace the "layout" example. this is something i've been thinking of doing for years, and finally got around to doing. basically, it provides demonstrations (most of which are interactive) of all the Generic and VelocityView tools we have. there is certainly plenty of room for improvement in the usefulness of the examples, but i figured it was time to get it out and see what ya'll think. if some of you were willing to check it out and give it a test run, i'd love to get some feedback. It's easy: - check out the latest revision of VelocityTools from svn - run 'ant showcase' - follow the instructions printed out at the end thanks! p.s. VelocityView and the Generic Tools are largely ready for a 1.3 release. if anyone wants to help me get 1.3 out the door, i'd love some help updating the VelocityStruts dependencies and making sure VelocityStruts is fully compatible with the Struts 1.3.x series. (Marino?) Please note that with Tiles going independent as a TLP and Struts 2.x soon on the way, the future of VelocityStruts beyond VelocityTools 1.3 is very much in question. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Veltools 1.3 - Showcase Example
On 12/9/06, Claude Brisson <[EMAIL PROTECTED]> wrote:
Looks very cool. That's a lot of work!
Some remarks:
- Alternator: we'd like the hand-made examples to return several
values... not that important.
not sure i understand...
- Date
$date.getDay("[ ]")
$date.getMont("[ ]")
$date.getYear("[ ]")
those three methods take a Date argument, so the text field doesn't help
much... in fact we should also have string versions for those three
methods (that rely on toDate()).
actually, those three methods take an Object argument which is
automatically fed through toCalendar(Object) which eventually
delegates to toDate(Object) whose last resort is parsing the String
value of the Object. So, they can be used as is. However, i agree
that they're not especially useful like this. i'll drop the quotes
around the DateTool function examples.
- Cookie
$cookie.all should be displayed with a #foreach, so that we actually see
the cookies. Minor.
can do.
The CSS layout rocks! Maybe we can use it by default.
i guess we could. hadn't really thought about it.
Last but not least, this webapp could serve as a basis for testcases.
Talking about this, I built a testcase for Velosurf (both whitebox and
blackbox using Jetty), so maybe I can work on this for the Tools.
interesting idea. would this be automated or automate-able?
Claude
Le vendredi 08 décembre 2006 à 12:02 -0800, Nathan Bubna a écrit :
> hey folks,
>
> you probably noticed that i just checked in a new example app for
> VelocityTools to replace the "layout" example. this is something i've
> been thinking of doing for years, and finally got around to doing.
>
> basically, it provides demonstrations (most of which are interactive)
> of all the Generic and VelocityView tools we have. there is certainly
> plenty of room for improvement in the usefulness of the examples, but
> i figured it was time to get it out and see what ya'll think.
>
> if some of you were willing to check it out and give it a test run,
> i'd love to get some feedback.
>
> It's easy:
> - check out the latest revision of VelocityTools from svn
> - run 'ant showcase'
> - follow the instructions printed out at the end
>
> thanks!
>
> p.s. VelocityView and the Generic Tools are largely ready for a 1.3
> release. if anyone wants to help me get 1.3 out the door, i'd love
> some help updating the VelocityStruts dependencies and making sure
> VelocityStruts is fully compatible with the Struts 1.3.x series.
> (Marino?) Please note that with Tiles going independent as a TLP and
> Struts 2.x soon on the way, the future of VelocityStruts beyond
> VelocityTools 1.3 is very much in question.
>
> -
> 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 unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Veltools 1.3 - Showcase Example
On 12/11/06, Claude Brisson <[EMAIL PROTECTED]> wrote:
Le lundi 11 décembre 2006 à 09:45 -0800, Nathan Bubna a écrit :
> On 12/9/06, Claude Brisson <[EMAIL PROTECTED]> wrote:
> > Looks very cool. That's a lot of work!
> >
> > Some remarks:
> >
> > - Alternator: we'd like the hand-made examples to return several
> > values... not that important.
>
> not sure i understand...
Just that when I give the alternator ['blue','red'], I'd like to see
"blue, red, blue" rather than just "blue" (that is, it should be
evaluated several times). Really not that important.
nah. i'd like to keep the function demos realistic. things like that
can go in a "full demo" at the bottom, such as the ones that
IteratorTool or SearchTool have. i've actually been adding a few more
of these and will check them in shortly.
> > - Date
> > $date.getDay("[ ]")
> > $date.getMont("[ ]")
> > $date.getYear("[ ]")
> >
> > those three methods take a Date argument, so the text field doesn't help
> > much... in fact we should also have string versions for those three
> > methods (that rely on toDate()).
>
> actually, those three methods take an Object argument which is
> automatically fed through toCalendar(Object) which eventually
> delegates to toDate(Object) whose last resort is parsing the String
> value of the Object. So, they can be used as is. However, i agree
> that they're not especially useful like this. i'll drop the quotes
> around the DateTool function examples.
Ok, I browsed the sources too fast. But I did so after having tried 3 or
4 different syntaxes in the field getDay("[]"), which every newcomer
will do as well... This time I tracked the trail to its very end and saw
that the default behaviour is to fetch a date time medium format, which
means the only string that works is "Dec 11, 2006 9:07:05 PM", wich is
ok as a default formatting string but not so smart when it comes to
parsing... We should include some guessing algorithm, and I'm sure we
can easily find a pretty one around there in the apache codebase just
waiting for us.
that would be cool. the string -> date parsing of
DateTool.toDate(Object) is simplistic at best by default. if you use
the same format for output and input, then you can configure DateTool
to use that as the default. otherwise, you should use
DateTool.toDate(String format, Object date) or one of the other
toDate() methods.
so basically, there's plenty of capability in DateTool, but only
limited "magic". improvements are welcome!
> > - Cookie
> >
> > $cookie.all should be displayed with a #foreach, so that we actually see
> > the cookies. Minor.
>
> can do.
>
> >
> > The CSS layout rocks! Maybe we can use it by default.
>
> i guess we could. hadn't really thought about it.
>
> > Last but not least, this webapp could serve as a basis for testcases.
> > Talking about this, I built a testcase for Velosurf (both whitebox and
> > blackbox using Jetty), so maybe I can work on this for the Tools.
>
> interesting idea. would this be automated or automate-able?
Could not be more automated. Downloads needed jars, starts Jetty,
submits forms, compares results, stops Jetty. And what is cool is that
you can manually launch the ant target "start-jetty" and point your
browser to -let's say, localhost:8081, when you need to debug the
testcases themselves.
It uses HttpUnit to do so. The HttpUnit licence is not an ASF one, but
is clearly compatible (never seen a shorter licence:
http://httpunit.sourceforge.net/doc/license.html ) and already used by
several apache projects.
sounds awesome! i'd definitely be interested in exploring such things.
Claude
> >
> > Claude
> >
> > Le vendredi 08 décembre 2006 à 12:02 -0800, Nathan Bubna a écrit :
> > > hey folks,
> > >
> > > you probably noticed that i just checked in a new example app for
> > > VelocityTools to replace the "layout" example. this is something i've
> > > been thinking of doing for years, and finally got around to doing.
> > >
> > > basically, it provides demonstrations (most of which are interactive)
> > > of all the Generic and VelocityView tools we have. there is certainly
> > > plenty of room for improvement in the usefulness of the examples, but
> > > i figured it was time to get it out and see what ya'll think.
> > >
> > > if some of you were willing to check it out and give it a test run,
> > > i'd love to get some feedback.
>
Re: Veltools 1.3 - Showcase Example
On 12/10/06, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: Claude Brisson <[EMAIL PROTECTED]> writes: >> p.s. VelocityView and the Generic Tools are largely ready for a 1.3 >> release. if anyone wants to help me get 1.3 out the door, i'd love >> some help updating the VelocityStruts dependencies and making sure >> VelocityStruts is fully compatible with the Struts 1.3.x series. I pimped up the velocity gump build a bit; if it passes the next cycle then I will switch from the packaged struts to struts-action, struts-taglib, struts-tiles dependency; if that passes that should be a good sign that vel-tools works with struts 1.3. thanks! that'll be very helpful. How about releasing a beta to get people ready for this? first i want to upgrade the struts dependencies. right now the build still uses the 1.2.x series. then we'll push a beta out. 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 guy "Save the cheerleader. Save the world." - 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: Veltools 1.3 - Showcase Example
I've debated that myself a dozen times. The main issue is that i've not had cause to use that particular function myself. I just added the getMonth() and getDay() methods as logical fellows of the getYear() method that i really wanted. I could easily be swayed either direction, and either way, the documentation definitely should be improved. Anyone else have thoughts on this one? I'm actually leaning back toward the normal 1-based month and away from the j.u.Calendar's 0-based month right now. While the DateTool is in the generic package, it's primary use is probably in a view layer of an application, where it is more natural to present the human month value rather than the machine one. On 12/11/06, Claude Brisson <[EMAIL PROTECTED]> wrote: Le lundi 11 décembre 2006 à 12:47 -0800, Nathan Bubna a écrit : > so basically, there's plenty of capability in DateTool, but only > limited "magic". improvements are welcome! Ah, one last thing (for now) about the DateTool that I forgot to mention: are we sure we want to keep the jdk zero-based behaviour for the month? If so we should recall that in the docs, rather twice than once... Claude > > > > - Cookie > > > > > > > > $cookie.all should be displayed with a #foreach, so that we actually see > > > > the cookies. Minor. > > > > > > can do. > > > > > > > > > > > The CSS layout rocks! Maybe we can use it by default. > > > > > > i guess we could. hadn't really thought about it. > > > > > > > Last but not least, this webapp could serve as a basis for testcases. > > > > Talking about this, I built a testcase for Velosurf (both whitebox and > > > > blackbox using Jetty), so maybe I can work on this for the Tools. > > > > > > interesting idea. would this be automated or automate-able? > > > > Could not be more automated. Downloads needed jars, starts Jetty, > > submits forms, compares results, stops Jetty. And what is cool is that > > you can manually launch the ant target "start-jetty" and point your > > browser to -let's say, localhost:8081, when you need to debug the > > testcases themselves. > > > > It uses HttpUnit to do so. The HttpUnit licence is not an ASF one, but > > is clearly compatible (never seen a shorter licence: > > http://httpunit.sourceforge.net/doc/license.html ) and already used by > > several apache projects. > > sounds awesome! i'd definitely be interested in exploring such things. > > > Claude > > > > > > > > > > Claude > > > > > > > > Le vendredi 08 décembre 2006 à 12:02 -0800, Nathan Bubna a écrit : > > > > > hey folks, > > > > > > > > > > you probably noticed that i just checked in a new example app for > > > > > VelocityTools to replace the "layout" example. this is something i've > > > > > been thinking of doing for years, and finally got around to doing. > > > > > > > > > > basically, it provides demonstrations (most of which are interactive) > > > > > of all the Generic and VelocityView tools we have. there is certainly > > > > > plenty of room for improvement in the usefulness of the examples, but > > > > > i figured it was time to get it out and see what ya'll think. > > > > > > > > > > if some of you were willing to check it out and give it a test run, > > > > > i'd love to get some feedback. > > > > > > > > > > It's easy: > > > > > - check out the latest revision of VelocityTools from svn > > > > > - run 'ant showcase' > > > > > - follow the instructions printed out at the end > > > > > > > > > > thanks! > > > > > > > > > > p.s. VelocityView and the Generic Tools are largely ready for a 1.3 > > > > > release. if anyone wants to help me get 1.3 out the door, i'd love > > > > > some help updating the VelocityStruts dependencies and making sure > > > > > VelocityStruts is fully compatible with the Struts 1.3.x series. > > > > > (Marino?) Please note that with Tiles going independent as a TLP and > > > > > Struts 2.x soon on the way, the future of VelocityStruts beyond > > > > > VelocityTools 1.3 is very much in question. > > > > > > > > > > - > >
Re: Veltools 1.3 - Showcase Example
Ok. Make sure you move it to the Struts 1.x head, and not Struts 2.x. They are entirely different frameworks. On 12/11/06, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: "Nathan Bubna" <[EMAIL PROTECTED]> writes: velocity-tools builds again (see http://vmgump.apache.org/gump/public/velocity-tools/velocity-tools/index.html), I will move it to the struts HEAD today; let's see how it works out. :-) Best regards Hennig >On 12/10/06, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: >> Claude Brisson <[EMAIL PROTECTED]> writes: >> >> >> p.s. VelocityView and the Generic Tools are largely ready for a 1.3 >> >> release. if anyone wants to help me get 1.3 out the door, i'd love >> >> some help updating the VelocityStruts dependencies and making sure >> >> VelocityStruts is fully compatible with the Struts 1.3.x series. >> >> I pimped up the velocity gump build a bit; if it passes the next cycle >> then I will switch from the packaged struts to struts-action, >> struts-taglib, struts-tiles dependency; if that passes that should be >> a good sign that vel-tools works with struts 1.3. >thanks! that'll be very helpful. >> How about releasing a beta to get people ready for this? >first i want to upgrade the struts dependencies. right now the build >still uses the 1.2.x series. then we'll push a beta out. >> 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 guy >> >> "Save the cheerleader. Save the world." >> >> - >> 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] -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design | Velocity - Turbine guy "Save the cheerleader. Save the world." - 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: Velocity Site - Preview
I like the direction this is heading, especially as laid out here: http://wiki.apache.org/jakarta-velocity/VelocitySite I'll help with the Tools docs at least. But it might be a week or so. I've gotta get some other work done first. On 12/11/06, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: [Hm. I could have sworn I've sent this out already. Seems it never made it] To let you know what I've been busy over the weekend: I've been wrestling with maven 2 and site building. A preview of where I intent to go is currently visible at http://velocity.apache.org/staging/ Comments, Criticism, Help, Patches wanted. Most of that is already in the site svn; I've created a custom skin for the site, that is not yet there. 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 guy "Save the cheerleader. Save the world." - 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: Velocity ImportTool Question
On 12/14/06, Claude Brisson <[EMAIL PROTECTED]> wrote: (really moving it to the dev list...) > Yeah, ever since Tomcat 5.5 made the obnoxious decision to use > commons-logging (which i could have sworn was supposed to be just a > log wrapper/adapter) as a full-on logging solution responsible for > generating servlet log files and printing to them, our former method > of handling things (pointing all commons-logging messages to > Velocity's LogSystem and pointing Velocity's LogSystem at the provided > servlet log) fails with an infinite loop. Yes, I remember that. > It's been a while since i was fully familiar with the nuances of this > issue, but i believe things are currently as follows: > > Velocity's LogSystem is being pointed at the servlet log, and all > VelocityTools messages are being sent to commons-logging. If you are > using Tomcat 5.5.x, then this works fine as the VelocityTools and > Velocity methods both end up in the servlet log. If you are using an > older Tomcat or a different servlet container, then you will not get > VelocityTools messages in your servlet log without actively > configuring commons-logging to print to Velocity's LogSystem (see the > LogSystemCommonsLog class for details). > > Once Velocity 1.5 is released, it is my intent to push forward with > work on VelocityTools 2.x and leave the VelocityTools 1.x series > behind. VelocityTools 2.x will require Velocity 1.5+ as a dependency > (among other major changes). Among the benefits of this will be the > ability to drop commons-logging from VelocityTools and use the new and > improved LogChute support in Velocity 1.5+. This will once more > allow us to funnel all Velocity and VelocityTools messages to the same > place, regardless of which servlet container you are using. Yes, but my concern was that ToolboxManagers and logging tools directly uses import org.apache.commons.logging.Log via LogFactory.getLog(ServletToolboxManager.class) and not via LogSystemCommonsLog. No, the way we are using commons-logging is the appropriate way. The whole idea of it is/was that you use the LogFactory and Log interfaces so that you can easily swap out implementations of Log (like the LogSystemCommonsLog). You are not supposed to use the implementations directly. If you do, then you might as well do what i plan to do in 2.x and ditch commons-logging altogether. So without Tomcat 5.5.x and any proper commons-loggin configuration, you'll see the VVS logs allright (letting you think that tools logging is ok) but no error message from the servlet toolbox manager. No, what you are seeing in such a case is just *Velocity* log messages. The VelocityViewServlet does precious little logging of its own, pretty much only in cases of major initialization errors. Of course, it does log directly to the servlet log. This is because in such cases it may be that Velocity failed to init and we can't log there. I'm not enough familiar with this problem and with commons-logging to know which solution would be best : - implement a LogFactory ? - create setLog(Log) methods (introspected for tools the same way as "init" and "configure") ? No, this is not the way to use commons-logging. Here are the options: a) Improve documentation to make it clear that those not using Tomcat 5.5+ must add a commons-logging.properties file to the root of the classpath that contains the following line: org.apache.commons.logging.Log=org.apache.velocity.tools.log.LogSystemCommonsLog or b) by default, point all commons-logging messages to LogSystemCommonsLog (as i believe we used to do), but stop having Velocity's LogSystem use the ServletLogger by default. this will mean that all log output for Velocity and VelocityTools will follow Velocity's default logging configuration (unless users change that via velocity.properties). but I definitely think we should do sthing about this for the 1.3 release. The options above are our only options for improving the situation in 1.3. Claude > In short, the Tomcat people did what Geir could not and successfully > convinced me that it is a very bad idea to use commons-logging in a > webapp framework. > > > Claude > > > > Le jeudi 14 décembre 2006 à 12:30 -0800, Nathan Bubna a écrit : > > > On 12/14/06, Tod Thomas <[EMAIL PROTECTED]> wrote: > > > > Nathan Bubna wrote: > > > > > and what does your web.xml have? > > > > > > > > Sorry, plain vanilla: > > > > > > > > > > > > > > > > velocity > > > > > > > > org.apache.velocity.tools.view.servlet.VelocityViewServlet > > > > > > > > > > > > > > > > org.
Re: Velocity Site - Preview
First, general thoughts I would like to see our web site reflect our charter in the sense that the Velocity Engine is always prominent and pre-eminent. It is a requirement that the other subprojects be dependent on that "core" center pole, otherwise the umbrella will become a mere sack. I'm not sure how best to represent this on our front page, but i think it is important that that be the case. Apart from this emphasis, i generally agree with Henning's thoughts on the front page. Regarding "Velocity in a webapp"... I like having a front page link to this guide. Like Will, it feels like there have been fewer simplistic questions on this since we added that page. I also think it would be good to have a link right above or below it that quickly tells how to use Velocity outside a webapp. The title of this would probably depend on the examples created for it. Which, by the way, i'm not sure we have any good, simple, easy-to-get-started-with, examples of this. Maybe i'll take a shot at that before 1.5 goes final... On 12/18/06, Claude Brisson <[EMAIL PROTECTED]> wrote: Some remarks / suggestions... Le dimanche 17 décembre 2006 à 14:10 +0100, Henning Schmiedehausen a écrit : > > New users need to know > > --> What the heck is Velocity? > > +1. So what is it? Is it a templating engine? A toolbox for a templating > engine? What is the "Velocity project". I'm struggling with that answer > myself. ;-) Apache Velocity is the Velocity template engine and a set of complementary and closely-tied projects. Also (more pragmatic... ahum... not purely aesthetic) the "project" (in the title) vs "projects" (in the menu) - what about changing the title to sthing like "the Velocity Umbrella" or "the Velocity Connection"? i think we should generally refer to the Apache Velocity TLP as "Apache Velocity" and put no further nouns into it. If we need a generic noun as a synonym, i'd stick with "project" as that is how the ASF views us collectively. > > --> What's the latest version? > > +1. Latest Version of what? We already have three sub projects. What about including validation/compatibility/voting steps for subprojects, so that a particular version of a subproject is officially linked with every engine release? Hence, there would be a "Velocity package" version, the same as the core, and newcomers can avoid dealing with subproject versions. Advanced users who want to mix versions can fetch infos on subprojects pages and use subversion. I think this is a great idea. Not a high priority, but definitely something i'd like to work on once we get the TLP move completed and Velocity Engine 1.5 and VelocityTools 1.3 out the door. At this point, all VelocityTools releases are compatible with Velocity Engine 1.3+. Starting with VelocityTools 2.x, we'll probably require Velocity Engine 1.5+. It would be fantastic to have some simple way of expressing on overview of all these dependencies on our web site, especially as we bring in other subprojects and push Anakia and Texen out of the Engine. Claude - 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: svn commit: r487325 - in /velocity/tools/trunk: build.properties build.xml
On 12/15/06, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] writes: >- upgrade dependencies for Struts 1.3.x series >- separate example runtime deps from compile time deps >- upgrade ant download targets to work with and use maven2 repo >- misc other updates to build system Very nice. The struts Gump build BTW is broken beyond repair so I've given up here ATM and kept it running with packaged-struts (which probably now broke velocity-tools because you now require three jars. I will fix it sometime over the weekend. Since you didn't get to it yet, i took the liberty of attempting to fix it myself. I dropped the antlr dependency since we didn't really need it and pointed the struts-core.jar, struts-taglib.jar, and struts-tiles.jar all at the packaged-struts jar. I don't know if this will actually make Gumps ant run succeed, and i doubt that the example struts.war produced by Gump's ant build will be fully functional, if that matters. The other option might be to just point at the "jar" target instead of the "all" target, but i wouldn't want to leave it that way long term. Hopefully someone will update Gump's struts.xml to work with Struts 1.3.5's multiple artifacts. velocity-tools builds fine BTW with JDK 6. cool. :) 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 guy "Save the cheerleader. Save the world." - 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]
[VOTE] Release VelocityTools 1.3-beta1
Ok, i've got all the dependencies upgraded. The ant build system seems to be working great. I've attempted to get the Gump build working again, but that shouldn't hold up a release anyway. So, i think we're ready for a beta of VelocityTools 1.3: [ ] +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 vote will close sometime after Thursday 12pm PST (roughly 72 hours). :) My vote is +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release VelocityTools 1.3-beta1
On 12/18/06, Will Glass-Husain <[EMAIL PROTECTED]> wrote: I vote +1. It's a good trend to do more frequent releases as things improve. By the way, I looked at the JIRA changelog to see what was new: https://issues.apache.org/jira/browse/VELTOOLS?report=com.atlassian.jira.plugin.system.project:roadmap-panel How would you summarize this release vs. 1.2? Build cleanup, dependency upgrades, bug fixes? Or are there other substantial improvements? Big things: - ViewTool and Configurable interfaces are no longer necessary - Syntax simplifications - New showcase example - Request-scoped tools can be restricted according to the request path - new ContextTool Little things (to me): - better build process - bug fixes (esp. in ImportSupport) - more configurable defaults in generic tools - new functions in several tools (esp. LinkTool) WILL On 12/18/06, Nathan Bubna <[EMAIL PROTECTED]> wrote: > Ok, i've got all the dependencies upgraded. The ant build system seems > to be working great. I've attempted to get the Gump build working > again, but that shouldn't hold up a release anyway. > > So, i think we're ready for a beta of VelocityTools 1.3: > > [ ] +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 vote will close sometime after Thursday 12pm PST (roughly 72 hours). :) > > My vote is +1 > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - 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: [VOTE] Release VelocityTools 1.3-beta1
On 12/18/06, Claude Brisson <[EMAIL PROTECTED]> wrote: +1, with the only exception that we should add to the docs the mention you suggested about the commons-logging.properties file (btw, thanks for clarifying the situation for me!) - this was your a) proposal. sure. just gotta figure out where best to do that now... Claude Le lundi 18 décembre 2006 à 12:06 -0800, Nathan Bubna a écrit : > Ok, i've got all the dependencies upgraded. The ant build system seems > to be working great. I've attempted to get the Gump build working > again, but that shouldn't hold up a release anyway. > > So, i think we're ready for a beta of VelocityTools 1.3: > > [ ] +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 vote will close sometime after Thursday 12pm PST (roughly 72 hours). :) > > My vote is +1 > > - > 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 unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release VelocityTools 1.3-beta1
On 12/21/06, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: "Nathan Bubna" <[EMAIL PROTECTED]> writes: >Ok, i've got all the dependencies upgraded. The ant build system seems >to be working great. I've attempted to get the Gump build working >again, but that shouldn't hold up a release anyway. >So, i think we're ready for a beta of VelocityTools 1.3: >[X] +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 __ (I'd like to see some tests to build it with 1.2.x and maybe 1.1, too because sometimes people are stuck on these Struts versions. Apart from that: Great work!) I'd love to see that too. :) However, i'm no longer using VelocityStruts. My time/interest in that part is very limited. Here's the good news though: we didn't have to change any tool code to make the VelocityStruts tools work with 1.3. This means they're definitely still compatible with 1.2 at this point. If/when i get around to https://issues.apache.org/jira/browse/VELTOOLS-58, then i'll try to remember to test against Struts 1.2. No promises though. I have no idea about Struts 1.1 compatibility, and i'm not sure i care to support anyone that many years behind. They can keep using VelocityTools 1.1 just fine. Otherwise, folks are welcome to volunteer to help with that! 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 guy "Save the cheerleader. Save the world." - 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]
[RESULT] [VOTE] Release VelocityTools 1.3-beta1
And the final tally is... PMC +1's - Nathan Bubna - Will Glass-Husain - Marino A Jonsson - Henning Schmiedehausen Committer +1's - Claude Brisson Feedback - Claude wants the logging issue better documented - Henning wants BC tests for Struts 1.2 and maybe Struts 1.1 My plan - I'm away from my home desk, but i'll try to get the docs updated a bit more before rolling a release in the next few days. Depends on the flakiness of the wifi here. :) Once the beta is out, i plan to work on the remaining bugs scheduled for 1.3 and updating the documentation with the new features and changes. Assuming there are no major issues found, i'd love to get an RC out by January's end. Help would be greatly appreciated! :) Especially from any who think it's "about time" we get this version out. ;-) I'll admit, i'm largely excited to get this out so i can start working on the "cool stuff" i want to do in 2.0. But i also want 1.3 to be of better quality than the previous versions since it may take a while to get 2.0 in shape. So, i'd really appreciate if ya'll can try this out and perhaps help a bit too. :) On 12/21/06, Nathan Bubna <[EMAIL PROTECTED]> wrote: On 12/21/06, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: > "Nathan Bubna" <[EMAIL PROTECTED]> writes: > > >Ok, i've got all the dependencies upgraded. The ant build system seems > >to be working great. I've attempted to get the Gump build working > >again, but that shouldn't hold up a release anyway. > > >So, i think we're ready for a beta of VelocityTools 1.3: > > >[X] +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 __ > > (I'd like to see some tests to build it with 1.2.x and maybe 1.1, too > because sometimes people are stuck on these Struts versions. Apart > from that: Great work!) I'd love to see that too. :) However, i'm no longer using VelocityStruts. My time/interest in that part is very limited. Here's the good news though: we didn't have to change any tool code to make the VelocityStruts tools work with 1.3. This means they're definitely still compatible with 1.2 at this point. If/when i get around to https://issues.apache.org/jira/browse/VELTOOLS-58, then i'll try to remember to test against Struts 1.2. No promises though. I have no idea about Struts 1.1 compatibility, and i'm not sure i care to support anyone that many years behind. They can keep using VelocityTools 1.1 just fine. Otherwise, folks are welcome to volunteer to help with that! > 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 guy > > "Save the cheerleader. Save the world." > > - > 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: docs / javadocs in the tools svn?
The reasons for this are primarily historical at this point. I believe the original motivation was to make it easy to update the public site by just doing svn update. At this point, i guess i'm +0.1 on removing the generated documentation from version control in this version. Once we have velocity.apache.org up and a totally different way of building the site, then i'll be +1. On 12/22/06, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: Hi, I noticed that the Javadocs and docs output are checked into SVN. Besides from giving me a big number of M(odified) files from SVN when I do svn status after building the tools, do we need that? We do build these files with a regular build anyway and people actually getting the source code from SVN probably know their way around enough to build these themselves. I'm +1 for removing the generated files from SVN. 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 guy "Save the cheerleader. Save the world." - 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: [jira] Commented: (VELOCITY-502) Skip jar verification unless "force.jar.loading" is true
On 12/23/06, Claude Brisson <[EMAIL PROTECTED]> wrote: Le samedi 23 décembre 2006 à 15:45 -0800, Nathan Bubna (JIRA) a écrit : > I don't really care. Both have advantages, both will work fine. If you're going to do the work, i say you should get to decide. :) That's the "new commiter" syndrom... feeling like having to ask before doing nasty things inside the sourcetree... it will pass... ;-) :) well, in your defense, it is polite to give a heads up before acting on something that was being debated. of course, for me there's few arguments stronger than action, especially when it comes to something inconsequential like this. Claude > > > Skip jar verification unless "force.jar.loading" is true > > > > > > Key: VELOCITY-502 > > URL: http://issues.apache.org/jira/browse/VELOCITY-502 > > Project: Velocity > > Issue Type: Improvement > > Components: Build > >Affects Versions: 1.5 beta2 > > Environment: all > >Reporter: Claude Brisson > >Priority: Minor > > Fix For: 1.5 > > > > Attachments: jar-downloading.patch > > > > > > When the www.iblibo.org/maven repository is down (as it seems right now, at least from here), or when you want to work form an unconnected place (yes, it still exists...), build fails because ant wants to check every jar timestamp. > > The attached patch modifies this behaviour: if a jar file is already present, the repository is not hit at all (why would we have to check any timestamp anyway since version numbers are present inside filenames?!). > > The new force.jar.loading property forces reloading of jar files. > - 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: Velocity Site - Almost ready to go
On 12/30/06, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: Hi, after some amount of Maven wrestling, I have a new version of the intended Velocity Project site put at http://people.apache.org/~henning/site/ This is looking great! First some good and bad news: Good news: The Site builds now very smoothly with Maven 2 and the Velocity Doxia Plugin. Bad news: It does not do so with Maven 2.0.4. It needs the current 2.0 SNAPSHOT. Good news: It is not our fault. It is Maven's fault (see http://svn.apache.org/repos/asf/velocity/site/README.txt) Better news: There is a workaround for Maven 2.0.4. It is kludgy but works. Even better news: For those of us that are maven impaired, I'm willing to build and deploy the site on demand. Maven 2.0.5 should be out in January, afterwards there is no excuse. ;-) Thanks! :) I've read all of your suggestions and I agree with most of them. There will be a lot of shuffling around in the next few days / weeks, but the most important thing for us are IMHO: - We final sever our ties with Jakarta - We offer a welcome page, a download page and links to the projects - We have stable locations for release and development docs. - We have an easy and reproducable process to build the site Everything else can come later, can be reshuffled or rewritten. The one thing that I am missing from the site is the news page. I have some outline for a maven plugin that can read structured news items (some simple XML format) and provide * A news page (all articles) * A Doxia macro that displays the newest few items on the first page * A RSS feed * Aggregation of sub-feeds (think Engine Feed, Tools Feed aggregated on the TLP site). That sounds complicated but the maven 2 plugins make this actually very simple and I intend to get this done before 2007. ;-) Very cool. So what is in the site now (what has changed from the last version): - Project page and menu is gone. We can revive that later or just leave it. If we make the engine a first class citizen, then we will have some general engine docs in the wrapper site anyway, so why bother? - Moved Releases up, right after General - Added a "Reference library" link for often referenced documents. - Added a "Board reports" menu and the existing two board reports. - Filled most of the menu points with some content. The "Who we are" and "Contact us" pages are generated from POM information. If you want to change your information on the site, please update the site POM (https://svn.apache.org/repos/asf/velocity/site/site/pom.xml) - "How it works" is basically a rip off from Jakarta. We should evaluate these documents over time to see where they fit us and where not. Later. - The other "Apache Reference" links are unchanged. Feel free to do so. - Added "Site building" link which describes the process. This is the README from the site converted to APT (APT is fun. Take a look at it. Sooo much better than xdoc!) But is APT as timeless as XML? I'll take a look at it again, but i worry that the format will not gain the longevity of XML. And i'm sure it will never gain the popularity and flexibility. The great benefit of xdoc was that it was just xml, for which there are many tools and parsers and probably always will be. Note: that the above is meant as loyal opposition. i can't imagine ever even thinking of vetoing any work anyone does on documentation. on that matter, them that do the work not only make the decision, but are also my personal heroes. :) Please take a look at the new site. If no objections come up, I will move this in sometime early next week (tuesday or wednesday). Until then I will have the news plugin ready and in place. I'l try and update things with an announcement about tools 1.3-beta1 soon. It's up on the servers, i just need to update download pages and whatnot, then announce. I meant to do it last week, but the holidays won out. Afterwards I will work on the actual Engine docs. I expect some doc shuffling between the wrapper and the engine site and they will probably be in "construction site" mode for a while. Get ready for Velocity 1.5 in '07. ;-) (at what point will we make the vapor ware top 10 BTW?) We haven't already?? 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 guy "Save the cheerleader. Save the world." - 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: [RESULT] [VOTE] Release VelocityTools 1.3-beta1
Hmm. I didn't notice the beta directory. Yeah, i can move 1.3-beta1,
but i don't approve of the distinction. Alphas and betas are
releases. If we vote on it and announce it (as i will as soon as i
can get my feet under myself after the holidays and update all the
download links), then it is a release.
So, before i move it over, let's get our nomenclature straight here
and change the "release" folder to "stable" or "final" or something
like that, so that it is clear that that is the place to put and find
all final releases.
On 1/2/07, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote:
"Nathan Bubna" <[EMAIL PROTECTED]> writes:
(First: Happy new year, Velocity folks!)
Hi Nathan,
I somehow missed that you have put the 1.3 beta-1 release archives
onto www.apache.org/dist.
As this is a beta version and not a release, the location is a bit
unfortunate. I'd very much prefer if you could move the 1.3-beta-1 out
of the release directory and into beta/1.3-beta1, similar to the
engine (which has also a beta and a release directory). And also
restore the "current" links back to Tools 1.2.
The offical "stable" release is currently still 1.2, so we should not
upset people downloading it. :-)
Thank you
Henning
[...]
>And the final tally is...
>PMC +1's
> - Nathan Bubna
> - Will Glass-Husain
> - Marino A Jonsson
> - Henning Schmiedehausen
>Committer +1's
> - Claude Brisson
>Feedback
> - Claude wants the logging issue better documented
> - Henning wants BC tests for Struts 1.2 and maybe Struts 1.1
>My plan
> - I'm away from my home desk, but i'll try to get the docs updated a
>bit more before rolling a release in the next few days. Depends on
>the flakiness of the wifi here. :)
>Once the beta is out, i plan to work on the remaining bugs scheduled
>for 1.3 and updating the documentation with the new features and
>changes. Assuming there are no major issues found, i'd love to get an
>RC out by January's end. Help would be greatly appreciated! :)
>Especially from any who think it's "about time" we get this version
>out. ;-) I'll admit, i'm largely excited to get this out so i can
>start working on the "cool stuff" i want to do in 2.0. But i also
>want 1.3 to be of better quality than the previous versions since it
>may take a while to get 2.0 in shape. So, i'd really appreciate if
>ya'll can try this out and perhaps help a bit too. :)
>On 12/21/06, Nathan Bubna <[EMAIL PROTECTED]> wrote:
>> On 12/21/06, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote:
>> > "Nathan Bubna" <[EMAIL PROTECTED]> writes:
>> >
>> > >Ok, i've got all the dependencies upgraded. The ant build system seems
>> > >to be working great. I've attempted to get the Gump build working
>> > >again, but that shouldn't hold up a release anyway.
>> >
>> > >So, i think we're ready for a beta of VelocityTools 1.3:
>> >
>> > >[X] +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 __
>> >
>> > (I'd like to see some tests to build it with 1.2.x and maybe 1.1, too
>> > because sometimes people are stuck on these Struts versions. Apart
>> > from that: Great work!)
>>
>> I'd love to see that too. :) However, i'm no longer using
>> VelocityStruts. My time/interest in that part is very limited.
>> Here's the good news though: we didn't have to change any tool code
>> to make the VelocityStruts tools work with 1.3. This means they're
>> definitely still compatible with 1.2 at this point. If/when i get
>> around to https://issues.apache.org/jira/browse/VELTOOLS-58, then i'll
>> try to remember to test against Struts 1.2. No promises though.
>>
>> I have no idea about Struts 1.1 compatibility, and i'm not sure i care
>> to support anyone that many years behind. They can keep using
>> VelocityTools 1.1 just fine. Otherwise, folks are welcome to
>> volunteer to help with that!
>>
>>
>> > 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 guy
>> >
>> > "Save the cheerleader. Save the world.
Re: #evaluate
The more canonical example for an "evaluate" tool (or directive) is
being ably to dynamically decide what method to call on a particular
reference. So, something along the lines of:
#if( $this > $that )
#set( $method = $foo )
#else
#set( $method = $bar )
#end
$render.eval( "\${someRef}.${method}" )
Though, Christoph's example gets to the same point quicker.
While i am quite fine with providing a tool or a directive for
advanced users to do this, i really don't think it's practical,
necessary, or wise to bend over backwards to support this sort of
thing. So, i'm not even sure i'm ready to automatically include such
a directive in the default directive.properties, much less add some
new-fangled syntax for doing such things. At least an #evaluate
directive wouldn't really be growing the VTL language.
And as far as adding on optional parameter to narrow the context for
such evaluations, i think i can say with great confidence that YAGNI.
I don't think most people even need #evaluate, much less one with
such fine-grained context control.
On 1/3/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote:
[I'm changing the subject line-- I kept looking for this discussion in JIRA]
Great way of way of framing this, Christopher. Thinking about
#evaluate as a companion to #include and #parse makes me realize this
new proposed directive fits within the Velocity approach.
Another idea is to have an optional argument with a map that would
serve as a context.
#evaluate("hello from $name",{"name":"Will"})
WILL
On 1/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> No, the #evaluate directive is to be used as it the following example:
>
> #set( $error = $i18n_tool.getMessage("ERROR123") )
> #evaluate( $error )## reder by merging with context
>
> It something like the #parse directive, but the content comes
> from a string and not a file.
>
> :) Christoph
>
> Geir Magnusson Jr. wrote:
> > Do you mean
> >
> > $foo = "#foreach($a in $b) .. #end"
> >
> > ?
> >
> > If so, why not just do it that way, rather than add a new directive?
> >
> > geir
> >
> >
> > On Jan 2, 2007, at 11:47 PM, Will Glass-Husain (JIRA) wrote:
> >
> >> Add new directive #evaluate
> >> ---
> >>
> >> Key: VELOCITY-509
> >> URL: https://issues.apache.org/jira/browse/VELOCITY-509
> >> Project: Velocity
> >> Issue Type: New Feature
> >> Components: Engine
> >> Affects Versions: 1.5 beta2
> >> Reporter: Will Glass-Husain
> >> Priority: Minor
> >> Fix For: 1.6
> >>
> >>
> >> On a separate issue (VELOCITY-504) we came up with the idea of a new
> >> directive, #evaluate. Basically, it would act just like
> >> Velocity.evaluate().
> >>
> >> Users are always asking for this capability (internal evaluation).
> >> Usually we tell them to "use a tool". Instead, we should just put in
> >> a simple directive that would evaluate a VTL string using the current
> >> context.
> >>
> >> Incidentally, this should be the current local context, e.g. if inside
> >> a macro or a foreach loop (or worse, both) it should use that
> >> context. See VELOCITY-504 for why this is needed.
> >>
> >> --This message is automatically generated by JIRA.
> >> -
> >> If you think it was sent incorrectly contact one of the
> >> administrators: https://issues.apache.org/jira/secure/Administrators.jspa
> >> -
> >> For more information on JIRA, see: http://www.atlassian.com/software/jira
> >>
> >>
> >>
> >> -
> >> 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 unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Forio Business Simulations
Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com
-
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]
[veltools] tests not running for me
Claude, The new test stuff looks great. I'm particularly impressed by the ability to embed jetty like that. However, i can't get the tests to run on my system, even after fixing the the toolbox path for the generic tests. Here's the output i get: test.generic: [junit] Running org.apache.velocity.tools.test.whitebox.GenericToolsTests [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.01 sec [junit] Test org.apache.velocity.tools.test.whitebox.GenericToolsTests FAILED ... start-showcase-webapp: [echo] web server launched successfully. [junit] Running org.apache.velocity.tools.test.blackbox.ViewToolsTests [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.01 sec [junit] Test org.apache.velocity.tools.test.blackbox.ViewToolsTests FAILED I've tried messing around with various properties on the Junit task, but no luck so far. Any idea what might cause this? I even tried putting Sysout calls in each of the methods in GenericToolsTest to see which one was being run, but none of them were. help! :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [veltools] tests not running for me
Testsuite: org.apache.velocity.tools.test.whitebox.GenericToolsTests Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.01 sec Testcase: warning took 0.01 sec FAILED No tests found in org.apache.velocity.tools.test.whitebox.GenericToolsTests junit.framework.AssertionFailedError: No tests found in org.apache.velocity.tools.test.whitebox.GenericToolsTests === Testsuite: org.apache.velocity.tools.test.blackbox.ViewToolsTests Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.01 sec Testcase: warning took 0 sec FAILED No tests found in org.apache.velocity.tools.test.blackbox.ViewToolsTests junit.framework.AssertionFailedError: No tests found in org.apache.velocity.tools.test.blackbox.ViewToolsTests === The showcase.log looks like normal VVS and Velocity startup chatter. Nothing about tests in there. Could this be something to do with the JUnit/Ant classpath stuff? Perhaps the wrong version of JUnit in the classpath or wrong classpath being used? Looking into this myself... On 1/8/07, Claude Brisson <[EMAIL PROTECTED]> wrote: Hi Nathan. The exact cause should be listed (as long as any output) in the test result files in build/test/rst/ What do they contain ? Claude Le lundi 08 janvier 2007 à 10:47 -0800, Nathan Bubna a écrit : > Claude, > > The new test stuff looks great. I'm particularly impressed by the > ability to embed jetty like that. However, i can't get the tests to > run on my system, even after fixing the the toolbox path for the > generic tests. Here's the output i get: > > test.generic: > [junit] Running org.apache.velocity.tools.test.whitebox.GenericToolsTests > [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.01 sec > [junit] Test > org.apache.velocity.tools.test.whitebox.GenericToolsTests FAILED > ... > start-showcase-webapp: > [echo] web server launched successfully. > [junit] Running org.apache.velocity.tools.test.blackbox.ViewToolsTests > [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.01 sec > [junit] Test org.apache.velocity.tools.test.blackbox.ViewToolsTests FAILED > > I've tried messing around with various properties on the Junit task, > but no luck so far. Any idea what might cause this? I even tried > putting Sysout calls in each of the methods in GenericToolsTest to see > which one was being run, but none of them were. > > help! :) > > - > 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 unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [veltools] tests not running for me
Ok, i got it working. But, to do so, i had to upgrade to Ant 1.7.0. I'm not sure why it wouldn't work with Ant 1.6.2, though i tried a variety of things. Any insight here would be appreciated... It'd be great if this could work with earlier versions of Ant, but if not, then we should at least document it. On 1/8/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: Testsuite: org.apache.velocity.tools.test.whitebox.GenericToolsTests Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.01 sec Testcase: warning took 0.01 sec FAILED No tests found in org.apache.velocity.tools.test.whitebox.GenericToolsTests junit.framework.AssertionFailedError: No tests found in org.apache.velocity.tools.test.whitebox.GenericToolsTests === Testsuite: org.apache.velocity.tools.test.blackbox.ViewToolsTests Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.01 sec Testcase: warning took 0 sec FAILED No tests found in org.apache.velocity.tools.test.blackbox.ViewToolsTests junit.framework.AssertionFailedError: No tests found in org.apache.velocity.tools.test.blackbox.ViewToolsTests === The showcase.log looks like normal VVS and Velocity startup chatter. Nothing about tests in there. Could this be something to do with the JUnit/Ant classpath stuff? Perhaps the wrong version of JUnit in the classpath or wrong classpath being used? Looking into this myself... On 1/8/07, Claude Brisson <[EMAIL PROTECTED]> wrote: > Hi Nathan. > > The exact cause should be listed (as long as any output) in the test > result files in build/test/rst/ > > What do they contain ? > > Claude > > Le lundi 08 janvier 2007 à 10:47 -0800, Nathan Bubna a écrit : > > Claude, > > > > The new test stuff looks great. I'm particularly impressed by the > > ability to embed jetty like that. However, i can't get the tests to > > run on my system, even after fixing the the toolbox path for the > > generic tests. Here's the output i get: > > > > test.generic: > > [junit] Running org.apache.velocity.tools.test.whitebox.GenericToolsTests > > [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.01 sec > > [junit] Test > > org.apache.velocity.tools.test.whitebox.GenericToolsTests FAILED > > ... > > start-showcase-webapp: > > [echo] web server launched successfully. > > [junit] Running org.apache.velocity.tools.test.blackbox.ViewToolsTests > > [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.01 sec > > [junit] Test org.apache.velocity.tools.test.blackbox.ViewToolsTests FAILED > > > > I've tried messing around with various properties on the Junit task, > > but no luck so far. Any idea what might cause this? I even tried > > putting Sysout calls in each of the methods in GenericToolsTest to see > > which one was being run, but none of them were. > > > > help! :) > > > > - > > 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 unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA issues - resolve or close
I can see some value in this process, but not enough that i really care either way for myself. I'll do whatever pleases. :) On 1/11/07, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: Hi, I just reopened and resolved some issues. Reason for this is: I'd like to follow the proposed status lifecycle as shown on http://www.atlassian.com/software/jira/docs/v3.7.1/issues.html#StatusTypes. That means, we don't close issues immediately but resolve them with a "resolution" (Fixed/Won't fix/Later/Can't reproduce etc.). Once we to a particular release, we then close all issues that have been marked "resolved" for that release. Reason for this is to distinguish between issues for the current release and historic ones. It might be that this is too artificial / I am too anal here. If you think so, please speak up. ;-) 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 guy "Save the cheerleader. Save the world." - 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]
Tiles mailing list Was: Re: [jira] Commented: (VELTOOLS-64) Geronimo 1.1.1 with Tomcat install fails to render links correctly
That's an odd question. Not sure what "far" means when we're talking about mailing lists, but i am subscribed to all the newly created Tiles TLP mailing lists. On 1/16/07, Claude Brisson <[EMAIL PROTECTED]> wrote: Just a small question out of topic : Nathan, are you far from a specific tiles mailing list? c Le mardi 16 janvier 2007 à 08:51 -0800, John Eichelsdorfer (JIRA) a écrit : > [ https://issues.apache.org/jira/browse/VELTOOLS-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465209 ] > > John Eichelsdorfer commented on VELTOOLS-64: > > > I think I mentioned the exact versions of things except for Struts and Tiles. My struts is not a latest, but I don't remember the exact version here. > > The thing is, I took the same exact war for http://www.jobbank.com that works on straight Tomcat 5.5 and placed it in Geronimo 1.1.1. It worked perfectly in the one and failed as shown in the other in only that way. You can see this working in production if you go to the site. > > As I am not in front of that code at the moment I can't look into it right now, but I will try to give more particulars tonight or tomorrow including a bigger code snippet. The partial code above is correct though as I cut and pasted it. > > > > Geronimo 1.1.1 with Tomcat install fails to render links correctly > > -- > > > > Key: VELTOOLS-64 > > URL: https://issues.apache.org/jira/browse/VELTOOLS-64 > > Project: Velocity Tools > > Issue Type: Bug > > Components: VelocityStruts > >Affects Versions: 1.2 > >Reporter: John Eichelsdorfer > >Priority: Critical > > Fix For: 1.3 > > > > > > I have been using VelocityTools for years and have a project successfully running in production on standalone Tomcat 5.5. When I run the same war file on Geronimo 1.1.1, links do not render correctly. Geronimo also uses a 5.5 version of Tomcat in the standard distribution I am using. > > I am using Velocity 1.5 beta 1 and VelocityTools 1.2 from Maven. > > Given the following code that is parsed into a main file: > > $!pop.popName Jobs > > On Tomcat 5.5 standalone get: > > http://www.jobbank.com/action/pub/jobpost/list/submit?c=US&r=CA > > On Geronimo 1.1.1 with the same war file, we get: > > http://action/pub/jobpost/list/submit?c=US&r=CA > > The only difference obviously is the lack of domain name. Other links seem to work correctly that are referenced with an absolute path. For example: > > shows the correct hostname in the front. > > I was using a non-beta velocity, but moved up to using the beta to rule out this being the issue. I also did a search on the Geronimo distribution for any other file matching "velocity" but came up empty. > > I am not in a rush for this fix, but I think it is important to know that it will work in a next 1.5 Velocity release else people will be constantly using snapshots rather then a steady 1.5 build if this is where the problem lies. > > I am hoping it is somehow just a configuration issue, though I am using the most basic Geronimo setup. > - 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: Tiles mailing list Was: Re: [jira] Commented: (VELTOOLS-64) Geronimo 1.1.1 with Tomcat install fails to render links correctly
Ah... far in time. I was thinking space. :) Yeah, the lists are all up. Come join the fun! On 1/16/07, Claude Brisson <[EMAIL PROTECTED]> wrote: That's not odd at all, last time I tried the mailing list wasn't yet up, just asking how far in time, irrelevant of course if it is open, c u there :-) Claude Le mardi 16 janvier 2007 à 13:37 -0800, Nathan Bubna a écrit : > That's an odd question. Not sure what "far" means when we're talking > about mailing lists, but i am subscribed to all the newly created > Tiles TLP mailing lists. > > On 1/16/07, Claude Brisson <[EMAIL PROTECTED]> wrote: > > Just a small question out of topic : Nathan, are you far from a specific > > tiles mailing list? > > > > c > > > > Le mardi 16 janvier 2007 à 08:51 -0800, John Eichelsdorfer (JIRA) a > > écrit : > > > [ https://issues.apache.org/jira/browse/VELTOOLS-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465209 ] > > > > > > John Eichelsdorfer commented on VELTOOLS-64: > > > > > > > > > I think I mentioned the exact versions of things except for Struts and Tiles. My struts is not a latest, but I don't remember the exact version here. > > > > > > The thing is, I took the same exact war for http://www.jobbank.com that works on straight Tomcat 5.5 and placed it in Geronimo 1.1.1. It worked perfectly in the one and failed as shown in the other in only that way. You can see this working in production if you go to the site. > > > > > > As I am not in front of that code at the moment I can't look into it right now, but I will try to give more particulars tonight or tomorrow including a bigger code snippet. The partial code above is correct though as I cut and pasted it. > > > > > > > > > > Geronimo 1.1.1 with Tomcat install fails to render links correctly > > > > -- > > > > > > > > Key: VELTOOLS-64 > > > > URL: https://issues.apache.org/jira/browse/VELTOOLS-64 > > > > Project: Velocity Tools > > > > Issue Type: Bug > > > > Components: VelocityStruts > > > >Affects Versions: 1.2 > > > >Reporter: John Eichelsdorfer > > > >Priority: Critical > > > > Fix For: 1.3 > > > > > > > > > > > > I have been using VelocityTools for years and have a project successfully running in production on standalone Tomcat 5.5. When I run the same war file on Geronimo 1.1.1, links do not render correctly. Geronimo also uses a 5.5 version of Tomcat in the standard distribution I am using. > > > > I am using Velocity 1.5 beta 1 and VelocityTools 1.2 from Maven. > > > > Given the following code that is parsed into a main file: > > > > $!pop.popName Jobs > > > > On Tomcat 5.5 standalone get: > > > > http://www.jobbank.com/action/pub/jobpost/list/submit?c=US&r=CA > > > > On Geronimo 1.1.1 with the same war file, we get: > > > > http://action/pub/jobpost/list/submit?c=US&r=CA > > > > The only difference obviously is the lack of domain name. Other links seem to work correctly that are referenced with an absolute path. For example: > > > > shows the correct hostname in the front. > > > > I was using a non-beta velocity, but moved up to using the beta to rule out this being the issue. I also did a search on the Geronimo distribution for any other file matching "velocity" but came up empty. > > > > I am not in a rush for this fix, but I think it is important to know that it will work in a next 1.5 Velocity release else people will be constantly using snapshots rather then a steady 1.5 build if this is where the problem lies. > > > > I am hoping it is somehow just a configuration issue, though I am using the most basic Geronimo setup. > > > > > > > > > - > > 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 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]
[veltools] 1.3 freeze soon...
Just giving fair warning to anyone planning/hoping to make any further changes to VelocityTools before 1.3 is released... My current plan is to call for a vote to release 1.3-rc1 on Monday. At that time, it would be rather unhelpful for further changes to be made, since that would require a re-vote and/or a second RC release. So, if you want to make changes, please make them soon or at least wait until the vote finishes and i create a 1.3-rc1 tag. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project velocity-tools (in module velocity-tools) failed
VelocityTools is getting a Gump failure because we recently upgraded our Validator tool to use the org.struts.validator.Resources.getVarValue(Var,ServletContext,HttpServletRequest,boolean) method (to mirror the same change in JavascriptValidatorTag). The problem appears to be that the "packaged-struts" project in Gump (which we've been listing as a dependency) is an out of date JAR, and the "struts" project is a no-op. Is anyone in the Struts1 camp interested/able/willing to update Struts' presence in Gump? If not, i may try to take a stab at it, but it's been ages since i tried to build Struts myself, much less tell Gump how to do it. On 1/19/07, Velocity Gump wrote: 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-tools has an issue affecting its community integration. This issue affects 3 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - portals-bridges-frameworks : Support for JSR168 compliant Portlet development - portals-bridges-velocity : Support for JSR168 compliant Portlet development - velocity-tools : VelocityTools project Full details are available at: http://vmgump.apache.org/gump/public/velocity-tools/velocity-tools/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on commons-beanutils exists, no need to add for property commons-beanutils.jar. -DEBUG- Dependency on commons-collections exists, no need to add for property commons-collections.jar. -DEBUG- Dependency on commons-digester exists, no need to add for property commons-digester.jar. -DEBUG- Dependency on commons-lang exists, no need to add for property commons-lang.jar. -DEBUG- Dependency on commons-logging exists, no need to add for property commons-logging.jar. -DEBUG- Dependency on commons-validator exists, no need to add for property commons-validator.jar. -DEBUG- Dependency on jakarta-oro exists, no need to add for property oro.jar. -DEBUG- Dependency on velocity-engine exists, no need to add for property velocity.jar. -DEBUG- Dependency on jakarta-servletapi-4 exists, no need to add for property servlet.jar. -DEBUG- Dependency on struts-sslext exists, no need to add for property sslext.jar. -DEBUG- Dependency on packaged-struts exists, no need to add for property struts-core.jar. -DEBUG- Dependency on packaged-struts exists, no need to add for property struts-taglib.jar. -DEBUG- Dependency on packaged-struts exists, no need to add for property struts-tiles.jar. -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-tools/velocity-tools/gump_work/build_velocity-tools_velocity-tools.html Work Name: build_velocity-tools_velocity-tools (Type: Build) Work ended in a state of : Failed Elapsed: 9 secs Command Line: java -Djava.awt.headless=true org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dcommons-beanutils.jar=/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar -Doro.jar=/usr/local/gump/public/workspace/jakarta-oro/jakarta-oro-19012007.jar -Dstruts-core.jar=/usr/local/gump/packages/struts-1.2.9-lib/struts.jar -Dvelocity.jar=/usr/local/gump/public/workspace/velocity-engine/bin/velocity-19012007.jar -Dcommons-chain.jar=/usr/local/gump/public/workspace/jakarta-commons/chain/target/commons-chain-19012007.jar -Dservlet.jar=/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar -Dskip.jar.loading=true -Dsslext.jar=/usr/local/gump/public/workspace/struts-sslext/web/WEB-INF/lib/sslext.jar -Dstruts-tiles.jar=/usr/local/gump/packages/struts-1.2.9-lib/struts.jar -Dcommons-lang.jar=/usr/local/gump/public/workspace/jakarta-commons/lang/commons-lang-19012007.jar -Dproject.version=19012007 -Dcommons-validator.jar=/usr/local/gump/public/workspace/jakarta-commons/validator/dist/commons-validator-19012007.jar -Dcommons-logging.jar=/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-19012007.jar -Dstruts-taglib.jar=/usr/local/gump/packages/struts-1.2.9-lib/struts.jar -Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-19012007.jar -Dcommons-digester.jar=/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar all [Working Directory: /usr/local/gump/public/workspace/velocity-tools] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/velocity-tools/build/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr
[VOTE] Release VelocityTools 1.3-rc1
Ok, i think i'm done tinkering around, and i think it's time to get this codebase out there. Significant changes since 1.3-beta1 are as follow: - Addition and integration of a test framework (and a number of tests) for both GenericTools and VelocityView - Upgraded to Digester 1.8 and Validator 1.3.1 - Resolution of all remaining issues targeted for 1.3 family (especially VELTOOLS-58 & VELTOOLS-73) - Addition of ResourceTool and ViewResourceTool for i18n and other ResourceBundle usage. This includes tests for ResourceTool and demo of ViewResourceTool in showcase example. So, with this i think we're ready for a release candidate of VelocityTools 1.3. There are no other features or fixes planned for VelocityTools 1.3. Please vote regarding your support for doing this release: [ ] +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 vote will close sometime after Thursday 11am PST (roughly 72 hours). My vote is +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Get ready for CfV
i'm also rather fond of: * comparisons use toString() for different classes instead of being an error * multi-line string literals and directives * no longer necessary to call init() for default config and others will be very interested in: * support for decimals * map creation syntax On 1/23/07, Malcolm Edgar <[EMAIL PROTECTED]> wrote: Some high points for me include: * improved performance * improved error handling and logging * updated documentation, also now available in PDF * numerous bug fixes regards Malcolm Edgar On 1/24/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > What are the high points to be mentioned? > > On Jan 23, 2007, at 2:49 PM, Henning P. Schmiedehausen wrote: > > > "Geir Magnusson Jr." <[EMAIL PROTECTED]> writes: > > > > Let's see... ...the first release of one of the most popular > > templating engines in the java world since more than two years... > > > > I'd say yes. We did bigger PR for less visible projects. :-) > > > > Best regards > > Henning > > > > > > > >> Do you think this is really worthy of a press release? > > > >> On Jan 23, 2007, at 4:49 AM, Henning P. Schmiedehausen wrote: > > > >>> So folks, I think it is about time now to bite the bullet, call it a > >>> day and get Velocity 1.5 out. > >>> > >>> Unless anyone objects, I will CfV to release the current HEAD as > >>> Velocity 1.5 tomorrow, 12 PM (noon). All still open issues get moved > >>> to 1.6 by the time of the CfV. > >>> > >>> Will: Can you ramp up the PRC connection to get a press release > >>> by the > >>> end of next week? > >>> > >>> 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 guy > >>> > >>> "Save the cheerleader. Save the world." > >>> > >>> > >>> - > >>> 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] > > > > -- > > Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, > > 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person > > Open Source Consulting, Development, Design | Velocity - Turbine guy > > > > "Save the cheerleader. Save the world." > > > > - > > 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 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: Get ready for CfV
Is there some way we can put mailmur's stuff into the whiteboard or experimental stuff, so it at least gets distributed and is easily available, even if it doesn't make it into the core until 1.6? If not that, there's always the wiki. On 1/23/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: Yes! Significant Apache project emerges from dormancy; new TLP project; a couple of books written about it; lots of new features. Worth a press release. I'm a little disappointed mailmur's unicode file patch didn't make it in. Been meaning to work on that but have been slammed since before the holidays. Let's schedule this as the first patch to review for 1.6. I'll email the PRC, look for templates for a press release, and develop a draft. WILL On 1/23/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > Do you think this is really worthy of a press release? > > On Jan 23, 2007, at 4:49 AM, Henning P. Schmiedehausen wrote: > > > So folks, I think it is about time now to bite the bullet, call it a > > day and get Velocity 1.5 out. > > > > Unless anyone objects, I will CfV to release the current HEAD as > > Velocity 1.5 tomorrow, 12 PM (noon). All still open issues get moved > > to 1.6 by the time of the CfV. > > > > Will: Can you ramp up the PRC connection to get a press release by the > > end of next week? > > > > 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 guy > > > > "Save the cheerleader. Save the world." > > > > - > > 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] > > -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - 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: [VOTE]: Release Velocity 1.5
+1 On 1/24/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote: Let's do it. The list of changes (http://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12310253&styleName=Text&projectId=12310104&Create=Create) is much longer than it ought to be, the number of open issues is more or less down to zero and no new issues have been reported with beta 2. I think, it is time now. Stuff that I do expect to change between "now" (CfV) and "then" (Relase) are all non code: - Further work on the docs - A Maven 2 POM so that the Mavenatics don't need to pull velocity.jar and velocity-dep.jar in all the time - Updates on the xdocs themselves. [ ] +1 Let's do it [ ] 0 I don't care [ ] -1 No, because __ The vote will go for ~72 hours, that is Saturday, 27th, 18:00 MET (http://www.timeanddate.com/worldclock/fixedtime.html?month=1&day=27&year=2007&hour=18&min=0&sec=0&p1=37) My vote is +1 Best regards Henning - 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: Velocity-Tools ImportSupport unit tests
Thanks! Archives and more eyes are very good things. :)
Responses inline:
On 1/24/07, Christopher Schultz <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All,
[ At the request of Nathan Bubna, I am posting this to
dev@velocity.apache.org instead of bothering him individually ;) ]
Today, I have integrated the ImageSupport tests that I wrote into the
unit tests that are (as we speak) being added into svn.
Please find attached below my test case. It is a single file that
belongs in src/test/org/apache/velocity/tools/test/whitebox.
It relies on two additional libraries:
1. jmock (available at http://jmock.org/)
2. TestURLConnection (my own library, not attached as the list
identifies my post as SPAM if I do that)
Code contributions are best through JIRA anyway, as that allows you to
mark it explicitly as contributed for use under the Apache License.
Both of these JAR files need to go into test/lib in order to run the tests.
A couple of notes:
1. My TestURLConnection library is looking for a good home. Any
suggestions? I'm only providing the binary library which is
probably a deal-breaker for velocity-tools -- I know -- but I
was wondering if you know anyone in either jakarta-commons or
an incubator project who might be interested in this. I'd be
happy to provide you with the entire thing including source,
docs, etc.
Yeah, we're open source, so installing a binary-only library probably
won't work. However, it's not really that difficult to start your
own open source project for this at Google Code
(http://code.google.com/hosting/createProject) or SourceForge
(http://sourceforge.net/register/). Once it is set up there, that
makes it much easier for people to try it out or check out the code,
which in turn makes it much, much easier to find a better home for it
or else build a dev community around it there.
In fact, depending on what license you put it under (i recommend ASL
2.0 :), once you set it up and release a version, we would then be
able to integrate it into the VelocityTools tests and increase it's
exposure for you.
The only other possibility for us being able to use TestURLConnection
in VelocityTools is if we decided to adopt the code ourselves and make
it part of our own little test framework. Consideration of this would
probably have to wait until VelocityTools 1.3 is released and i am
definitely open to it if it means thorough testing of ImportSupport,
however, it probably would not give as much exposure or freedom to
your library.
If you're willing to take the time to set it up and release it as an
independent project, then that is the path i would recommend.
2. My test case does not run properly unless "fork" is set to true in
the whitebox junit invocation. I'm not entirely sure why this is.
Also, I have an inner class that wants to run like a test,
and so that fails unless you change the fileset to be executed from
".../whitebox/**/*" to ".../whitebox/**/*Tests.class". I'd be happy
to learn how to suppress testing on an inner class so that this
doesn't cause a problem.
i'm not sure. Claude might have a better idea. I'm still a noob when
it comes to junit.
3. The "test.generic" ant target runs all whitebox testing and not
just the generic tests (well, now that my test is included, it
does). My test is definitely not a blackbox test, so I set it up
under the white box tests. Perhaps you guys aren't ready for more
tests and the method just needs to evolve as more tests are added.
Just a thought.
We would probably either have to change "test.generic" to
"test.whitebox" or else add a new "greybox" or something. Claude, are
you reading this? I'd love to hear your thoughts on where
non-blackbox testing of VelocityView (not Generic) tools should go.
Let me know what you think.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFt+eL9CaO5/Lv0PARAtcjAKCyLd1hpJ+h35HD/NcYvzxtYxsptgCeL4nN
gEu8P0VTyQ8tyYEw0aU2t9Q=
=Ofs5
-END PGP SIGNATURE-
package org.apache.velocity.tools.test.whitebox;
import java.util.Map;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.Reader;
import org.junit.Test;
import org.junit.BeforeClass;
import junit.framework.Assert;
import junit.framework.TestCase;
import org.jmock.Mock;
import org.jmock.MockObjectTestCase;
import org.apache.velocity.tools.view.ImportSupport;
import org.apache.velocity.tools.test.loopback.Handler;
import net.christopherschultz.testurl.HttpURLConnection;
import net.christopherschultz.testurl.URLConnectionRegistry;
public class ImportSupportTests
extends MockObjectTestCase
{
// Need a concrete class; must be public else junit complain
Re: Velocity-Tools ImportSupport unit tests
On 1/24/07, Christopher Schultz <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan, Thanks for the quick response. Nathan Bubna wrote: > Code contributions are best through JIRA anyway, as that allows you to > mark it explicitly as contributed for use under the Apache License. Well, I decided to start here because of the library dependencies. I'm happy to tun everything through JIRA once there's an agreement. > Yeah, we're open source, so installing a binary-only [of your] library probably > won't work. Certainly. In fact, I /want/ to give this thing away. I've just been unable to get much guidance for the best way to do it. > However, it's not really that difficult to start your > own open source project for this at Google Code > (http://code.google.com/hosting/createProject) or SourceForge > (http://sourceforge.net/register/). Once it is set up there, that > makes it much easier for people to try it out or check out the code, > which in turn makes it much, much easier to find a better home for it > or else build a dev community around it there. I was operating based upon a rumor that the ASF doesn't like to use libs and stuff that are either non-ASF or that operate under certain types of licenses. I wanted to make sure that whatever I did wasn't a deal-breaker. The official doctrine is that ASF projects are encouraged (but definitely not required) to use other ASF projects wherever possible. However, ASF projects regularly and happily use non-ASF software (assuming the license allows) for needs which cannot be served by another ASF project. So, for instance, VelocityStruts happily makes use of the SSL-Ext project, which is hosted by sourceforge. Certain types of licenses can definitely be problematic. I'm no expert in this field, but if you are interested in a non-Apache license, then let me know which one and i'll help you find out if and how we can use it as an Apache project. > In fact, depending on what license you put it under (i recommend ASL > 2.0 :), once you set it up and release a version, we would then be > able to integrate it into the VelocityTools tests and increase it's > exposure for you. I was kinda hoping that Jakarta Commons would express interest, but it's kind of unclear how to donate something like this. Donating needn't be that difficult. You could just find a project which looks like it could use your code, create a new JIRA issue, attach your code, and mark it as a contribution under the ASL. But of course, that's no guarantee anything will be done with it. It's getting an existing ASF project to *adopt* code that is tricky. The PMC (Project Management Committee) for the adopting project has to want the code first. Even once they do, some large code donations must be brought through the incubator, though i'm not fully versed in all the situations where that is or isn't required. The most important thing is getting a PMC to want the code. Once you have the interest, the rest is usually just procedure, and members of that PMC should help you through it. If it is an independent project that will not be fully absorbed/integrated into an existing project, then it is much easier to get interest if people are free to try the code out (i.e. there is a release they can download) and can check out the source for it from some public repository. If it is just a small set of classes/patches, then posting the code as JIRA attachments may be sufficient for people to see it and try it out. > If you're willing to take the time to set it up and release it as an > independent project, then that is the path i would recommend. It's all set up and ready to go, actually. Just looking for a good home and for me to choose a license (ASF is just fine with me). Well, then i think you ought to create a project for it on Google Code or Sourceforge and do a release soon. Then i think we can look at getting the release uploaded into a maven repository and using it as a dependency of VelocityTools tests. Thanks again, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFt/dZ9CaO5/Lv0PARAhTCAJ9OHzOlAhro1gaQD+gpfZ1sEelOrQCdEBhb ddOsdqLN5/3IODZwdQAibiA= =bvqN -END PGP SIGNATURE- - 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]
[RESULT] [VOTE] Release VelocityTools 1.3-beta1
The vote has passed! I'll tag the release today and try to upload it tonight or tomorrow. Announcement should follow once the release is mirrored. PMC +1 Nathan Bubna Will Glass-Husain Henning Schmiedehausen Committer +1 Claude Brisson User/Contributor +1 Malcolm Edgar On 12/18/06, Nathan Bubna <[EMAIL PROTECTED]> wrote: Ok, i've got all the dependencies upgraded. The ant build system seems to be working great. I've attempted to get the Gump build working again, but that shouldn't hold up a release anyway. So, i think we're ready for a beta of VelocityTools 1.3: [ ] +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 vote will close sometime after Thursday 12pm PST (roughly 72 hours). :) My vote is +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] Release VelocityTools 1.3-beta1
Sorry, wrong thread. let's try that again... On 1/25/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: The vote has passed! I'll tag the release today and try to upload it tonight or tomorrow. Announcement should follow once the release is mirrored. PMC +1 Nathan Bubna Will Glass-Husain Henning Schmiedehausen Committer +1 Claude Brisson User/Contributor +1 Malcolm Edgar On 12/18/06, Nathan Bubna <[EMAIL PROTECTED]> wrote: > Ok, i've got all the dependencies upgraded. The ant build system seems > to be working great. I've attempted to get the Gump build working > again, but that shouldn't hold up a release anyway. > > So, i think we're ready for a beta of VelocityTools 1.3: > > [ ] +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 vote will close sometime after Thursday 12pm PST (roughly 72 hours). :) > > My vote is +1 > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] [VOTE] Release VelocityTools 1.3-rc1
The vote has passed! And this time i'm referring to the correct version and vote thread!! ;-) I'll tag the release today and try to upload it tonight or tomorrow. Announcement should follow once the release is mirrored. PMC +1 Nathan Bubna Will Glass-Husain Henning Schmiedehausen Committer +1 Claude Brisson User/Contributor +1 Malcolm Edgar On 1/23/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: +1 On 1/22/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > Ok, i think i'm done tinkering around, and i think it's time to get > this codebase out there. > > Significant changes since 1.3-beta1 are as follow: > > - Addition and integration of a test framework (and a number of tests) > for both GenericTools and VelocityView > - Upgraded to Digester 1.8 and Validator 1.3.1 > - Resolution of all remaining issues targeted for 1.3 family > (especially VELTOOLS-58 & VELTOOLS-73) > - Addition of ResourceTool and ViewResourceTool for i18n and other > ResourceBundle usage. This includes tests for ResourceTool and demo > of ViewResourceTool in showcase example. > > So, with this i think we're ready for a release candidate of > VelocityTools 1.3. There are no other features or fixes planned for > VelocityTools 1.3. Please vote regarding your support for doing this > release: > > [ ] +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 vote will close sometime after Thursday 11am PST (roughly 72 hours). > > My vote is +1 > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - 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]
Release dist directory structure
With two significant stable releases happening soon (Velocity 1.5 and VelocityTools 1.3), i'd like to nail down the distribution directory structure now. Changing these things is a pain due to mirroring, various link locations and such. I'd rather we get it straight and stick to it. Rather than re-hash what's currently out there (which isn't even totally sync'd with people.apache.org as i write) and our various understandings of how it should be, i'd like to kick the discussion off with a proposed structure. under /dist/velocity, i propose we continue to keep our KEYS file and directories for engine and tools. directly under those directories, we should have folders named after the most recent stable/production release and--if one exists--a more recent unstable/beta release. Given our current releases, this would look like: dist/velocity/ KEYS engine/ 1.4/ 1.5-beta2/ tools 1.2/ 1.3-rc1/ Since all releases on dist are automatically archived, we should not keep more than one stable and one unstable release for each branch of a project. So each time there is a stable/production release, both the old stable release and whatever beta/rc/alpha preceded the new stable release should be deleted. The "current" symlinks VelocityTools has [had in the past] are a debatable issue. Personally, they're a pain to update, and i suspect they're not even an ASF endorsed procedure. Unless someone protests, i'm going to remove them. If you like this, feel free to give a +1. If you don't please speak up soon, so i can get things moved around appropriately and update all our download links accordingly soon. :) If i don't hear anything on this by Monday afternoon (PST), i'll get started. though, i may do it earlier if everyone seems to be on board before then. :) so, yeah, feedback is welcome! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release dist directory structure
:) Great! Well, since our chair was so enthusiastic and he and i have been doing the recent releases, i'm going to go ahead and make the changes. if anyone protests, i'll be happy to reverse them (though that would be a PITA). On 1/27/07, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: "Nathan Bubna" <[EMAIL PROTECTED]> writes: >With two significant stable releases happening soon (Velocity 1.5 and >VelocityTools 1.3), i'd like to nail down the distribution directory >structure now. Changing these things is a pain due to mirroring, >various link locations and such. I'd rather we get it straight and >stick to it. +1 >Rather than re-hash what's currently out there (which isn't even >totally sync'd with people.apache.org as i write) and our various >understandings of how it should be, i'd like to kick the discussion >off with a proposed structure. >under /dist/velocity, i propose we continue to keep our KEYS file and >directories for engine and tools. directly under those directories, +1 >we should have folders named after the most recent stable/production >release and--if one exists--a more recent unstable/beta release. +1 >Given our current releases, this would look like: >dist/velocity/ > KEYS > engine/ > 1.4/ > 1.5-beta2/ > tools > 1.2/ > 1.3-rc1/ +1 >Since all releases on dist are automatically archived, we should not >keep more than one stable and one unstable release for each branch of >a project. So each time there is a stable/production release, both >the old stable release and whatever beta/rc/alpha preceded the new >stable release should be deleted. +1 >The "current" symlinks VelocityTools has [had in the past] are a >debatable issue. Personally, they're a pain to update, and i suspect >they're not even an ASF endorsed procedure. Unless someone protests, >i'm going to remove them. +1 +1 +1 >If you like this, feel free to give a +1. If you don't please speak >up soon, so i can get things moved around appropriately and update all >our download links accordingly soon. :) If i don't hear anything on >this by Monday afternoon (PST), i'll get started. though, i may do it >earlier if everyone seems to be on board before then. :) I fully agree with you on all points. Getting this more simple is good. Getting it consistent is even better. 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 guy "Save the cheerleader. Save the world." - 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: Release dist directory structure
Ok, i've reorganized the releases in our dist directory. The sync'ing
between people.apache.org and www.apache.org has already partly
updated things at http://www.apache.org/dist/velocity/, the rest
should happen within the next 24 hours.
Henning, i've updated all the relevant stuff in velocity/site that i
can think of, but i have not been able to successfully build it
locally, much less deploy it. Would you mind deploying the updates
for me today or tomorrow? Or, if you want to help me figure it out,
here's the error i'm stuck on:
[INFO] Building Apache Velocity Site
[INFO]task-segment: [post-site]
[INFO]
[INFO] [velocity-site-doxia-renderer:pre-site {execution: default}]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Internal error in the plugin manager executing goal
'org.apache.velocity.site:velocity-site-news-plugin:1.1.0:pre-site':
Un
able to find the mojo
'org.apache.velocity.site:velocity-site-news-plugin:1.1.0:pre-site' in
the plugin 'org.apache.velocity.site:
velocity-site-news-plugin'
This is when running "mvn" in site/site after successfully running
"mvn" in site/tools. And i'm using Maven 2.0.4 with
maven-site-plugin 2.0-beta-5 in my extensions instead of 2.0-SNAPSHOT
of maven-site-plugin, because Maven wasn't finding 2.0-SNAPSHOT.
If i just need to use Maven 2.0.5-SNAPSHOT, would you point me to a
build? i'd rather not have to build it myself this weekend.
On 1/27/07, Nathan Bubna <[EMAIL PROTECTED]> wrote:
:) Great! Well, since our chair was so enthusiastic and he and i
have been doing the recent releases, i'm going to go ahead and make
the changes. if anyone protests, i'll be happy to reverse them
(though that would be a PITA).
On 1/27/07, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote:
> "Nathan Bubna" <[EMAIL PROTECTED]> writes:
>
> >With two significant stable releases happening soon (Velocity 1.5 and
> >VelocityTools 1.3), i'd like to nail down the distribution directory
> >structure now. Changing these things is a pain due to mirroring,
> >various link locations and such. I'd rather we get it straight and
> >stick to it.
>
> +1
>
> >Rather than re-hash what's currently out there (which isn't even
> >totally sync'd with people.apache.org as i write) and our various
> >understandings of how it should be, i'd like to kick the discussion
> >off with a proposed structure.
>
> >under /dist/velocity, i propose we continue to keep our KEYS file and
> >directories for engine and tools. directly under those directories,
>
> +1
>
> >we should have folders named after the most recent stable/production
> >release and--if one exists--a more recent unstable/beta release.
>
> +1
>
> >Given our current releases, this would look like:
>
> >dist/velocity/
> > KEYS
> > engine/
> > 1.4/
> > 1.5-beta2/
> > tools
> > 1.2/
> > 1.3-rc1/
>
> +1
>
> >Since all releases on dist are automatically archived, we should not
> >keep more than one stable and one unstable release for each branch of
> >a project. So each time there is a stable/production release, both
> >the old stable release and whatever beta/rc/alpha preceded the new
> >stable release should be deleted.
>
> +1
>
> >The "current" symlinks VelocityTools has [had in the past] are a
> >debatable issue. Personally, they're a pain to update, and i suspect
> >they're not even an ASF endorsed procedure. Unless someone protests,
> >i'm going to remove them.
>
> +1 +1 +1
>
> >If you like this, feel free to give a +1. If you don't please speak
> >up soon, so i can get things moved around appropriately and update all
> >our download links accordingly soon. :) If i don't hear anything on
> >this by Monday afternoon (PST), i'll get started. though, i may do it
> >earlier if everyone seems to be on board before then. :)
>
> I fully agree with you on all points. Getting this more simple is
> good. Getting it consistent is even better.
>
>
> 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 guy
>
> "Save the cheerleader. Save the world."
>
> -
> 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: [VOTE]: Release Velocity 1.5
On 1/27/07, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: "Geir Magnusson Jr." <[EMAIL PROTECTED]> writes: >Normally yes - you vote on the final software that's going to be >released, not just the concept. >At the moment, I have no clue what would actually go out the door wrt >the binary (included libs, LICENSE and NOTICE files, etc) >Should be easy. Hm. That *is* a strong imbalance IMHO between projects that ship docs as part of their distribution (like we do) and others that simply keep and update their docs online and ship just e.g. javadocs. In that case, I'd actually like to discuss removing all docs except automatically created docs from source (e.g. Javadocs, Changelog etc.) from the distribution archives. -1 i like keeping docs with distros, both source and binary. and as Geir said, it doesn't really solve the problem. We do have to discuss the actual release process. Other projects (e.g. httpd) do it differently, they roll their distribution archives first and then vote on them. We do it the other way around. +1 !! i've been thinking about this for quite some time. i like the freedom httpd-ish projects have to change the status of a release (in any direction) without having to re-roll it. at the latest, i'd like to see us adopt this after Engine 1.5 and Tools 1.3 are out. it's a little superfluous to switch to this now since we've already been stepping through betas and RCS, but if people really wanted to start now, that's fine by me. :) Best regards Henning >geir >On Jan 27, 2007, at 6:20 AM, Henning P. Schmiedehausen wrote: >> "Geir Magnusson Jr." <[EMAIL PROTECTED]> writes: >> >>> I assume we'll have another vote on the final binary? >> >>> geir >> >> Do we need to? The code itself will not change, just some doc file, >> change logs etc. >> >> Best regards >> Henning >> >> >> >> >>> On Jan 27, 2007, at 3:52 AM, Henning P. Schmiedehausen wrote: >> >>>> "Will Glass-Husain" <[EMAIL PROTECTED]> writes: >>>> >>>> Hi, >>>> >>>> I'd say that I fully agree with your points. This is part of the >>>> "docs >>>> cleanup" before we release the code. >>>> >>>>Best regards >>>>Henning >>>> >>>> >>>>> Hi Henning, >>>> >>>>> +1, with a caveat... >>>> >>>>> Users will want to see specifics of what's new with the system. >>>>> Where's the change list? Will Maven generate this >>>>> automatically? I >>>>> suggest we have two items >>>> >>>>> * a copy of the release notes from the Wiki, moved into the main >>>>> distro as "RELEASE-NOTES.txt". This summarizes key changes and >>>>> more >>>>> importantly, dependency changes. >>>> >>>>> * a maven generated list from changes.xml >>>> >>>>> I'm +1 if we have those two things. >>>> >>>>> As an aside, It's incredible all the work you've done, >>>>> especially in >>>>> the past few months. >>>> >>>>> WILL >>>> >>>>> On 1/24/07, Malcolm Edgar <[EMAIL PROTECTED]> wrote: >>>>>> Been waiting for this day for a while now :) >>>>>> >>>>>> +1 >>>>>> >>>>>> On 1/25/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: >>>>>>> +1 >>>>>>> >>>>>>> On 1/24/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote: >>>>>>>> Let's do it. >>>>>>>> >>>>>>>> The list of changes >>>>>>>> (http://issues.apache.org/jira/secure/ReleaseNote.jspa? >>>>>>>> version=12310253&styleName=Text&projectId=12310104&Create=Create >>>>>>>> ) >>>>>>>> is much longer than it ought to be, the number of open issues >>>>>>>> is more or less down to zero and no new issues have been >>>>>>>> reported with beta 2. I think, it is time now. >>>>>>>> >>>>>>>> Stuff that I do expect to change between "now" (CfV) and >>>>>>>> "then" (Relase) >>>>>>>> are all non
Re: Release dist directory structure
On 1/27/07, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: "Nathan Bubna" <[EMAIL PROTECTED]> writes: >Henning, i've updated all the relevant stuff in velocity/site that i >can think of, but i have not been able to successfully build it >locally, much less deploy it. Would you mind deploying the updates >for me today or tomorrow? Or, if you want to help me figure it out, >here's the error i'm stuck on: Redeployed it. BTW: If you are crying out "how can I update the site": My plan was to set up an automated rebuild (once or twice a day) on a zone using the maven snapshot. However, the relevant infra ticket is now open for quite a while and even gentle prodding on IRC didn't move it (much). Unless anything happens really quick here, I'm not sure if I get this builder set up before I leave for holidays. Well, that would be nice. If it doesn't happen before you go, and we really need the site updated while you're gone, then i can probably find time to just dig in and build maven 2.0.6 myself. anyway, thanks for updating it for me. :) now i just need www.apache.org and a few mirrors to pick up 1.3-rc1 before i announce it to the lists. :) 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 guy "Save the cheerleader. Save the world." - 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: Release dist directory structure
On 1/27/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: On 1/27/07, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: > "Nathan Bubna" <[EMAIL PROTECTED]> writes: > > >Henning, i've updated all the relevant stuff in velocity/site that i > >can think of, but i have not been able to successfully build it > >locally, much less deploy it. Would you mind deploying the updates > >for me today or tomorrow? Or, if you want to help me figure it out, > >here's the error i'm stuck on: > > Redeployed it. BTW: If you are crying out "how can I update the site": > My plan was to set up an automated rebuild (once or twice a day) on a > zone using the maven snapshot. However, the relevant infra ticket is > now open for quite a while and even gentle prodding on IRC didn't move > it (much). Unless anything happens really quick here, I'm not sure if > I get this builder set up before I leave for holidays. Well, that would be nice. If it doesn't happen before you go, and we really need the site updated while you're gone, then i can probably find time to just dig in and build maven 2.0.6 myself. ... argh. i checked out the maven 2.0.x head, built it and installed it, but it is still giving me the same error i was getting with 2.0.4. i seem to be stuck at the moment. well, maybe i'll have some time and insight to try again monday... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
+1 On 1/28/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote: Due to a misunderstanding in the vote procedure, we actually have to repeat the release vote, because we should vote only on really rolled releases. The candidate for the Apache Velocity 1.5 release is available from http://people.apache.org/dist/velocity/1.5/ Shall we release this code base as Apache Velocity 1.5 [ ] +1 Yes. [ ] 0 I still don't care. [ ] -1 No, because . Vote period is Monday, Jan 29th 0:00 MET to Wednesday, Jan 31st 0:00 MET Best regards Henning - 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: svn commit: r500648 - /velocity/engine/branches/Velocity_1.5_BRANCH/
I believe the 1.6 was a typo. He was just suggesting that velocity/engine/branches/Velocity_1.5_BRANCH might be simply renamed velocity/engine/branches/1.5 so that "velocity" and "branch" aren't repeated in the path. :) On 1/29/07, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: "Geir Magnusson Jr." <[EMAIL PROTECTED]> writes: >Isn't that redundant "Velocity_1.6_BRANCH"? >it's in the velocity project, in the branches directory... how about >"1.5"? [...] >> Added: >> velocity/engine/branches/Velocity_1.5_BRANCH/ >> - copied from r500647, velocity/engine/trunk/ ? Sorry I don't understand this mail. Please elaborate. 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 guy "Save the cheerleader. Save the world." - 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]
[ANNOUNCE] VelocityTools 1.3 Release Candidate 1
The Apache Velocity project is pleased to announce the first release candidate for VelocityTools 1.3. You may download this release from: http://velocity.apache.org/download.cgi Significant changes since VelocityTools 1.2 are: - New tools: ContextTool for accessing context data, ResourceTool and ViewResourceTool for resource bundle access and easy i18n - ViewTool and Configurable interfaces are no longer necessary, instead you need only add init(Object) or configure(Map) methods (respectively) to your tools. This has allowed many settings on GenericTools to become configurable via toolbox.xml (like DateTool's default format). - Numerous syntax simplifications for using many of the tools in your templates - New showcase example to demonstrate most of the tools and their functions - Request-scoped tool availability can be restricted according to the request path by adding a element to the tool config. - New functionality in EscapeTool, LinkTool, CookieTool, ValueParser, and more We've also fixed all known bugs, overhauled our build process, updated all dependencies, added a test framework, and much more. Please try it out and let us know of any bugs, so we can release a final 1.3 version as soon as possible! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r500648 - /velocity/engine/branches/Velocity_1.5_BRANCH/
On 1/29/07, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: "Nathan Bubna" <[EMAIL PROTECTED]> writes: Well, all other branches are also named "VEL__BRANCH" (yes, I know that comes semi-automatically from CVS). I wanted to keep in tune. I actually didn't think much about it. >I believe the 1.6 was a typo. He was just suggesting that >velocity/engine/branches/Velocity_1.5_BRANCH >might be simply renamed >velocity/engine/branches/1.5 >so that "velocity" and "branch" aren't repeated in the path. :) Yes, it is redundant. Then again, I'm not a computer, I'm sort of a human being. A little redundancy is good for my weak mind (quick: How often do we state in the release that you need at least ant 1.6 now for building Velocity? [1]). good for the mind, rough on the fingers! :) i really don't and didn't care. this is not the sort of branch that any of us should have to work with often. i was just clarifying things. Please do *not* rename the branch. Its URL is referenced from the POM, the docs etc. and renaming it would break all the links. i don't think anyone was planning to at this point. Best regards Henning [1] Eight times. Once in getting-started.html and getting-started.xml, twice in build.html and build.xml and README. :-) >On 1/29/07, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: >> "Geir Magnusson Jr." <[EMAIL PROTECTED]> writes: >> >> >Isn't that redundant "Velocity_1.6_BRANCH"? >> >> >it's in the velocity project, in the branches directory... how about >> >"1.5"? >> >> [...] >> >> >> Added: >> >> velocity/engine/branches/Velocity_1.5_BRANCH/ >> >> - copied from r500647, velocity/engine/trunk/ >> >> ? Sorry I don't understand this mail. Please elaborate. >> >> 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 guy >> >> "Save the cheerleader. Save the world." >> >> - >> 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] -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design | Velocity - Turbine guy "Save the cheerleader. Save the world." - 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: Automatic Site rebuild
I'd rather not leave something running that is out of our control for a month unless there is very clear need for it, which i don't see at this point. As long as Will's concerns are addressed in the announcement emails and news blurb on the web site, we should be fine until you get back. Besides, i haven't given up all hope of getting Maven 2 to cooperate with me. In a pinch i could probably burn some midnight oil and figure it. On 1/29/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote: Hi, quick idea: As we will not get the zone on time and I will leave at least my mail server running and connected to the internet, I could set up a "once daily / twice daily" build on that machine. Downside to it is, that if I get lost in the Outback and it runs amok, you might not be able to stop it (short of closing my people.apache.org account... =:-) ) That would be a temporary solution and there would be no further excuse not to work on the docs. :-) 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 guy "Save the cheerleader. Save the world." - 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: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/30/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: Hi all, Reluctantly, I vote -1. :( I tested the release. It compiled fine, ant test ran fine under JDK 1.5 and 1.6, worked with Velocity Tools 1.2. But when I checked all the hyperlinks, the anakia page was missing. There's an error when generating the page and it was left out of the distribution [1]. C'mon. Anakia's documentation is anything but hard to find. I'm all for getting things right, but not for holding back releases based on one missing doc. I'd rather you let Henning release 1.5 now and release 1.5.1 yourself next week. I'm concerned about two things. I'm concerned about a prominent bad link on the main menu, and I'm concerned the last minute "vote on the final release" might not have uncovered additional problems. We've a chance to make a major impression on the Java world with this prominent release and I want this to be very smooth installation for both new users and the typical existing user who wants to upgrade. We can't cower in fear of unknown bugs. Fix what you know and care about, then let's get this thing moving again. My recommendation is to delay the release until there's time to fix these doc issues and for more thorough testing. Mid-March seems fine. For the "shallow bugs" theory to work, we need to issue a "release candidate" that everyone can work with. This doesn't need to be an actual release, just a binary distribution we can test. After a few weeks we should be assured the details are 100% set. How about two betas and a test build? That's what we've had. This release has had much time to prepare. More time won't kill us, but let's not pretend things are ever likely to be 100% set. Trust me, if i cared enough, i could start combing thru the docs of almost any major project you like and find dozens of errors. Same goes for most code. Final releases will never be perfect, but the "shallow bugs" theory won't work if we don't get *them* out there. Far fewer people bother with release candidates and betas. Incidentally, I disagree with Henning's comment that the beta2 had no errors. Actually, beta2 had a serious error in the build process in which "ant test" failed when run from the actual distribution. It worked from the source distribution but not the released package. No one found this problem for a month. And it's fixed, is it not? I can't adequately express my admiration of Henning's efforts in the last 6 months to get this out. This must be frustrating. I take responsibility myself for not thinking through the implications of the release process when Henning proposed a month ago we issue a release at the end of January. Taking responsibility in the open source world means only one thing, if you ask me. Doing the work. If you're going to take responsibility for this by re-doing this whole process to your satisfaction either by repeating the 1.5 test build and vote or by letting 1.5 go and releasing a 1.5.1, then i won't protest. But please don't just sit back and critique at the last minute. That's not just frustrating, it's obnoxious. However, the good news is that the recent momentum was effective. We are right at the doorway to a new release with many new features. The code is branched and close to perfect. it is not close to perfect, nor will it ever be, but i believe it will get better faster if you don't obsess about it being perfect. Docs are set, readme is present. With a little more checking (and fixing minor issues like this one), we can type "ant dist" in early March and create the new release. WILL [1] [echo] [anakia] Transforming into: C:\Documents and Settings\wglass\Desktop\velocity-1.5\bin\docs [anakia] Input: anakia.xml [anakia] [anakia] Error: The end-tag for element type "example" must end with a '>' delimiter. [anakia]Line: 117 Column: 60 On 1/28/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote: > Due to a misunderstanding in the vote procedure, we actually have to > repeat the release vote, because we should vote only on really rolled > releases. > > The candidate for the Apache Velocity 1.5 release is available from > http://people.apache.org/dist/velocity/1.5/ > > Shall we release this code base as Apache Velocity 1.5 > > [ ] +1 Yes. > [ ] 0 I still don't care. > [ ] -1 No, because . > > Vote period is > > Monday, Jan 29th 0:00 MET to Wednesday, Jan 31st 0:00 MET > > Best regards > Henning > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ---
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/30/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote: ... I did discuss this in some depth with Will on IRC. He explained me his reasons for the vote in depth I respect them. Here is my response: - The problem with the anakia.html file is apparent and obvious. So we have a single file for a quite obscure part of Velocity missing. It is fixed on the site (http://velocity.apache.org/engine/releases/velocity-1.5/anakia.html) so if anyone is really looking for this file and can not find it in the downloaded distribution, it is available online. To me, this is no show stopper. It is a wart. We have a number of them (I can readily think of at least one more broken link on the bundled pages). - The release feels "rushed". As I wrote, yes in part it is because I want to get it out before end of January. We have been dragging that release for so long that we might make the vaporware top 10 at some point. I'd like to get over with it. If we have warts, we can release 1.5.1 which fix them. Aiming for perfection IMHO does not cut the cake. Good is enough and we can always do the next release. We can find a reason not to release every time we try. +1 - The issues we have are *solely* with documentation. No code is involved. - Re-releasing 1.5 is IMHO not possible. We have rolled tarballs and jars which have been available from http://people.apache.org/dist/velocity/1.5/ Some people are bound to have downloaded them and they might even spread. We can denounce them as "not officially released" but if we re-roll 1.5 tarballs, we will end up with bug reports against bogus versions. eh... if you think so. i wouldn't say we released it even once, much less worry about re-releasing. we can call the next test build 1.5, 1.5.0 or 1.5.1, as far as i'm concerned. Telling me that I did a lot of work is nice. I know it. Velocity did cut seriously into my spare time lately and I want to spend this time for coding, not doing release and documentation chores. There has not much response been in terms of helping with docs and while most people are already talking about "the grand new Velocity 2.0", we want to get an actual release for 1.x first. Sorry, been busy with VelocityTools 1.3. :( BTW: I don't actually buy into the "smooth transition" argument anyway, however I can not really reinforce it. If you have an app that uses 1.4 or 1.3 for a long time and you just drop 1.5 in, you are in for a surprise. There is always dependency upgrading (which we could have stated more prominently in the release, but we do have it on the web site now (http://velocity.apache.org/engine/devel/upgrading.html, once the mirror caught up), so adding that link in the announcement is IMHO fine. As a compromise, I'd like to propose to keep the 1.5 release and call it "Release candidate" in the same way as httpd calls it's releases x.y.z and assigns them "levels of quality" such as (Alpha) (Beta) (Release Candidate) (General Availability). So this would then be Velocity 1.5 (Release Candidate) with probably Velocity 1.5.1 (General Availability) following. hmm. not thrilled about switching release procedures midway, but if you won't release Velocity 1.5 as final/GA/whatever, then i want to see some sort of release. so, i suppose i'll give this plan a: +1 This would mean that we reduce our planned 'press campaign' to an announcement on the dev list and the RSS feed and run the real thing for 1.5.1. I will not release if we have a -1 vote even if we do have three PMC +1 votes. I know the 'Apache rules' would back me here, but I would feel uncomfortable to do this without unanimous consent from the PMC members. Will felt strong enough about this to not just abstain but to vote -1, so we should try to resolve this and get him to retract his vote. To be honest, i'm bummed about this. I think there is wisdom in the rules. If Will feels strongly enough to -1 this, then he should feel strongly enough to address his concerns, upload a 1.5.1 test build and vote to have it released ASAP to supersede the 1.5 release. I did pull the release archives from people.apache.org. If we can resolve this on short notice, good. If not, we are basically stuck with Mid-March as the next possible release date (and a third vote) if I should do the release or someone else stepping up as release manager. Will should be able to scratch his itches quickly. Mid-march is a long time to wait for such small tweaks. If he doesn't step up with a 1.5.1 test build and vote before then, then i may take a shot at it. I'd like to hear opinions from others to that. I'd also like to encourage you to lobby Will to withdraw his -1 :-) Best regards Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ---
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/30/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Jan 30, 2007, at 11:24 PM, Henning Schmiedehausen wrote: ... > > As a compromise, I'd like to propose to keep the 1.5 release and > call it > "Release candidate" in the same way as httpd calls it's releases x.y.z > and assigns them "levels of quality" such as (Alpha) (Beta) (Release > Candidate) (General Availability). So this would then be > Velocity 1.5 (Release Candidate) with probably Velocity 1.5.1 (General > Availability) following. No - that's confusing. 1.5 RC would be followed by 1.5 GA eh.. only if we're talking about a vote to just re-label 1.5. if we make changes to the distro (even for docs) and roll a new release, then we need a new number. since we're only talking about doc changes, 1.5.1 seems appropriate and would be likely to get voted as GA. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/30/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: Hi, Knew I'd be unpopular the moment I hit send. no, no. we still like you. just not your decision. :) Three quick notes. 1) don't think the changes are big. But I think the distro should be reviewed and fixed. A bad hyperlink on the main menu, in our first release in 3 years, looks sloppy and conveys an inaccurate impression of the quality of our product. review and fix away! 2) Unlike V-tools, we did not have a test build. Instead, the final package was created with the choice "vote yes, or delay the release". I don't like it. no. we did have a test build and veltools did not. test build == unreleased build to be tested then voted upon hold on, i'm dropping this email and starting another. we have to get our terms and release processes straight or we'll never find consensus. 3) I'd be happy to vote +1 if we could call this Velocity 1.5rc1. But given the historic significance of this release, I urge us to release "Velocity 1.5" in a professional distro without obvious errors.(no need to immediately issue Velocity 1.5.1). best, WILL On 1/30/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > On 1/30/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > Reluctantly, I vote -1. > > :( > > > I tested the release. It compiled fine, ant test ran fine under JDK > > 1.5 and 1.6, worked with Velocity Tools 1.2. But when I checked all > > the hyperlinks, the anakia page was missing. There's an error when > > generating the page and it was left out of the distribution [1]. > > C'mon. Anakia's documentation is anything but hard to find. I'm all > for getting things right, but not for holding back releases based on > one missing doc. I'd rather you let Henning release 1.5 now and > release 1.5.1 yourself next week. > > > I'm concerned about two things. I'm concerned about a prominent bad > > link on the main menu, and I'm concerned the last minute "vote on the > > final release" might not have uncovered additional problems. We've a > > chance to make a major impression on the Java world with this > > prominent release and I want this to be very smooth installation for > > both new users and the typical existing user who wants to upgrade. > > We can't cower in fear of unknown bugs. Fix what you know and care > about, then let's get this thing moving again. > > > My recommendation is to delay the release until there's time to fix > > these doc issues and for more thorough testing. Mid-March seems fine. > > For the "shallow bugs" theory to work, we need to issue a "release > > candidate" that everyone can work with. This doesn't need to be an > > actual release, just a binary distribution we can test. After a few > > weeks we should be assured the details are 100% set. > > How about two betas and a test build? That's what we've had. This > release has had much time to prepare. More time won't kill us, but > let's not pretend things are ever likely to be 100% set. Trust me, if > i cared enough, i could start combing thru the docs of almost any > major project you like and find dozens of errors. Same goes for most > code. Final releases will never be perfect, but the "shallow bugs" > theory won't work if we don't get *them* out there. Far fewer people > bother with release candidates and betas. > > > Incidentally, I disagree with Henning's comment that the beta2 had no > > errors. Actually, beta2 had a serious error in the build process in > > which "ant test" failed when run from the actual distribution. It > > worked from the source distribution but not the released package. No > > one found this problem for a month. > > And it's fixed, is it not? > > > I can't adequately express my admiration of Henning's efforts in the > > last 6 months to get this out. This must be frustrating. I take > > responsibility myself for not thinking through the implications of the > > release process when Henning proposed a month ago we issue a release > > at the end of January. > > Taking responsibility in the open source world means only one thing, > if you ask me. Doing the work. If you're going to take > responsibility for this by re-doing this whole process to your > satisfaction either by repeating the 1.5 test build and vote or by > letting 1.5 go and releasing a 1.5.1, then i won't protest. But > please don't just sit back and critique at the last minute. That's > not just fru
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/30/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Jan 31, 2007, at 3:48 AM, Will Glass-Husain wrote: > I thought about this a little more. There's a couple things we can do > that I'd support. > > (1) Figure out a way to call this release something other than > Velocity 1.5, e.g. Velocity 1.5rc1 and issue the release immediately. > Can we do this without a 3 day vote? See my other response. Why the rush? If Henning has to go vacation, then you do the RC1 stuff, and we'll wait until he gets back for the 1.5 GA release. > > (2) Take a little time to make the minor fix required, then release > the software. I can step up to do this over the next few days. I > think Henning was concerned we'd need to rebuild the site and he's the > only one that can do that. If I managed the release, I'd probably > want to do Velocity 1.5rc1 first and then Velocity 1.5 two weeks > later. Why is he the only one that can do the site? because Maven2 has issues and that's what the current site is being built with. i've tried to get it working on my machine, but no luck yet. > > (3) Henning remains release manager and we wait until March for the > release. We could leave the VELOCITY_1.5_BRANCH up so that the > release is ready to go. We can also direct users interested in 1.5 > specific features to that svn branch. Right. Do the fixes in the branch, then make a tag/1.5rc1 build, vote and release as RC1. When Henning gets back, do 1.5 GA. Advantage is that people get to beat 1.5RC1 about for a month. geir > > I'm sure our European community is long abed, I'll look for comments > from them in the morning. > > WILL > > On 1/30/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: >> Hi, >> >> Knew I'd be unpopular the moment I hit send. >> >> Three quick notes. >> >> 1) don't think the changes are big. But I think the distro should be >> reviewed and fixed. A bad hyperlink on the main menu, in our first >> release in 3 years, looks sloppy and conveys an inaccurate impression >> of the quality of our product. >> >> 2) Unlike V-tools, we did not have a test build. Instead, the final >> package was created with the choice "vote yes, or delay the release". >> I don't like it. >> >> 3) I'd be happy to vote +1 if we could call this Velocity 1.5rc1. >> But >> given the historic significance of this release, I urge us to release >> "Velocity 1.5" in a professional distro without obvious errors. >> (no >> need to immediately issue Velocity 1.5.1). >> >> best, >> WILL >> >> >> >> On 1/30/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: >> > On 1/30/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: >> > > Hi all, >> > > >> > > Reluctantly, I vote -1. >> > >> > :( >> > >> > > I tested the release. It compiled fine, ant test ran fine >> under JDK >> > > 1.5 and 1.6, worked with Velocity Tools 1.2. But when I >> checked all >> > > the hyperlinks, the anakia page was missing. There's an error >> when >> > > generating the page and it was left out of the distribution [1]. >> > >> > C'mon. Anakia's documentation is anything but hard to find. >> I'm all >> > for getting things right, but not for holding back releases >> based on >> > one missing doc. I'd rather you let Henning release 1.5 now and >> > release 1.5.1 yourself next week. >> > >> > > I'm concerned about two things. I'm concerned about a >> prominent bad >> > > link on the main menu, and I'm concerned the last minute "vote >> on the >> > > final release" might not have uncovered additional problems. >> We've a >> > > chance to make a major impression on the Java world with this >> > > prominent release and I want this to be very smooth >> installation for >> > > both new users and the typical existing user who wants to >> upgrade. >> > >> > We can't cower in fear of unknown bugs. Fix what you know and care >> > about, then let's get this thing moving again. >> > >> > > My recommendation is to delay the release until there's time >> to fix >> > > these doc issues and for more thorough testing. Mid-March >> seems fine. >> > > For the "shallow bugs" theory to work, we need to issue a >> "release >> > > candidate
Release/Voting processes
ok, there seems to be some confusion about the different ways to prepare, label, and vote on releases. here's my understanding of the two most common options. 1) How we used to do it. We would put the quality/status of the release in the release name. These would typically go something like 1.5-beta1, 1.5-rc1, 1.5. If a second beta or RC was necessary, then those would end with a "2". The proper way to begin this release process is to build the distribution with the anticipated release name (say 1.5-beta1) and upload it to where dev@ folks can get it. This is what i would call the test build. Once this test build is available, then call for a simple +1 (release it), 0 (i'm ambivalent), -1 (don't release) vote. This is a perfectly valid process, though it has the disadvantage that the quality/status of the release cannot be changed even if our opinions of it have changed for better or worse. If 1.5-rc1 turned out to have no problems anyone found or cared about, then we would still have to rebuild a release named 1.5, upload the test build of it, and then vote to release it, even though the only needed change was in the name. The improper way to do this is to call for a vote before providing the build for people to test. Henning initially did this with 1.5, and i did it for both Veltools 1.3-beta1 and Veltools 1.3-rc1. That was the lazy, improper way and won't be done again. However, for Henning's second try at 1.5, he did provide a proper test build for us to download and try before voting. 2) How i'd like to see us to do it. We would not put the quality/status of the release in the release name. Instead, the release is only given a number (typically in X.Y.Z form, but there's no reason for that but convention), and the quality/status of the release is decided by vote and labeled on the website and not in the release itself. The proper way to begin this release process is to build the distribution with the current release number and upload it to where dev@ folks can get it. This is, again, the test build. Once the test build is available, the release manager calls for a vote on the quality of the build +1 (GA), +1 (Beta), or +1 (Alpha). I don't really see much point in have a +1 (RC) option, but some like it. Once the vote is over, the release may be made available with the quality determined clearly labeled on the download page and in all announcements. This means that we don't have to do a new release if an RC is found to be perfect. All we have to do is re-vote, change the website, and announce it (if we want). It also provides a clear means to demote releases in which serious problems are later found. This ease of changing status makes it easier to have more frequent releases, and helps to ensure that the work of doing a release is not voided by a -1 vote. Instead, the quality just gets lowered, but the release still happens and is available to those who want it. We've discussed switching to 2), but i'm not aware of a clear decision or consensus on that, so it feels like we're still talking about both, hoping that one or the other will work better for us here. I really want to move to 2), but i've seen on other projects that the switch takes some getting used to. It may be best if we stick to 1) until Velocity 1.5 and Veltools 1.3 are out. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/30/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: Just to clarify... > > 2) Unlike V-tools, we did not have a test build. Instead, the final > > package was created with the choice "vote yes, or delay the release". > no. we did have a test build and veltools did not. > test build == unreleased build to be tested then voted upon What I meant is that there was no opportunity to offer fixes upon this build before voting. Due to the timing, Henning put that last touches on the build then called for a vote. Obviously, I'd much prefer to just have added the missing page to the Velocity 1.5 branch, but according to our recently clarified rules, I can't fix this and have this vote apply to that fix. We have to vote on a specific distribution. build or branch? let's not confuse those. that said, yes, it feels like 1.5 is caught on procedural technicalities when the code is good and we all want to see it released. :( As a side question, is there a required voting period? It seems pretty obvious to me that we could do another vote and with everyone saying yes quickly, perhaps allowing Henning to still make this happen. Though I'd like to see an rc, I wouldn't insist on it. i don't know. i also don't know why we're just expecting Henning to make this happen, when he's probably got enough to do with getting ready to travel, and he isn't the one with itches left to scratch on this release. WILL - 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: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/31/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Jan 31, 2007, at 5:54 AM, Nathan Bubna wrote: > On 1/30/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> ... >> Why is he the only one that can do the site? > > because Maven2 has issues and that's what the current site is being > built with. i've tried to get it working on my machine, but no luck > yet. Then I'd argue this shouldn't be our site until this is fixed :) Sorry, it's a little late for argument. :( this is our first go at our TLP site. we didn't have one, Henning made one that worked for him and believed he had left sufficient instructions for others to copy. Turns out it wasn't so simple (at least for me, YMMV). No one foresaw this, and fixes and further effort are in the pipeline. If i understand the situation fully, the options facing each of us here are a) jump in and help, b) replace it entirely with something more workable, or c) wait for someone else to do a) or b). personally, i'm planning to find time for a). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/31/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: Hi, Quick note at 6AM. (always dangerous to send email 15 min after getting up). How about if I just drop my concerns about the lack of an rc, and just ask - is there any way we can issue a release "Velocity 1.5" with the anakia documentation fixed? It's a small patch to two files to fix the xdoc that has already been applied to trunk. Yes. We have not had an official 1.5 release, only a test build. Our next release can be either 1.5 or 1.5-rc1 or whatever. Again, I'd be happy to do the release - perhaps we could get the site ready, archive it, then copy the release over when ready? If you're willing to do the release, go for it. Put the fixes in the VELOCITY_1.5_BRANCH, roll a test build, upload it, point us to it, and then call for a vote. Updating the site is a secondary thing. We can figure that out when we get to it. I really like the new site organization. I assume these Maven issues are a temporary thing. If it becomes too onerous we might just back out the specific site features in the short term. agreed. and i'm also not aware of any reason that we can't just go in and tweak the html by hand if we need to. the site can be dealt with. get the release up to you standards and release it. i'm growing quite weary of talking about it. WILL - 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: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/31/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Jan 31, 2007, at 10:40 PM, Nathan Bubna wrote: > On 1/31/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> On Jan 31, 2007, at 5:54 AM, Nathan Bubna wrote: >> >> > On 1/30/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> > ... >> >> Why is he the only one that can do the site? >> > >> > because Maven2 has issues and that's what the current site is being >> > built with. i've tried to get it working on my machine, but no >> luck >> > yet. >> >> Then I'd argue this shouldn't be our site until this is fixed :) > > Sorry, it's a little late for argument. :( this is our first go at > our TLP site. But the TLP site could have been a slightly agumented older site. ah... hindsight. yeah, it could've, at least until the new one was totally ready. we didn't expect so many problems, and even now i feel like getting things sorted with Maven2 is the path of least resistance and will be more useful in the long run. again, YMMV. > we didn't have one, Henning made one that worked for > him and believed he had left sufficient instructions for others to > copy. Turns out it wasn't so simple (at least for me, YMMV). No one > foresaw this, and fixes and further effort are in the pipeline. If i > understand the situation fully, the options facing each of us here are > a) jump in and help, b) replace it entirely with something more > workable, or c) wait for someone else to do a) or b). personally, > i'm planning to find time for a). Great. But don't give me flak for suggesting that having only one person able to build is suboptimal. heh. sorry, but it'd be really hard not to come back with a "thanks, Captain Obvious" to something like that. ;-) seriously, we all know it's not good, and Henning's not the only working on changing that status. help and/or patience are appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/31/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: Ok, I didn't want to step on Henning's toes by doing this too soon. I'm guessing he's wrapping up and getting ready for his big trip. We can address the site update immediately following the release. if he's planning to do the fixes and put up a new test build, i haven't heard him say it. at this point, i think it'd be a nice gesture of cooperation if you were to step up and help. Incidentally, the press release is coming along. The PRC has given useful comments. I'm still working on getting a quote from a commercial user. Claude has agreed to be the European contact for the press and I'll be listed as the US contact. that's great! perhaps we could put out a request for commercial soundbites on the user list? WILL On 1/31/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > If you're willing to do the release, go for it. Put the fixes in the > VELOCITY_1.5_BRANCH, roll a test build, upload it, point us to it, and > then call for a vote. Updating the site is a secondary thing. We can > figure that out when we get to it. > - 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]
[VOTE] Release VelocityTools 1.3 Final
No problems new problems have been reported since the release of 1.3-rc1, and i've made another, more thorough pass through the docs and build scripts, so i think we are ready to release 1.3 final. Changes since VelocityTools 1.3-rc1 are as follow: - Improved "publish" target in build.xml - Added Christopher Schultz to CONTRIBUTORS - Minor misc doc updates - Removed all outdated jakarta URLs i could find - Changed ant scripts to be explicit about compilation source/targets There have been no changes to the source code, test code, or examples since 1.3-rc1. All tests pass successfully, and there are no further features or fixes expected for VelocityTools 1.3. The test build for this release is available at: http://people.apache.org/~nbubna/velocity/tools/1.3/ (i would have put it at people.apache.org/builds/velocity/tools/13, but i don't appear to have the necessary karma, and i don't think it really matters for a test build.) Please download it, try it out, and vote regarding your support for doing this release: [ ] +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 __ I plan to tally the results and close the vote sometime after Thursday 11am PST (roughly 72 hours). My vote is +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release VelocityTools 1.3 Final
I would prefer if you committed it to the trunk (which is now 1.4-dev) and not create a 1.3 branch just for this. To get this into 1.3, we'd have to turn the 1.3 tag into a branch and check the fix in there. Then i'd have to re-roll the release, re-test it myself, re-upload it, and call for a new vote. That's a lot of work for something i think can wait for the next version. We can't account for everything a user does, and this is not a situation new to the 1.3 release. There is also a very simple workaround. The user can always use $request.session or $request.getSession(false) to ensure a fresh session. If you're willing to let this wait for the next version, then go ahead and commit the change to the trunk. (And once again, i'm further convinced we need to move to a more httpd-like release process to avoid wasted release effort. :) On 2/5/07, Claude Brisson <[EMAIL PROTECTED]> wrote: I may have a little commit: IMO the ChainedContext object should not keep a reference to the session, because the session can be created during the merging process of the template (for instance, a request tool may create the session to store in it some cached value). In this case, $session will remain null while the session does exist. My proposal is just to always fetch the session using the request. Shall I commit it now or wait? Claude I'll try to do it today. Le lundi 05 février 2007 à 10:55 -0800, Nathan Bubna a écrit : > No problems new problems have been reported since the release of > 1.3-rc1, and i've made another, more thorough pass through the docs > and build scripts, so i think we are ready to release 1.3 final. > > Changes since VelocityTools 1.3-rc1 are as follow: > > - Improved "publish" target in build.xml > - Added Christopher Schultz to CONTRIBUTORS > - Minor misc doc updates > - Removed all outdated jakarta URLs i could find > - Changed ant scripts to be explicit about compilation source/targets > > There have been no changes to the source code, test code, or examples > since 1.3-rc1. All tests pass successfully, and there are no further > features or fixes expected for VelocityTools 1.3. The test build for > this release is available at: > > http://people.apache.org/~nbubna/velocity/tools/1.3/ > (i would have put it at people.apache.org/builds/velocity/tools/13, > but i don't appear to have the necessary karma, and i don't think it > really matters for a test build.) > > Please download it, try it out, and vote regarding your support for > doing this release: > > [ ] +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 __ > > I plan to tally the results and close the vote sometime after Thursday > 11am PST (roughly 72 hours). > > My vote is +1 > > - > 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 unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] [VOTE] Release VelocityTools 1.3 Final
The vote has passed! +1's from Nathan Bubna Claude Brisson Will Glass-Husain Daniel Rall I'll move the release to the dist folders for mirroring and work on getting the site updated so we can announce this release broadly. On 2/5/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: No problems new problems have been reported since the release of 1.3-rc1, and i've made another, more thorough pass through the docs and build scripts, so i think we are ready to release 1.3 final. Changes since VelocityTools 1.3-rc1 are as follow: - Improved "publish" target in build.xml - Added Christopher Schultz to CONTRIBUTORS - Minor misc doc updates - Removed all outdated jakarta URLs i could find - Changed ant scripts to be explicit about compilation source/targets There have been no changes to the source code, test code, or examples since 1.3-rc1. All tests pass successfully, and there are no further features or fixes expected for VelocityTools 1.3. The test build for this release is available at: http://people.apache.org/~nbubna/velocity/tools/1.3/ (i would have put it at people.apache.org/builds/velocity/tools/13, but i don't appear to have the necessary karma, and i don't think it really matters for a test build.) Please download it, try it out, and vote regarding your support for doing this release: [ ] +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 __ I plan to tally the results and close the vote sometime after Thursday 11am PST (roughly 72 hours). My vote is +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
update on site issues
I've made some progress with building the site. I've managed to get maven (2.0.6-snapshot) to build the web site successfully on my local machine with the exception of the front page, which appears to be failing due to the following error: Caused by: org.apache.maven.doxia.macro.manager.MacroNotFoundException: Cannot find macro with id = null I'm hoping to look further into that today or tomorrow if i have time. I haven't tried deploying the site yet. In the meantime, i've also noticed that there are a number of folders in /www/velocity.apache.org/ that do not have velocity group permissions, so i can't do anything with them. These are the engine/, tools/, and dvsl/ folders. This means i can't add the documentation for the Tools 1.3 release or the devel/ documentation in their current location unless Henning checks this and changes the group perms or someone else with sufficient karma changes them. Anyone out there got that karma? Geir? Or does anyone know who i should talk to? I'm guessing the infrastructure people, but i thought i'd ask here first. The other option would be to change all those locations, but i'd rather not if it can be helped. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: update on site issues
thanks! On 2/8/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: I fixed the group. You should be good to go. If not, bellow again... geir On Feb 8, 2007, at 5:50 PM, Nathan Bubna wrote: > I've made some progress with building the site. I've managed to get > maven (2.0.6-snapshot) to build the web site successfully on my local > machine with the exception of the front page, which appears to be > failing due to the following error: > > Caused by: > org.apache.maven.doxia.macro.manager.MacroNotFoundException: > Cannot find macro with id = null > > I'm hoping to look further into that today or tomorrow if i have time. > I haven't tried deploying the site yet. > > In the meantime, i've also noticed that there are a number of folders > in /www/velocity.apache.org/ that do not have velocity group > permissions, so i can't do anything with them. These are the engine/, > tools/, and dvsl/ folders. This means i can't add the documentation > for the Tools 1.3 release or the devel/ documentation in their current > location unless Henning checks this and changes the group perms or > someone else with sufficient karma changes them. > > Anyone out there got that karma? Geir? Or does anyone know who i > should talk to? I'm guessing the infrastructure people, but i thought > i'd ask here first. > > The other option would be to change all those locations, but i'd > rather not if it can be helped. > > - > 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 unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: update on site issues
Don't get too excited yet. So, i gave up on trying to get the site plugin to generate the index.html page with the news macro. Instead, i commented out the news macro and manually added the latest news. So now i have the site building and running perfectly on machine. Now i'm caught up trying to deploy the site. I've added my user/pass to the velocity.apache.org server in my M2 settings.xml, but the site:deploy target is failing rather mysteriously: [INFO] [INFO] Building Apache Velocity Site [INFO]task-segment: [site:deploy] [INFO] [INFO] [site:deploy] scpexe://people.apache.org/www/velocity.apache.org - Session: Opened Executing command: ssh -o "BatchMode yes" [EMAIL PROTECTED] "mkdir -p /www/velocity.apache.org/." Permission denied (publickey,keyboard-interactive). scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnecting scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnected [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Error performing commands for file transfer Exit code 255 - Permission denied (publickey,keyboard-interactive). [INFO] [INFO] Total time: 16 seconds [INFO] Finished at: Fri Feb 09 14:54:22 PST 2007 [INFO] Final Memory: 6M/12M [INFO] I've tried about a dozen different things messing with rsa and dsa keys, adding/removing my password from settings.xml, and more, but no luck yet. I've also tried running the ssh command that is failing, and it only works if i take out the -o "BatchMode yes" part. Anyone have any ideas? On 2/9/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: Good to hear! Glad we have this as a group capability. WILL On 2/8/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > I've made some progress with building the site. I've managed to get > maven (2.0.6-snapshot) to build the web site successfully on my local > machine with the exception of the front page, which appears to be > failing due to the following error: > > Caused by: org.apache.maven.doxia.macro.manager.MacroNotFoundException: > Cannot find macro with id = null > > I'm hoping to look further into that today or tomorrow if i have time. > I haven't tried deploying the site yet. > > In the meantime, i've also noticed that there are a number of folders > in /www/velocity.apache.org/ that do not have velocity group > permissions, so i can't do anything with them. These are the engine/, > tools/, and dvsl/ folders. This means i can't add the documentation > for the Tools 1.3 release or the devel/ documentation in their current > location unless Henning checks this and changes the group perms or > someone else with sufficient karma changes them. > > Anyone out there got that karma? Geir? Or does anyone know who i > should talk to? I'm guessing the infrastructure people, but i thought > i'd ask here first. > > The other option would be to change all those locations, but i'd > rather not if it can be helped. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - 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: update on site issues
Hmm. Not sure. I haven't got time to tackle this further today. I'll try again monday and take a look at those. On 2/9/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: Stupid question, but are the file permissions right on the public key and containing folder? That always trips me up when logging in with SSH keys. WILL On 2/9/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > Don't get too excited yet. > > So, i gave up on trying to get the site plugin to generate the > index.html page with the news macro. Instead, i commented out the > news macro and manually added the latest news. So now i have the site > building and running perfectly on machine. > > Now i'm caught up trying to deploy the site. I've added my user/pass > to the velocity.apache.org server in my M2 settings.xml, but the > site:deploy target is failing rather mysteriously: > > [INFO] > [INFO] Building Apache Velocity Site > [INFO]task-segment: [site:deploy] > [INFO] > [INFO] [site:deploy] > scpexe://people.apache.org/www/velocity.apache.org - Session: Opened > Executing command: ssh -o "BatchMode yes" [EMAIL PROTECTED] > "mkdir -p /www/velocity.apache.org/." > > Permission denied (publickey,keyboard-interactive). > > scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnecting > scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnected > [INFO] > [ERROR] BUILD ERROR > [INFO] > [INFO] Error uploading site > > Embedded error: Error performing commands for file transfer > Exit code 255 - Permission denied (publickey,keyboard-interactive). > > [INFO] > [INFO] Total time: 16 seconds > [INFO] Finished at: Fri Feb 09 14:54:22 PST 2007 > [INFO] Final Memory: 6M/12M > [INFO] > > I've tried about a dozen different things messing with rsa and dsa > keys, adding/removing my password from settings.xml, and more, but no > luck yet. I've also tried running the ssh command that is failing, > and it only works if i take out the -o "BatchMode yes" part. > > Anyone have any ideas? > > On 2/9/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > > Good to hear! Glad we have this as a group capability. > > > > WILL > > > > On 2/8/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > > I've made some progress with building the site. I've managed to get > > > maven (2.0.6-snapshot) to build the web site successfully on my local > > > machine with the exception of the front page, which appears to be > > > failing due to the following error: > > > > > > Caused by: org.apache.maven.doxia.macro.manager.MacroNotFoundException: > > > Cannot find macro with id = null > > > > > > I'm hoping to look further into that today or tomorrow if i have time. > > > I haven't tried deploying the site yet. > > > > > > In the meantime, i've also noticed that there are a number of folders > > > in /www/velocity.apache.org/ that do not have velocity group > > > permissions, so i can't do anything with them. These are the engine/, > > > tools/, and dvsl/ folders. This means i can't add the documentation > > > for the Tools 1.3 release or the devel/ documentation in their current > > > location unless Henning checks this and changes the group perms or > > > someone else with sufficient karma changes them. > > > > > > Anyone out there got that karma? Geir? Or does anyone know who i > > > should talk to? I'm guessing the infrastructure people, but i thought > > > i'd ask here first. > > > > > > The other option would be to change all those locations, but i'd > > > rather not if it can be helped. > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Forio Business Simulations > > > > Will Glass-Husain > > [EMAIL PROTECTED] > > www.forio.com > > > > ---
Re: [ANN] tuc 1.0a1 - URLConnection unit testing framework built for VELTOOLS
nice! i'll try to take a look at it this week. On 2/12/07, Christopher Schultz <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, In writing unit tests for velocity tools, I needed a component like this and it didn't already seem to exist. So, I created a formal project on sourceforge under the Apache Software License 2.0 and I have an alpha release. The project can be found here: http://sourceforge.net/projects/tuc The only file available for release is tuc-1.0a.zip which contains the full source, small amount of documentation, and a JAR binary for direct use. Unit tests are also provided, and the project is buildable very easily by simply doing "ant dist". I'd appreciate any feedback or suggestions for improvements, etc. MY goal is to get this vetted and then used for velocity tools' test suite. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF0Oxq9CaO5/Lv0PARAkRjAJ9rPPyhZpLi1io2qh9DKJeb9hG6XACgkxvp IxCL/7SPHt5sXRcEfCe5MbQ= =05+H -END PGP SIGNATURE- - 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: update on site issues
file permissions on my key don't seem to be the issue. i don't know a ton about ssh perms, but it sure seems like my account just doesn't have the karma to do '-o "BatchMode yes"'. still looking into it... On 2/9/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: Stupid question, but are the file permissions right on the public key and containing folder? That always trips me up when logging in with SSH keys. WILL On 2/9/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > Don't get too excited yet. > > So, i gave up on trying to get the site plugin to generate the > index.html page with the news macro. Instead, i commented out the > news macro and manually added the latest news. So now i have the site > building and running perfectly on machine. > > Now i'm caught up trying to deploy the site. I've added my user/pass > to the velocity.apache.org server in my M2 settings.xml, but the > site:deploy target is failing rather mysteriously: > > [INFO] > [INFO] Building Apache Velocity Site > [INFO]task-segment: [site:deploy] > [INFO] > [INFO] [site:deploy] > scpexe://people.apache.org/www/velocity.apache.org - Session: Opened > Executing command: ssh -o "BatchMode yes" [EMAIL PROTECTED] > "mkdir -p /www/velocity.apache.org/." > > Permission denied (publickey,keyboard-interactive). > > scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnecting > scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnected > [INFO] > [ERROR] BUILD ERROR > [INFO] > [INFO] Error uploading site > > Embedded error: Error performing commands for file transfer > Exit code 255 - Permission denied (publickey,keyboard-interactive). > > [INFO] > [INFO] Total time: 16 seconds > [INFO] Finished at: Fri Feb 09 14:54:22 PST 2007 > [INFO] Final Memory: 6M/12M > [INFO] > > I've tried about a dozen different things messing with rsa and dsa > keys, adding/removing my password from settings.xml, and more, but no > luck yet. I've also tried running the ssh command that is failing, > and it only works if i take out the -o "BatchMode yes" part. > > Anyone have any ideas? > > On 2/9/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > > Good to hear! Glad we have this as a group capability. > > > > WILL > > > > On 2/8/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > > I've made some progress with building the site. I've managed to get > > > maven (2.0.6-snapshot) to build the web site successfully on my local > > > machine with the exception of the front page, which appears to be > > > failing due to the following error: > > > > > > Caused by: org.apache.maven.doxia.macro.manager.MacroNotFoundException: > > > Cannot find macro with id = null > > > > > > I'm hoping to look further into that today or tomorrow if i have time. > > > I haven't tried deploying the site yet. > > > > > > In the meantime, i've also noticed that there are a number of folders > > > in /www/velocity.apache.org/ that do not have velocity group > > > permissions, so i can't do anything with them. These are the engine/, > > > tools/, and dvsl/ folders. This means i can't add the documentation > > > for the Tools 1.3 release or the devel/ documentation in their current > > > location unless Henning checks this and changes the group perms or > > > someone else with sufficient karma changes them. > > > > > > Anyone out there got that karma? Geir? Or does anyone know who i > > > should talk to? I'm guessing the infrastructure people, but i thought > > > i'd ask here first. > > > > > > The other option would be to change all those locations, but i'd > > > rather not if it can be helped. > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Forio Business Simulations > > > > Will Glass-Husain
Re: update on site issues
finally got it working. the updated site has been uploaded and should be on the public servers soon. i'll probably get an announcement out tomorrow afternoon (too busy between now and then otherwise). for the curious, i finally just wiped my ssh keys on both the server and my client and re-did them following the instructions here: http://www.atmos.albany.edu/facstaff/rmctc/ssh2/ not sure exactly what was wrong before, but it works. Will, are you going to roll Engine 1.5 anytime soon? if not, i might be up for doing it later this week. On 2/13/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: file permissions on my key don't seem to be the issue. i don't know a ton about ssh perms, but it sure seems like my account just doesn't have the karma to do '-o "BatchMode yes"'. still looking into it... On 2/9/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > Stupid question, but are the file permissions right on the public key > and containing folder? That always trips me up when logging in with > SSH keys. > > WILL > > On 2/9/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > Don't get too excited yet. > > > > So, i gave up on trying to get the site plugin to generate the > > index.html page with the news macro. Instead, i commented out the > > news macro and manually added the latest news. So now i have the site > > building and running perfectly on machine. > > > > Now i'm caught up trying to deploy the site. I've added my user/pass > > to the velocity.apache.org server in my M2 settings.xml, but the > > site:deploy target is failing rather mysteriously: > > > > [INFO] > > [INFO] Building Apache Velocity Site > > [INFO]task-segment: [site:deploy] > > [INFO] > > [INFO] [site:deploy] > > scpexe://people.apache.org/www/velocity.apache.org - Session: Opened > > Executing command: ssh -o "BatchMode yes" [EMAIL PROTECTED] > > "mkdir -p /www/velocity.apache.org/." > > > > Permission denied (publickey,keyboard-interactive). > > > > scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnecting > > scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnected > > [INFO] > > [ERROR] BUILD ERROR > > [INFO] > > [INFO] Error uploading site > > > > Embedded error: Error performing commands for file transfer > > Exit code 255 - Permission denied (publickey,keyboard-interactive). > > > > [INFO] > > [INFO] Total time: 16 seconds > > [INFO] Finished at: Fri Feb 09 14:54:22 PST 2007 > > [INFO] Final Memory: 6M/12M > > [INFO] > > > > I've tried about a dozen different things messing with rsa and dsa > > keys, adding/removing my password from settings.xml, and more, but no > > luck yet. I've also tried running the ssh command that is failing, > > and it only works if i take out the -o "BatchMode yes" part. > > > > Anyone have any ideas? > > > > On 2/9/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > > > Good to hear! Glad we have this as a group capability. > > > > > > WILL > > > > > > On 2/8/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > > > I've made some progress with building the site. I've managed to get > > > > maven (2.0.6-snapshot) to build the web site successfully on my local > > > > machine with the exception of the front page, which appears to be > > > > failing due to the following error: > > > > > > > > Caused by: org.apache.maven.doxia.macro.manager.MacroNotFoundException: > > > > Cannot find macro with id = null > > > > > > > > I'm hoping to look further into that today or tomorrow if i have time. > > > > I haven't tried deploying the site yet. > > > > > > > > In the meantime, i've also noticed that there are a number of folders > > > > in /www/velocity.apache.org/ that do not have velocity group > > > > permissions, so i can't do anything with them. These are the engine/, > > > > tools/, and dvsl/ folders. This means i can't add the documentation > >
[ANNOUNCE] VelocityTools 1.3 released
I'm pleased to announce the release of VelocityTools 1.3. There have been many improvements made since the 1.2 release. A key focus in this version has been ease of use. We've simplified developing your own tools by eliminating the ViewTool and Configurable interfaces, and we've simplified the syntax for using many of our existing tools within Velocity templates to both save keystrokes and reduce visual clutter. The distribution also comes with a new "showcase" example webapp that demonstrates many of the uses of the various tools as well as allowing you to interactively play with them. Just download the binary distribution, and deploy the "showcase.war" example to your servlet container to try it out. Also included are the usual slate of bug fixes, dependency upgrades, entirely new tools, and new functions for existing tools. For a full listing of changes, see the change log. http://velocity.apache.org/tools/devel/changes.html VelocityTools 1.3 is available in either source or binary form at: http://velocity.apache.org/download.cgi#tools For more information about VelocityTools go to: http://velocity.apache.org/tools/devel/index.html Nathan Bubna, on behalf of the Velocity development community. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: typo in devtool page (EscapeTool -> ResourceTool)
argh. thanks! will fix shortly... On 2/15/07, mailmur <[EMAIL PROTECTED]> wrote: FYI, Link list has two "EscapeTool" links, second one should be "ResourceTool" link. http://velocity.apache.org/tools/devel/generic/ ** EscapeTool A tool to help with common escaping needs in Velocity templates. ** EscapeTool A tool to simplify access to ResourceBundles for internationalization or other dynamic content needs. The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php - 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: svn commit: r509094 - in /velocity/engine/trunk/src: java/org/apache/velocity/util/introspection/SecureIntrospectorImpl.java test/org/apache/velocity/test/SecureIntrospectionTestCase.java
Awful lot of formatting changes mixed in here, makes it hard to tell
what changed. :(
On 2/18/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: wglass
Date: Sun Feb 18 21:17:09 2007
New Revision: 509094
URL: http://svn.apache.org/viewvc?view=rev&rev=509094
Log:
Allow SecureUberspector to work with iterators in #foreach. Fixes VELOCITY-516.
Modified:
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/SecureIntrospectorImpl.java
velocity/engine/trunk/src/test/org/apache/velocity/test/SecureIntrospectionTestCase.java
Modified:
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/SecureIntrospectorImpl.java
URL:
http://svn.apache.org/viewvc/velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/SecureIntrospectorImpl.java?view=diff&rev=509094&r1=509093&r2=509094
==
---
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/SecureIntrospectorImpl.java
(original)
+++
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/SecureIntrospectorImpl.java
Sun Feb 18 21:17:09 2007
@@ -16,7 +16,7 @@
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
- * under the License.
+ * under the License.
*/
import java.lang.reflect.Method;
@@ -24,14 +24,14 @@
import org.apache.velocity.runtime.log.Log;
/**
- * Prevent "dangerous" classloader/reflection related calls. Use this
+ * Prevent "dangerous" classloader/reflection related calls. Use this
* introspector for situations in which template writers are numerous
* or untrusted. Specifically, this introspector prevents creation of
* arbitrary objects and prevents reflection on objects.
- *
- * See documentation of checkObjectExecutePermission() for
+ *
+ * See documentation of checkObjectExecutePermission() for
* more information on specific classes and methods blocked.
- *
+ *
* @author mailto:[EMAIL PROTECTED]">Will Glass-Husain
* @version $Id$
*/
@@ -39,19 +39,19 @@
{
private String[] badClasses;
private String[] badPackages;
-
+
public SecureIntrospectorImpl(String[] badClasses, String[] badPackages,
Log log)
{
super(log);
this.badClasses = badClasses;
this.badPackages = badPackages;
}
-
+
/**
- * Get the Method object corresponding to the given class, name and
parameters.
+ * Get the Method object corresponding to the given class, name and
parameters.
* Will check for appropriate execute permissions and return null if the
method
* is not allowed to be executed.
- *
+ *
* @param clazz Class on which method will be called
* @param methodName Name of method to be called
* @param params array of parameters to method
@@ -62,84 +62,81 @@
{
if (!checkObjectExecutePermission(clazz,methodName))
{
-log.warn ("Cannot retrieve method " + methodName +
+log.warn ("Cannot retrieve method " + methodName +
" from object of class " + clazz.getName() +
" due to security restrictions.");
return null;
-
+
}
else
{
return super.getMethod(clazz, methodName, params);
}
}
-
+
/**
* Determine which methods and classes to prevent from executing. Always
blocks
* methods wait() and notify(). Always allows methods on Number, Boolean,
and String.
* Prohibits method calls on classes related to reflection and system
operations.
* For the complete list, see the properties
introspector.restrict.classes
* and introspector.restrict.packages.
- *
+ *
* @param clazz Class on which method will be called
* @param methodName Name of method to be called
* @see
org.apache.velocity.util.introspection.SecureIntrospectorControl#checkObjectExecutePermission(java.lang.Class,
java.lang.String)
*/
public boolean checkObjectExecutePermission(Class clazz, String methodName)
{
-if (methodName == null)
-{
-return false;
-}
-
-/**
- * check for wait and notify
- */
-if ( methodName.equals("wait") || methodName.equals("notify") )
-{
-return false;
-}
-
-/**
- * Always allow the most common classes - Number, Boolean and String
- */
-else if (java.lang.Number.class.isAssignableFrom(clazz))
-{
-return true;
-}
-
-else if (java.lang.Boolean.class.isAssignableFrom(clazz))
-{
-return true;
-}
-
-else if (java.lang.String.class.isAssignableFrom(clazz))
-{
-return true;
-}
-
+
+ /**
+* check for wait and n
Re: update on site issues
Will, I have pretty good odds on finding time to roll a 1.5 build and call for vote this week. If you can assure me you're sure you can get a test build and vote going tomorrow, i'll hold my horses. If not, then i'm quite tired of waiting for this release and will plan to start putting time into running the release myself tomorrow afternoon. On 2/13/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: Nice. > Will, are you going to roll Engine 1.5 anytime soon? if not, i might > be up for doing it later this week. I think so. I've been getting about 6 hours of sleep nightly for the last few weeks lately due to work deadlines. When that hits 8, I'll have a little free time to address this :-) Give me till this weekend to do the right thing here... WILL On 2/13/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > finally got it working. the updated site has been uploaded and should > be on the public servers soon. i'll probably get an announcement out > tomorrow afternoon (too busy between now and then otherwise). > > for the curious, i finally just wiped my ssh keys on both the server > and my client and re-did them following the instructions here: > http://www.atmos.albany.edu/facstaff/rmctc/ssh2/ > > not sure exactly what was wrong before, but it works. > > Will, are you going to roll Engine 1.5 anytime soon? if not, i might > be up for doing it later this week. > > On 2/13/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > file permissions on my key don't seem to be the issue. i don't know a > > ton about ssh perms, but it sure seems like my account just doesn't > > have the karma to do '-o "BatchMode yes"'. still looking into it... > > > > On 2/9/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > > > Stupid question, but are the file permissions right on the public key > > > and containing folder? That always trips me up when logging in with > > > SSH keys. > > > > > > WILL > > > > > > On 2/9/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > > > Don't get too excited yet. > > > > > > > > So, i gave up on trying to get the site plugin to generate the > > > > index.html page with the news macro. Instead, i commented out the > > > > news macro and manually added the latest news. So now i have the site > > > > building and running perfectly on machine. > > > > > > > > Now i'm caught up trying to deploy the site. I've added my user/pass > > > > to the velocity.apache.org server in my M2 settings.xml, but the > > > > site:deploy target is failing rather mysteriously: > > > > > > > > [INFO] > > > > [INFO] Building Apache Velocity Site > > > > [INFO]task-segment: [site:deploy] > > > > [INFO] > > > > [INFO] [site:deploy] > > > > scpexe://people.apache.org/www/velocity.apache.org - Session: Opened > > > > Executing command: ssh -o "BatchMode yes" [EMAIL PROTECTED] > > > > "mkdir -p /www/velocity.apache.org/." > > > > > > > > Permission denied (publickey,keyboard-interactive). > > > > > > > > scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnecting > > > > scpexe://people.apache.org/www/velocity.apache.org - Session: Disconnected > > > > [INFO] > > > > [ERROR] BUILD ERROR > > > > [INFO] > > > > [INFO] Error uploading site > > > > > > > > Embedded error: Error performing commands for file transfer > > > > Exit code 255 - Permission denied (publickey,keyboard-interactive). > > > > > > > > [INFO] > > > > [INFO] Total time: 16 seconds > > > > [INFO] Finished at: Fri Feb 09 14:54:22 PST 2007 > > > > [INFO] Final Memory: 6M/12M > > > > [INFO] > > > > > > > > I've tried about a dozen different things messing with rsa and dsa > > > > keys, adding/removing my password from settings.xml, and more, but no > > > > luck yet. I've also tried running the ssh command that is failing,
[VOTE] Release Velocity Engine 1.5
Ok, Will has fixed the doc issues that made him -1 the last test build, as well as a minor bug in the new SecureUberspect. All the tests pass, the build looks solid to me, and the included velocity-1.5.jar works just dandy with the VelocityTools example apps. The test build for this release is available at: http://people.apache.org/~nbubna/velocity/engine/1.5/ Please check out the build to make sure i haven't missed anything important and vote regarding your support for releasing this test build as the long-awaited Velocity 1.5: [ ] +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 10am PST on Saturday, Feb 24th. If i do not find time amidst yardwork 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]
Re: [VOTE] Release Velocity Engine 1.5
On 2/22/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: +1 Thanks for jumping in, Nathan. no problem. things are slow at work for me this week. i do hope, though, that you'll still be willing and able to handle the announcement and press release once i finish the release process and update the website. (actually, it was a small but major bug in the SecureUberspector, essentially rendering it unusable. Never hurts to get features beyond the unit tests and into the field. "Good catch!" to Vincent). ah, thanks. i didn't realize it was major. how fortuitous that the release was delayed long enough for it to be caught! WILL On 2/22/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > Ok, Will has fixed the doc issues that made him -1 the last test > build, as well as a minor bug in the new SecureUberspect. All the > tests pass, the build looks solid to me, and the included > velocity-1.5.jar works just dandy with the VelocityTools example apps. > > The test build for this release is available at: > http://people.apache.org/~nbubna/velocity/engine/1.5/ > > Please check out the build to make sure i haven't missed anything > important and vote regarding your support for releasing this test > build as the long-awaited Velocity 1.5: > > [ ] +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 10am PST on Saturday, Feb 24th. If i do not find time amidst > yardwork 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] > > -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - 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] Some proposals for Tools 2.0
On 2/25/07, Claude Brisson <[EMAIL PROTECTED]> wrote:
Hi there!
Here are some structural evolutions I'd like to discuss before any
coding. I'm pretty sure that the first one is a good option - the second
one is more prospective.
1. On-demand tools loading: instead of a standard HashMap, the idea here
is to have a ToolMap, inheriting HashMap, which will instanciate a tool
from its toolinfo only when the generic getter is called. This should be
a quite interesting performance gain in some situations. We maybe need
some attribute to have tools instanciated at toolbox initialization
('instanciate-on-load' ?).
I really like the idea! Though, i think i might prefer to call it a
Toolbox instead of ToolMap. just to stick with the metaphor... :)
2. View tools: other objects in my webapp are often jealous of the view
servlet. They also would like to use some of the tools. Session scoped
tools can be reached via the session, but it's not the case for
application or request scoped tools. To achieve this, there would be two
things to do:
- the application tools map should be stored as a ServletContext
attribute and the request tools map as a Request attribute.
- the constitution of the three scoped maps should be decorrelated from
the remaining of the processing so that it could potentially take place
in a servlet filter.
i agree we should find a way to solve this, though i'm not sure i
fully understand the second part of your proposed implementation. i
would think we would simply want to create a Toolbox (as in idea #1)
for each scope, place the proper Toolbox in the attributes of the
request/session/servletcontext and then just make our ChainedContext
smart enough to search in all of those for tools that are requested.
i don't see why we need a filter or to constitute the three toolboxes
at all.
oh, and with this, we may want to re-organize the layout of a
toolbox.xml file to lump the tools from the three scopes together in
their toolboxes. but that's a separate issue...
i predict there are going to be some interesting complications/side
effects, but we'll be able to see those better once we start coding.
i'll try and get a 2.x branch set up today (or soon, if i don't get to
it). Then we can start hacking away. i have some other ideas and
major changes in mind and already have some code for them too. i'm
excited about the possibilities...
Thanks for your remarks,
Claude
-
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: update on site issues
On 3/5/07, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: "Nathan Bubna" <[EMAIL PROTECTED]> writes: >Anyone out there got that karma? Geir? Or does anyone know who i >should talk to? I'm guessing the infrastructure people, but i thought >i'd ask here first. Hm. Are you not in Jakarta? You should have been able to simply chgrp the directories as you are a member of the velocity (definitely) and jakarta (probably) groups. Did you try and it did not work? I'm pretty sure i'm in both. I did try, and it didn't work. It's been a while, but IIRC, the group perms weren't set to jakarta or velocity. Anyway, it's fixed now. Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person|eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fürth, HRB 7350|a s Sitz der Gesellschaft: Buckenhof. Geschäftsführer: Henning Schmiedehausen |n "Save the cheerleader. Save the world." - 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: Velocity 1.5 Release - SVN Revision?
On 3/5/07, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: Nathan, do you still have your SVN tree from which you built the 1.5 Release? of course. Which Revision does it report for "svn info ." in the root directory? We need that information for creating the 1.5 Release Tag. 509925 That info is also here: http://svn.apache.org/viewvc/velocity/engine/branches/Velocity_1.5_BRANCH/ BTW: Strictly spoken are the references in the POM wrong because they should not reference .../branches/VELOCITY_1.5_BRANCH/ but .../tags/VELOCITY_1.5/ They aren't wrong unless/until we do further dev on the branch, in which case, we should do a 1.5.x release. So, it hardly matters. This means that rebuilding 1.5 from source will actually be difficult, once we think about 1.5.1. This is my bad and I intended to fix it before the 1.5 release; however Nathan CfV'ed before I returned from holidays and the voting period is already over. Not too late to vote. 72 hours was the minimum voting period. I'm managing this release, the vote is over when i send a result. I did miss the result, though. No, there is no result. Both Geir and Marino have implied that they intend to vote. I will wait until they do or until enough people do to satisfy me that the test build has been sufficiently tested. I understand this is a busy time for many. I've waited long enough to be patient for another week or so if need be. Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person|eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fürth, HRB 7350|a s Sitz der Gesellschaft: Buckenhof. Geschäftsführer: Henning Schmiedehausen |n "Save the cheerleader. Save the world." - 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: Velocity 1.5 Release - SVN Revision?
On 3/5/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: On 3/5/07, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: > Nathan, > > do you still have your SVN tree from which you built the 1.5 Release? of course. > Which Revision does it report for "svn info ." in the root directory? > We need that information for creating the 1.5 Release Tag. 509925 That info is also here: http://svn.apache.org/viewvc/velocity/engine/branches/Velocity_1.5_BRANCH/ > BTW: Strictly spoken are the references in the POM wrong because they > should not reference .../branches/VELOCITY_1.5_BRANCH/ but > .../tags/VELOCITY_1.5/ They aren't wrong unless/until we do further dev on the branch, in which case, we should do a 1.5.x release. So, it hardly matters. By the way, many projects vote on and release their official POMs separately. We could consider doing the same. We should definitely consider at some point doing a parent POM for the Velocity TLP that the rest can inherit from. > This means that rebuilding 1.5 from source will actually be difficult, > once we think about 1.5.1. This is my bad and I intended to fix it > before the 1.5 release; however Nathan CfV'ed before I returned from > holidays and the voting period is already over. Not too late to vote. 72 hours was the minimum voting period. I'm managing this release, the vote is over when i send a result. > I did miss the result, though. No, there is no result. Both Geir and Marino have implied that they intend to vote. I will wait until they do or until enough people do to satisfy me that the test build has been sufficiently tested. I understand this is a busy time for many. I've waited long enough to be patient for another week or so if need be. > Best regards > Henning > > > -- > Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls > 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person|eau > Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc > |m k > INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fürth, HRB 7350|a s > Sitz der Gesellschaft: Buckenhof. Geschäftsführer: Henning Schmiedehausen |n > > "Save the cheerleader. Save the world." > > - > 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: Velocity 1.5 Release - SVN Revision?
I've got to rush out the door to a meeting, but i'll be back in an hour or so. Then i'll comment further, tally the votes and get things moving. And yes, i'm all for a 1.5.1. no shame in that. On 3/6/07, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: "Nathan Bubna" <[EMAIL PROTECTED]> writes: My vote is reluctantly +1, because the "I want to get it out" weights more for me than the issues that I have found: >> BTW: Strictly spoken are the references in the POM wrong because they >> should not reference .../branches/VELOCITY_1.5_BRANCH/ but >> .../tags/VELOCITY_1.5/ >They aren't wrong unless/until we do further dev on the branch, in >which case, we should do a 1.5.x release. So, it hardly matters. Yes, it does. If we do further development, then trying to rebuild the site from the release package will give different results. Which probably does not matter much, but it would matter to me. IMHO we will at least have an 1.5.1 to fix the issues listed below: >> This means that rebuilding 1.5 from source will actually be difficult, >> once we think about 1.5.1. This is my bad and I intended to fix it >> before the 1.5 release; however Nathan CfV'ed before I returned from >> holidays and the voting period is already over. >Not too late to vote. 72 hours was the minimum voting period. I'm >managing this release, the vote is over when i send a result. Uhm. Don't tempt me. While I'm fed up with delaying and want to have that bugger out, here is what I've found: a) The link problem with the maven site. I have a patch for the guides which will go into trunk shortly. b) The checksum thing. Fixed on the trunk c) The package build thing (restrict on 1.4). I've put a patch on the trunk which might need more discussion. d) The POM references to the branch, not the tag. Considering the fact that Will -1'ed the last release attempt for a documentation issue, personally I'd weight at least d) much more than that. However, I believe that we can release a 1.5.1 4-6 weeks after 1.5 to amend that, so I will not block this vote. I would very much suggest that we target the next tuesday for the official release announcement. This gives us and the mirrors a few days to get our acts together. Lets push this out. Now! Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person|eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fürth, HRB 7350|a s Sitz der Gesellschaft: Buckenhof. Geschäftsführer: Henning Schmiedehausen |n "Save the cheerleader. Save the world." - 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: Velocity 1.5 Release - SVN Revision?
On 3/6/07, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: "Nathan Bubna" <[EMAIL PROTECTED]> writes: My vote is reluctantly +1, because the "I want to get it out" weights more for me than the issues that I have found: >> BTW: Strictly spoken are the references in the POM wrong because they >> should not reference .../branches/VELOCITY_1.5_BRANCH/ but >> .../tags/VELOCITY_1.5/ >They aren't wrong unless/until we do further dev on the branch, in >which case, we should do a 1.5.x release. So, it hardly matters. Yes, it does. If we do further development, then trying to rebuild the site from the release package will give different results. Which probably does not matter much, but it would matter to me. i don't see why rebuilding using the source in the release would produce a result different than itself. and what does the site have to do with this? just trying to understand... IMHO we will at least have an 1.5.1 to fix the issues listed below: >> This means that rebuilding 1.5 from source will actually be difficult, >> once we think about 1.5.1. This is my bad and I intended to fix it >> before the 1.5 release; however Nathan CfV'ed before I returned from >> holidays and the voting period is already over. >Not too late to vote. 72 hours was the minimum voting period. I'm >managing this release, the vote is over when i send a result. Uhm. Don't tempt me. While I'm fed up with delaying and want to have that bugger out, here is what I've found: a) The link problem with the maven site. I have a patch for the guides which will go into trunk shortly. b) The checksum thing. Fixed on the trunk c) The package build thing (restrict on 1.4). I've put a patch on the trunk which might need more discussion. d) The POM references to the branch, not the tag. Considering the fact that Will -1'ed the last release attempt for a documentation issue, personally I'd weight at least d) much more than that. However, I believe that we can release a 1.5.1 4-6 weeks after 1.5 to amend that, so I will not block this vote. thank you. it's about time we stopped fretting over minor issues in the build and documentation. the goal is always perfection, but the requirement is merely high quality (especially, higher quality than the previous GA release, which we achieved ages ago). I would very much suggest that we target the next tuesday for the official release announcement. This gives us and the mirrors a few days to get our acts together. Will or you can do the official announcement whenever you like. in the meantime, i'll do the result, the push to the mirrors, and the site update ASAP. Lets push this out. Now! Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person|eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fürth, HRB 7350|a s Sitz der Gesellschaft: Buckenhof. Geschäftsführer: Henning Schmiedehausen |n "Save the cheerleader. Save the world." - 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]
[RESULT] [VOTE] Release Velocity Engine 1.5
Ok, i think 12 days is a sufficiently long voting period. Geir & Marino, i can only assume you have no objections. :) +1's from: Nathan Bubna Claude Brisson Malcolm Edgar Will Glass-Husain mailmur Henning Schmiedehausen No other votes were recorded, and there were enough PMC +1s to approve the release. I will push the files out for mirroring and update the site as soon as most mirrors have picked it up. It sounds like the official announcement will not happen until Tuesday, but i believe Velocity Engine 1.5 should be available for download off most mirrors by tomorrow evening. On 2/22/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: Ok, Will has fixed the doc issues that made him -1 the last test build, as well as a minor bug in the new SecureUberspect. All the tests pass, the build looks solid to me, and the included velocity-1.5.jar works just dandy with the VelocityTools example apps. The test build for this release is available at: http://people.apache.org/~nbubna/velocity/engine/1.5/ Please check out the build to make sure i haven't missed anything important and vote regarding your support for releasing this test build as the long-awaited Velocity 1.5: [ ] +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 10am PST on Saturday, Feb 24th. If i do not find time amidst yardwork 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]
Re: Velocity 1.5 Release - SVN Revision?
If you'd prefer, i'd be happy to cede the update of the web site to you or at least enlist your help. I've got things working adequately, but not splendidly. Things left to be done for the 1.5 release are: - use mvn to deploy the changes i just checked in this morning. i'm waiting until a few more mirrors pick up the build before i do that. - update the "Engine 1.5" subsection. i'm not entirely sure how you do this. currently, there is an older version (from one of your attempted releases in January, i presume) up at http://velocity.apache.org/engine/releases/velocity-1.5/, but this doesn't reflect any changes since then (e.g. the change log doesn't show the fix for SecureUberspector). i'm not sure yet what the procedure for doing this is. then, once the site is fully updated, i'll remove the old releases (1.4 and 1.5-beta2) from http://www.apache.org/dist/velocity/engine/, and we'll be ready to announce it all. On 3/6/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote: The non-working links on the dev-guide and user-guide page have already been mentioned by at least one user. If one builds the release web site from the source, then these will be very prominently visible. I will doctor the links for the release, though. :-) Best regards Henning On Tue, 2007-03-06 at 08:40 -0800, Will Glass-Husain wrote: > Good catches. > > A missing doc page and bad link would have been immediately visible to > the casual user, while you are pointing more subtle flaws. Likely no > one will actually notice the POM issue, especially if we follow with a > 1.5.1 release. > > Looking forward to starting a discussion about future Road Map. I > made some edits on the Wiki a few weeks ago. > > WILL > > On 3/6/07, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: > > "Nathan Bubna" <[EMAIL PROTECTED]> writes: > > > > My vote is reluctantly +1, because the "I want to get it out" weights > > more for me than the issues that I have found: > > > > >> BTW: Strictly spoken are the references in the POM wrong because they > > >> should not reference .../branches/VELOCITY_1.5_BRANCH/ but > > >> .../tags/VELOCITY_1.5/ > > > > >They aren't wrong unless/until we do further dev on the branch, in > > >which case, we should do a 1.5.x release. So, it hardly matters. > > > > Yes, it does. If we do further development, then trying to rebuild the > > site from the release package will give different results. Which > > probably does not matter much, but it would matter to me. > > > > IMHO we will at least have an 1.5.1 to fix the issues listed below: > > > > >> This means that rebuilding 1.5 from source will actually be difficult, > > >> once we think about 1.5.1. This is my bad and I intended to fix it > > >> before the 1.5 release; however Nathan CfV'ed before I returned from > > >> holidays and the voting period is already over. > > > > >Not too late to vote. 72 hours was the minimum voting period. I'm > > >managing this release, the vote is over when i send a result. > > > > Uhm. Don't tempt me. While I'm fed up with delaying and want to have > > that bugger out, here is what I've found: > > > > a) The link problem with the maven site. I have a patch for the guides which > >will go into trunk shortly. > > > > b) The checksum thing. Fixed on the trunk > > > > c) The package build thing (restrict on 1.4). I've put a patch on the trunk > >which might need more discussion. > > > > d) The POM references to the branch, not the tag. > > > > Considering the fact that Will -1'ed the last release attempt for a > > documentation issue, personally I'd weight at least d) much more than > > that. However, I believe that we can release a 1.5.1 4-6 weeks after > > 1.5 to amend that, so I will not block this vote. > > > > I would very much suggest that we target the next tuesday for the > > official release announcement. This gives us and the mirrors a few > > days to get our acts together. > > > > Lets push this out. Now! > > > > Best regards > > Henning > > > > > > -- > > Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls > > 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau > > Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc > > |m k &g
Re: Releasing it (was: Re: Velocity 1.5 Release - SVN Revision?)
On 3/6/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote: On Tue, 2007-03-06 at 10:09 -0800, Nathan Bubna wrote: > If you'd prefer, i'd be happy to cede the update of the web site to > you or at least enlist your help. I've got things working adequately, > but not splendidly. Things left to be done for the 1.5 release are: As you wish. I can build it if you want me to. With the zone now finally being available I'm currently setting up ant, maven and all that stuff so we can build from a common environment. that'd be good. if you haven't noticed, i've had to disable the news macro and roughly mimic it's results by hand. if you can make it work properly, i think that would be preferable. of course, i do want us to figure out how to make it work fully for others besides you, but we can do that later. :) > > - use mvn to deploy the changes i just checked in this morning. i'm > waiting until a few more mirrors pick up the build before i do that. Sure. These are changes to the Velocity Site, right? yep. updated the download page, the doap descriptor, the front page and the menu sidebar thing. > > - update the "Engine 1.5" subsection. i'm not entirely sure how you > do this. currently, there is an older version (from one of your > attempted releases in January, i presume) up at > http://velocity.apache.org/engine/releases/velocity-1.5/, but this > doesn't reflect any changes since then (e.g. the change log doesn't > show the fix for SecureUberspector). i'm not sure yet what the > procedure for doing this is. In the engine release, run "mvn clean post-site site:deploy". That should push the release version of the site up. This should overwrite all the files you mentioned. let me give this part a try. i haven't done this yet and would like to see it work for me. - create the release tag. That why I asked about the revision. I did svn -m "Velocity 1.5 Release" copy -r 509925 \ https://svn.apache.org/repos/asf/velocity/engine/branches/Velocity_1.5_BRANCH \ https://svn.apache.org/repos/asf/velocity/engine/tags/Velocity_1.5 yeah, i saw that. thanks. for that. I MD5 checked the files from the branch and the tag and they all checked out ok, even though the files on the tag technically have another revision number. that's to be expected. revision numbers are only updated in files which are changed and which have the $Id$ thingy in 'em. - Deploy the release to the maven repo. another thing i've never done. i presume there's a magic maven command for this too? Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing it (was: Re: Velocity 1.5 Release - SVN Revision?)
On 3/6/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: On 3/6/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote: > On Tue, 2007-03-06 at 10:09 -0800, Nathan Bubna wrote: > > If you'd prefer, i'd be happy to cede the update of the web site to > > you or at least enlist your help. I've got things working adequately, > > but not splendidly. Things left to be done for the 1.5 release are: > > As you wish. I can build it if you want me to. With the zone now finally > being available I'm currently setting up ant, maven and all that stuff > so we can build from a common environment. that'd be good. if you haven't noticed, i've had to disable the news macro and roughly mimic it's results by hand. if you can make it work properly, i think that would be preferable. of course, i do want us to figure out how to make it work fully for others besides you, but we can do that later. ok, i deployed the site using the site module as it is in svn (with the news macro disabled and hand-mimicked). you're of course still quite welcome to re-update with the news macro working, and to fix and bad in-page anchors or whatever. so, the public now has access to Velocity 1.5 from our download page, if they happen to visit the web site before the announcements go out by email. > > - use mvn to deploy the changes i just checked in this morning. i'm > > waiting until a few more mirrors pick up the build before i do that. > > Sure. These are changes to the Velocity Site, right? yep. updated the download page, the doap descriptor, the front page and the menu sidebar thing. > > > > - update the "Engine 1.5" subsection. i'm not entirely sure how you > > do this. currently, there is an older version (from one of your > > attempted releases in January, i presume) up at > > http://velocity.apache.org/engine/releases/velocity-1.5/, but this > > doesn't reflect any changes since then (e.g. the change log doesn't > > show the fix for SecureUberspector). i'm not sure yet what the > > procedure for doing this is. > > In the engine release, run "mvn clean post-site site:deploy". That > should push the release version of the site up. This should overwrite > all the files you mentioned. let me give this part a try. i haven't done this yet and would like to see it work for me. it appears to have worked just fine... > - create the release tag. That why I asked about the revision. I did > > svn -m "Velocity 1.5 Release" copy -r 509925 \ > https://svn.apache.org/repos/asf/velocity/engine/branches/Velocity_1.5_BRANCH \ > https://svn.apache.org/repos/asf/velocity/engine/tags/Velocity_1.5 yeah, i saw that. thanks. > for that. I MD5 checked the files from the branch and the tag and they > all checked out ok, even though the files on the tag technically have > another revision number. that's to be expected. revision numbers are only updated in files which are changed and which have the $Id$ thingy in 'em. > - Deploy the release to the maven repo. another thing i've never done. i presume there's a magic maven command for this too? i think this last item and the email announcements are all that's left to be done. Will said he'd handle the PR. Anyone who wants to deploy 1.5 to the maven repo or tell me how to do it is welcome to do so. > Best regards > Henning > > -- > Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls > 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau > Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc > |m k > INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s > Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing it (was: Re: Velocity 1.5 Release - SVN Revision?)
I don't mind much either way, but i was given the impression from previous discussion that first thing Tuesday morning (presumably east coast time) was the ideal time for that. On 3/6/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: Do you want me to send the email announcements? I can do this tonight. WILL On 3/6/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > On 3/6/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > On 3/6/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote: > > > On Tue, 2007-03-06 at 10:09 -0800, Nathan Bubna wrote: > > > > If you'd prefer, i'd be happy to cede the update of the web site to > > > > you or at least enlist your help. I've got things working > adequately, > > > > but not splendidly. Things left to be done for the 1.5 release are: > > > > > > As you wish. I can build it if you want me to. With the zone now > finally > > > being available I'm currently setting up ant, maven and all that stuff > > > so we can build from a common environment. > > > > that'd be good. if you haven't noticed, i've had to disable the news > > macro and roughly mimic it's results by hand. if you can make it work > > properly, i think that would be preferable. of course, i do want us > > to figure out how to make it work fully for others besides you, but we > > can do that later. > ok, i deployed the site using the site module as it is in svn (with > the news macro disabled and hand-mimicked). you're of course still > quite welcome to re-update with the news macro working, and to fix and > bad in-page anchors or whatever. > > so, the public now has access to Velocity 1.5 from our download page, > if they happen to visit the web site before the announcements go out > by email. > > > > > - use mvn to deploy the changes i just checked in this morning. i'm > > > > waiting until a few more mirrors pick up the build before i do that. > > > > > > Sure. These are changes to the Velocity Site, right? > > > > yep. updated the download page, the doap descriptor, the front page > > and the menu sidebar thing. > > > > > > > > > > - update the "Engine 1.5" subsection. i'm not entirely sure how you > > > > do this. currently, there is an older version (from one of your > > > > attempted releases in January, i presume) up at > > > > http://velocity.apache.org/engine/releases/velocity-1.5/, but this > > > > doesn't reflect any changes since then (e.g. the change log doesn't > > > > show the fix for SecureUberspector). i'm not sure yet what the > > > > procedure for doing this is. > > > > > > In the engine release, run "mvn clean post-site site:deploy". That > > > should push the release version of the site up. This should overwrite > > > all the files you mentioned. > > > > let me give this part a try. i haven't done this yet and would like > > to see it work for me. > > it appears to have worked just fine... > > > > - create the release tag. That why I asked about the revision. I did > > > > > > svn -m "Velocity 1.5 Release" copy -r 509925 \ > > > > https://svn.apache.org/repos/asf/velocity/engine/branches/Velocity_1.5_BRANCH\ > > > https://svn.apache.org/repos/asf/velocity/engine/tags/Velocity_1.5 > > > > yeah, i saw that. thanks. > > > > > for that. I MD5 checked the files from the branch and the tag and they > > > all checked out ok, even though the files on the tag technically have > > > another revision number. > > > > that's to be expected. revision numbers are only updated in files > > which are changed and which have the $Id$ thingy in 'em. > > > > > - Deploy the release to the maven repo. > > > > another thing i've never done. i presume there's a magic maven > > command for this too? > > i think this last item and the email announcements are all that's left > to be done. Will said he'd handle the PR. Anyone who wants to deploy > 1.5 to the maven repo or tell me how to do it is welcome to do so. > > > > Best regards > > > Henning > > > > > > -- > > > Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, > Linux, |gls > > > 91054 Buckenhof, Germany -- +49 9131 506540 | Apache > person |eau > > > Open Source Consulting, Development, Design| Velocity - Turbine > guy |rwc > > > > > |m k > > > INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB > 7350 |a s > > > Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning > Schmiedehausen |n > > > > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing it (was: Re: Velocity 1.5 Release - SVN Revision?)
On 3/6/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote: Hi, thanks for doing this! It seems that this process is still a bit rough and it is one of my top priorities to get this smoother and that we can run it from the zone. that would be great. I've did a minor update on the main page, there was still 1.4 as release and 1.5 beta 2 as beta listed. thanks! I noticed that for the site, the pages that go through the velocity/doxia renderer did not get updated (they still had 1.4 as release), so I assume that this is one of the rough edges. Will look into this. the other problem i had, which may not have been obvious, was that the download.cgi page got updated with the wrong permissions (only readable, not executable). i had to manually fix this. not sure why it happened. Also for the Engine site, the JIRA report listed only a few issues, this might be a problem with the jira report plugin (I've contributed lots of fixes here). i noticed that there weren't many there, but i couldn't remember if there were a lot beforehand. (i.e. i didn't know if my update introduced that or not). I've deployed both sites again, they should be fine now. thanks again! feel free to use me as a guinea pig to test out you changes as you smooth things out. i want to make sure i can update the site as well. also, it would be good to switch the veltools docs to the same process eventually (once i trust it), so the more i figure this out the better. i do at least see that this has more potential than the old process. it's just been a very, very rough learning curve. Best regards Henning On Tue, 2007-03-06 at 17:27 -0800, Nathan Bubna wrote: > On 3/6/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > On 3/6/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote: > > > On Tue, 2007-03-06 at 10:09 -0800, Nathan Bubna wrote: > > > > If you'd prefer, i'd be happy to cede the update of the web site to > > > > you or at least enlist your help. I've got things working adequately, > > > > but not splendidly. Things left to be done for the 1.5 release are: > > > > > > As you wish. I can build it if you want me to. With the zone now finally > > > being available I'm currently setting up ant, maven and all that stuff > > > so we can build from a common environment. > > > > that'd be good. if you haven't noticed, i've had to disable the news > > macro and roughly mimic it's results by hand. if you can make it work > > properly, i think that would be preferable. of course, i do want us > > to figure out how to make it work fully for others besides you, but we > > can do that later. > ok, i deployed the site using the site module as it is in svn (with > the news macro disabled and hand-mimicked). you're of course still > quite welcome to re-update with the news macro working, and to fix and > bad in-page anchors or whatever. > > so, the public now has access to Velocity 1.5 from our download page, > if they happen to visit the web site before the announcements go out > by email. > > > > > - use mvn to deploy the changes i just checked in this morning. i'm > > > > waiting until a few more mirrors pick up the build before i do that. > > > > > > Sure. These are changes to the Velocity Site, right? > > > > yep. updated the download page, the doap descriptor, the front page > > and the menu sidebar thing. > > > > > > > > > > - update the "Engine 1.5" subsection. i'm not entirely sure how you > > > > do this. currently, there is an older version (from one of your > > > > attempted releases in January, i presume) up at > > > > http://velocity.apache.org/engine/releases/velocity-1.5/, but this > > > > doesn't reflect any changes since then (e.g. the change log doesn't > > > > show the fix for SecureUberspector). i'm not sure yet what the > > > > procedure for doing this is. > > > > > > In the engine release, run "mvn clean post-site site:deploy". That > > > should push the release version of the site up. This should overwrite > > > all the files you mentioned. > > > > let me give this part a try. i haven't done this yet and would like > > to see it work for me. > > it appears to have worked just fine... > > > > - create the release tag. That why I asked about the revision. I did > > > > > > svn -m "Velocity 1.5 Release" copy -r 509925 \ > > > https://svn.apache.org/repos/asf/velocity/engine/branches/Velocity_1.5_BRANCH
