Cool! But it is, of course, still better to submit patches via the issue tracker, so we don't lose them in the mounds of email most of us get.
Also, i wonder if the ASL v1 provided for this easy patch acceptance. I'm not generally in the habit of imagining legal requirements. So either i got my confusion from incorrect hearsay or it used to be that way. (i have been around here a long time). On Mon, Oct 1, 2012 at 5:15 PM, Benson Margulies <bimargul...@gmail.com> wrote: > On Mon, Oct 1, 2012 at 8:06 PM, Sergiu Dumitriu > <sergiu.dumit...@gmail.com> wrote: >> On 10/01/2012 07:29 PM, Benson Margulies wrote: >>> >>> yes you are! it's explicitly provided for in the apache license. >> >> >> I don't think this is a licensing issue, but a copyright issue. > > Quoting the Apache License: > > "Contribution" shall mean any work of authorship, including the > original version of the Work and any modifications or additions to > that Work or Derivative Works thereof, that is intentionally submitted > to Licensor for inclusion in the Work by the copyright owner or by an > individual or Legal Entity authorized to submit on behalf of the > copyright owner. For the purposes of this definition, "submitted" > means any form of electronic, verbal, or written communication sent to > the Licensor or its representatives, including but not limited to > communication on electronic mailing lists, source code control > systems, and issue tracking systems that are managed by, or on behalf > of, the Licensor for the purpose of discussing and improving the Work, > but excluding communication that is conspicuously marked or otherwise > designated in writing by the copyright owner as "Not a Contribution." > > If you send a patch (thus creating a derivative work of an AL work) to > an Apache mailing list, and don't explicitly write 'not a > contribution', it's a contribution. > > > >> >> Anyway, this would indeed be a very nice change. >> >>> On Oct 1, 2012, at 7:20 PM, Nathan Bubna <nbu...@gmail.com> wrote: >>> >>>> That looks like a great improvement! We aren't generally supposed to >>>> accept patches from email attachments (licensing or some such). Can >>>> you create an issue in JIRA for this enhancement and post the diff >>>> there? http://issues.apache.org >>>> >>>> On Mon, Oct 1, 2012 at 12:42 PM, Luke Perkins <lperk...@tripadvisor.com> >>>> wrote: >>>>> >>>>> Hey guys I made a patch to Velocity 1.7 to enable you to print out >>>>> velocity stack traces. If you dump a stack trace in a Java function that >>>>> was >>>>> called from a velocity file, you usually see a bunch of calls to velocity >>>>> parser functions like this in the Java stack trace: >>>>> >>>>> ... >>>>> at >>>>> org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:209) >>>>> at >>>>> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280) >>>>> at >>>>> org.apache.velocity.runtime.parser.node.ASTReference.evaluate(ASTReference.java:530) >>>>> at >>>>> org.apache.velocity.runtime.parser.node.ASTExpression.evaluate(ASTExpression.java:62) >>>>> at >>>>> org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:85) >>>>> at >>>>> org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) >>>>> at >>>>> org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:87) >>>>> at >>>>> org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) >>>>> at >>>>> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:216) >>>>> at >>>>> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:312) >>>>> at >>>>> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230) >>>>> at >>>>> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207) >>>>> at >>>>> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342) >>>>> at >>>>> org.apache.velocity.runtime.parser.node.ASTStringLiteral.value(ASTStringLiteral.java:330) >>>>> ... >>>>> >>>>> The velocity stack trace created by this patches is much more >>>>> informative: >>>>> >>>>> Velocity Stack Trace: Invocation of method 'getAvatarUrl' in class >>>>> Member >>>>> at avatarUrl called at common/Macros.vm[line 426, column 29] >>>>> at simpleAvatarUrl called at common/Macros.vm[line 487, column >>>>> 22] >>>>> at drawSimpleImage called at common/Macros.vm[line 487, column >>>>> 3] >>>>> at simpleMemberAvatar called at site/photo_pane.vm[line 153, >>>>> column 32] >>>>> at displayAvatarImage called at site/photo_pane.vm[line 162, >>>>> column 3] >>>>> >>>>> This sort of stack trace is very useful when debugging code and trying >>>>> to figure out which sequence of macros called into the currently executing >>>>> Java code that dumped out the Java stack trace. Please consider adding >>>>> something like this to a future release of Velocity - it would be very >>>>> useful! >>>>> >>>>> Thanks, >>>>> Luke >> >> >> -- >> Sergiu Dumitriu >> http://purl.org/net/sergiu/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org >> For additional commands, e-mail: dev-h...@velocity.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org > For additional commands, e-mail: dev-h...@velocity.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
