Re: macro issues
Will Glass-Husain [EMAIL PROTECTED] writes: Sure, go ahead. I thought the wiki page to be sufficient but if you feel more comfortable with having it in JIRA, I'm all +1 for that. Best regards Henning Henning, I noticed you closed all the Macro-related JIRA issues. I see this as a usability barrier and something we should definitely address in a future version. In particular, the need to be able to #parse a file that includes macros is important. I'd like to reopen the issues. They serve as a reminder to address these issues for 1.6. But I don't want to get into a open/close/open/close fight. Any comments before I do this? (see http://blogs.codehaus.org/people/geir/archives/001414_somtimes_process_is_good_somtimes_not.html ) 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] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macro issues
Great, will do. A little more detail on when I think we should mark WONTFIX (lets discuss). I think it's nice to have enhancement requests/future thoughts in JIRA. The wont fix is rather offputting. There's a continuum for responses to enhancement requests.. -- committers really enthusiastic about idea; will certainly go in -- idea fits with philosophical direction of tool, might go in but not right now -- idea is from left field, will likely not go in I'd suggest we always leave the first two bullets as open issues. Helps capture usage details, example cases, mailing list threads. The third is a matter of judgement. Doesn't hurt to occasionally leave a creative idea open, but more often we should provide feedback and (if appropriate) ask the poster to move sample code to the wiki. A good rule of thumb should be that all active committers believe an idea is from left field in order to mark WONTFIX. Or at least that it's ok for a committer who's interested in immediate reopen the issue. Just my thoughts. Comments? WILL On 11/6/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Will Glass-Husain [EMAIL PROTECTED] writes: Sure, go ahead. I thought the wiki page to be sufficient but if you feel more comfortable with having it in JIRA, I'm all +1 for that. Best regards Henning Henning, I noticed you closed all the Macro-related JIRA issues. I see this as a usability barrier and something we should definitely address in a future version. In particular, the need to be able to #parse a file that includes macros is important. I'd like to reopen the issues. They serve as a reminder to address these issues for 1.6. But I don't want to get into a open/close/open/close fight. Any comments before I do this? (see http://blogs.codehaus.org/people/geir/archives/001414_somtimes_process_is_good_somtimes_not.html ) 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] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - 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: macro issues
On 11/6/06, Will Glass-Husain [EMAIL PROTECTED] wrote: Great, will do. A little more detail on when I think we should mark WONTFIX (lets discuss). I think it's nice to have enhancement requests/future thoughts in JIRA. The wont fix is rather offputting. agreed. but it is better than silently ignoring such things. i think it's more polite if a committer responds with a strong negative than if no one responds. There's a continuum for responses to enhancement requests.. -- committers really enthusiastic about idea; will certainly go in -- idea fits with philosophical direction of tool, might go in but not right now -- idea is from left field, will likely not go in I'd suggest we always leave the first two bullets as open issues. Helps capture usage details, example cases, mailing list threads. +1 The third is a matter of judgement. Doesn't hurt to occasionally leave a creative idea open, but more often we should provide feedback and (if appropriate) ask the poster to move sample code to the wiki. +1 pushing the wiki is very good A good rule of thumb should be that all active committers believe an idea is from left field in order to mark WONTFIX. +1 if and only if... Or at least that it's ok for a committer who's interested in immediate reopen the issue. this is the canonical process. close if you don't like it. if no committer re-opens, then that means no interest. this is more workable than seeking acks on a motion to close an issue. Just my thoughts. Comments? WILL On 11/6/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Will Glass-Husain [EMAIL PROTECTED] writes: Sure, go ahead. I thought the wiki page to be sufficient but if you feel more comfortable with having it in JIRA, I'm all +1 for that. Best regards Henning Henning, I noticed you closed all the Macro-related JIRA issues. I see this as a usability barrier and something we should definitely address in a future version. In particular, the need to be able to #parse a file that includes macros is important. I'd like to reopen the issues. They serve as a reminder to address these issues for 1.6. But I don't want to get into a open/close/open/close fight. Any comments before I do this? (see http://blogs.codehaus.org/people/geir/archives/001414_somtimes_process_is_good_somtimes_not.html ) 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] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - 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: macro issues
Will Glass-Husain [EMAIL PROTECTED] writes: Great, will do. A little more detail on when I think we should mark WONTFIX (lets discuss). I think it's nice to have enhancement requests/future thoughts in JIRA. The wont fix is rather offputting. There's a continuum for responses to enhancement requests.. -- committers really enthusiastic about idea; will certainly go in -- idea fits with philosophical direction of tool, might go in but not right now -- idea is from left field, will likely not go in I'd suggest we always leave the first two bullets as open issues. Helps capture usage details, example cases, mailing list threads. While I agree with that, I still say that we want to close issues at some point. And wontfix is IMHO a valid response. Issues falling in the middle category will always be subject to discussion anyway, so we can move these to the mailing list / Wiki. If we keep issues open indefinitely we will always have nn open issues for any given part of the system. Next to being bad press (and we all remember people showing up here and bean-counting open bugs, don't we?), they also tend to hide the real bug reports. I agree that we could resolve as Later. :-) Best regards Henning The third is a matter of judgement. Doesn't hurt to occasionally leave a creative idea open, but more often we should provide feedback and (if appropriate) ask the poster to move sample code to the wiki. A good rule of thumb should be that all active committers believe an idea is from left field in order to mark WONTFIX. Or at least that it's ok for a committer who's interested in immediate reopen the issue. Just my thoughts. Comments? WILL On 11/6/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Will Glass-Husain [EMAIL PROTECTED] writes: Sure, go ahead. I thought the wiki page to be sufficient but if you feel more comfortable with having it in JIRA, I'm all +1 for that. Best regards Henning Henning, I noticed you closed all the Macro-related JIRA issues. I see this as a usability barrier and something we should definitely address in a future version. In particular, the need to be able to #parse a file that includes macros is important. I'd like to reopen the issues. They serve as a reminder to address these issues for 1.6. But I don't want to get into a open/close/open/close fight. Any comments before I do this? (see http://blogs.codehaus.org/people/geir/archives/001414_somtimes_process_is_good_somtimes_not.html ) 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] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - 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] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macro issues
Nathan Bubna [EMAIL PROTECTED] writes: +1 if and only if... Or at least that it's ok for a committer who's interested in immediate reopen the issue. this is the canonical process. close if you don't like it. if no committer re-opens, then that means no interest. this is more workable than seeking acks on a motion to close an issue. To be nit-picking: We are resolving the issue. Not closing it. :-) So they all will be touched one more time by closing resolved issues. Best regards Henning Just my thoughts. Comments? WILL On 11/6/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Will Glass-Husain [EMAIL PROTECTED] writes: Sure, go ahead. I thought the wiki page to be sufficient but if you feel more comfortable with having it in JIRA, I'm all +1 for that. Best regards Henning Henning, I noticed you closed all the Macro-related JIRA issues. I see this as a usability barrier and something we should definitely address in a future version. In particular, the need to be able to #parse a file that includes macros is important. I'd like to reopen the issues. They serve as a reminder to address these issues for 1.6. But I don't want to get into a open/close/open/close fight. Any comments before I do this? (see http://blogs.codehaus.org/people/geir/archives/001414_somtimes_process_is_good_somtimes_not.html ) 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] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - 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] -- 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]
Re: macro issues
sounds reasonable. As long as we're okay with reopening issues. WILL On 11/6/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Will Glass-Husain [EMAIL PROTECTED] writes: Great, will do. A little more detail on when I think we should mark WONTFIX (lets discuss). I think it's nice to have enhancement requests/future thoughts in JIRA. The wont fix is rather offputting. There's a continuum for responses to enhancement requests.. -- committers really enthusiastic about idea; will certainly go in -- idea fits with philosophical direction of tool, might go in but not right now -- idea is from left field, will likely not go in I'd suggest we always leave the first two bullets as open issues. Helps capture usage details, example cases, mailing list threads. While I agree with that, I still say that we want to close issues at some point. And wontfix is IMHO a valid response. Issues falling in the middle category will always be subject to discussion anyway, so we can move these to the mailing list / Wiki. If we keep issues open indefinitely we will always have nn open issues for any given part of the system. Next to being bad press (and we all remember people showing up here and bean-counting open bugs, don't we?), they also tend to hide the real bug reports. I agree that we could resolve as Later. :-) Best regards Henning The third is a matter of judgement. Doesn't hurt to occasionally leave a creative idea open, but more often we should provide feedback and (if appropriate) ask the poster to move sample code to the wiki. A good rule of thumb should be that all active committers believe an idea is from left field in order to mark WONTFIX. Or at least that it's ok for a committer who's interested in immediate reopen the issue. Just my thoughts. Comments? WILL On 11/6/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Will Glass-Husain [EMAIL PROTECTED] writes: Sure, go ahead. I thought the wiki page to be sufficient but if you feel more comfortable with having it in JIRA, I'm all +1 for that. Best regards Henning Henning, I noticed you closed all the Macro-related JIRA issues. I see this as a usability barrier and something we should definitely address in a future version. In particular, the need to be able to #parse a file that includes macros is important. I'd like to reopen the issues. They serve as a reminder to address these issues for 1.6. But I don't want to get into a open/close/open/close fight. Any comments before I do this? (see http://blogs.codehaus.org/people/geir/archives/001414_somtimes_process_is_good_somtimes_not.html ) 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] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - 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] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - 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: macro issues
We have a separate Resolved vs Closed category? Just checked - you're right. Seems unnecessarily onerous to me. Once the issue is done, it's done. Should be the same thing. WILL On 11/6/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Nathan Bubna [EMAIL PROTECTED] writes: +1 if and only if... Or at least that it's ok for a committer who's interested in immediate reopen the issue. this is the canonical process. close if you don't like it. if no committer re-opens, then that means no interest. this is more workable than seeking acks on a motion to close an issue. To be nit-picking: We are resolving the issue. Not closing it. :-) So they all will be touched one more time by closing resolved issues. Best regards Henning Just my thoughts. Comments? WILL On 11/6/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Will Glass-Husain [EMAIL PROTECTED] writes: Sure, go ahead. I thought the wiki page to be sufficient but if you feel more comfortable with having it in JIRA, I'm all +1 for that. Best regards Henning Henning, I noticed you closed all the Macro-related JIRA issues. I see this as a usability barrier and something we should definitely address in a future version. In particular, the need to be able to #parse a file that includes macros is important. I'd like to reopen the issues. They serve as a reminder to address these issues for 1.6. But I don't want to get into a open/close/open/close fight. Any comments before I do this? (see http://blogs.codehaus.org/people/geir/archives/001414_somtimes_process_is_good_somtimes_not.html ) 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] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - 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] -- 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]
Re: macro issues
Nope, the idea is that the developer resolves the issue and the release manager, once a release is done, closes it. AFAIK, JIRA can build nice change logs out of resolved issues for a release. Best regards Henning On Mon, 2006-11-06 at 11:41 -0800, Will Glass-Husain wrote: We have a separate Resolved vs Closed category? Just checked - you're right. Seems unnecessarily onerous to me. Once the issue is done, it's done. Should be the same thing. WILL On 11/6/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Nathan Bubna [EMAIL PROTECTED] writes: +1 if and only if... Or at least that it's ok for a committer who's interested in immediate reopen the issue. this is the canonical process. close if you don't like it. if no committer re-opens, then that means no interest. this is more workable than seeking acks on a motion to close an issue. To be nit-picking: We are resolving the issue. Not closing it. :-) So they all will be touched one more time by closing resolved issues. Best regards Henning Just my thoughts. Comments? WILL On 11/6/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Will Glass-Husain [EMAIL PROTECTED] writes: Sure, go ahead. I thought the wiki page to be sufficient but if you feel more comfortable with having it in JIRA, I'm all +1 for that. Best regards Henning Henning, I noticed you closed all the Macro-related JIRA issues. I see this as a usability barrier and something we should definitely address in a future version. In particular, the need to be able to #parse a file that includes macros is important. I'd like to reopen the issues. They serve as a reminder to address these issues for 1.6. But I don't want to get into a open/close/open/close fight. Any comments before I do this? (see http://blogs.codehaus.org/people/geir/archives/001414_somtimes_process_is_good_somtimes_not.html ) 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] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - 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] -- 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] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development Linux, Java, perl, Solaris -- Consulting, Training, Engineering For a successful technology, reality must take precedence over public relations for Nature cannot be fooled - Richard P. Feynman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
macro issues
Henning, I noticed you closed all the Macro-related JIRA issues. I see this as a usability barrier and something we should definitely address in a future version. In particular, the need to be able to #parse a file that includes macros is important. I'd like to reopen the issues. They serve as a reminder to address these issues for 1.6. But I don't want to get into a open/close/open/close fight. Any comments before I do this? (see http://blogs.codehaus.org/people/geir/archives/001414_somtimes_process_is_good_somtimes_not.html ) 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]
Re: request for comments on Macro issues
Disclaimer: This stuff is pushing the edges of my understanding of Velocity internals; i know how velocimacros behave far better than i know how they are implemented internally. So, i'm not sure how competently i can comment here. Nonetheless, here are some thoughts... I've long thought macros could use a rewrite, but i'm skeptical that we can do that without breaking some key b.c. stuff. I suspect it might be wiser to stick to documented behavior for 1.5 and just fix what bugs we can for now. I'm more eager to see a 1.5 release than to have improved macro design. That can come later and perhaps be more thorough then? Regardless of when it is done, I've no idea if your proposed solution will work, nor have i time right now to dig into the matter more (no surprise there, i'm sure). If you think it will only fix bugs and add some new way(s) to use velocimacros without breaking the ways they are currently used, then i say go for it! That would be very cool. Your proposed calling page scope sounds quite good, but i don't think it would be wise to have this as the default for 1.5. We should stick to the current default for now. On 1/2/06, Will Glass-Husain [EMAIL PROTECTED] wrote: I posted a little note about the JIRA issues on macros on the wiki http://wiki.apache.org/jakarta-velocity/MacroIssues Once I dug into these issues, I realized the scope of macros seems rather odd. Specifically, various users have complained that you can't stick macros in a file called by #parse (I've run into this myself). This is documented but still rather unintuititive. The recommended action is to put such macros in a library, but that may not be feasible with a large heterogenous library of templates. (or a case where template writers do not have control of the environment). What I realized is that this is fundamentally due to a design issue rather than a bug. Would appreciate any comments on this interpretation and my proposed approach to solve this. Thanks, WILL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: request for comments on Macro issues
Thanks, Nathan... Appreciate the feedback - I was indeed looking for these types of general comments rather then specific technical points. Also, I wanted to point out to the community that we've had repeated bug reports on this item and it's a feature not a bug, i.e. it's an issue with the design instead of an easily fixable bug. (Rather than just keep these notes in my work journal I thought I'd post them to the Wiki.) On thinking about it, I'm not eager to do extensive rewrites in functionality (at this point) for 1.5, so these issues may get pushed back to 1.6 or 2.0 unless there's a revolt. Ultimately, I'd definitely like to see this work in a common sense way (i.e. be able to #parse a file with macros). But in the meantime we can point user's to this Wiki article. WILL - Original Message - From: Nathan Bubna [EMAIL PROTECTED] To: Velocity Developers List velocity-dev@jakarta.apache.org Sent: Tuesday, January 03, 2006 8:51 AM Subject: Re: request for comments on Macro issues Disclaimer: This stuff is pushing the edges of my understanding of Velocity internals; i know how velocimacros behave far better than i know how they are implemented internally. So, i'm not sure how competently i can comment here. Nonetheless, here are some thoughts... I've long thought macros could use a rewrite, but i'm skeptical that we can do that without breaking some key b.c. stuff. I suspect it might be wiser to stick to documented behavior for 1.5 and just fix what bugs we can for now. I'm more eager to see a 1.5 release than to have improved macro design. That can come later and perhaps be more thorough then? Regardless of when it is done, I've no idea if your proposed solution will work, nor have i time right now to dig into the matter more (no surprise there, i'm sure). If you think it will only fix bugs and add some new way(s) to use velocimacros without breaking the ways they are currently used, then i say go for it! That would be very cool. Your proposed calling page scope sounds quite good, but i don't think it would be wise to have this as the default for 1.5. We should stick to the current default for now. On 1/2/06, Will Glass-Husain [EMAIL PROTECTED] wrote: I posted a little note about the JIRA issues on macros on the wiki http://wiki.apache.org/jakarta-velocity/MacroIssues Once I dug into these issues, I realized the scope of macros seems rather odd. Specifically, various users have complained that you can't stick macros in a file called by #parse (I've run into this myself). This is documented but still rather unintuititive. The recommended action is to put such macros in a library, but that may not be feasible with a large heterogenous library of templates. (or a case where template writers do not have control of the environment). What I realized is that this is fundamentally due to a design issue rather than a bug. Would appreciate any comments on this interpretation and my proposed approach to solve this. Thanks, 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: request for comments on Macro issues
sounds good. and i agree it would be nice to be able to #parse a macro file and have them work in the parent template. another thing that might be good to keep in mind for 1.6/2.0 when we address some of these macro design issues is the possibility of supporting macros with bodies. i know that's likely to be 2.0 stuff, but i figure it doesn't hurt to keep it in mind. :) and i'll be more eager to help with that. On 1/3/06, Will Glass-Husain [EMAIL PROTECTED] wrote: Thanks, Nathan... Appreciate the feedback - I was indeed looking for these types of general comments rather then specific technical points. Also, I wanted to point out to the community that we've had repeated bug reports on this item and it's a feature not a bug, i.e. it's an issue with the design instead of an easily fixable bug. (Rather than just keep these notes in my work journal I thought I'd post them to the Wiki.) On thinking about it, I'm not eager to do extensive rewrites in functionality (at this point) for 1.5, so these issues may get pushed back to 1.6 or 2.0 unless there's a revolt. Ultimately, I'd definitely like to see this work in a common sense way (i.e. be able to #parse a file with macros). But in the meantime we can point user's to this Wiki article. WILL - Original Message - From: Nathan Bubna [EMAIL PROTECTED] To: Velocity Developers List velocity-dev@jakarta.apache.org Sent: Tuesday, January 03, 2006 8:51 AM Subject: Re: request for comments on Macro issues Disclaimer: This stuff is pushing the edges of my understanding of Velocity internals; i know how velocimacros behave far better than i know how they are implemented internally. So, i'm not sure how competently i can comment here. Nonetheless, here are some thoughts... I've long thought macros could use a rewrite, but i'm skeptical that we can do that without breaking some key b.c. stuff. I suspect it might be wiser to stick to documented behavior for 1.5 and just fix what bugs we can for now. I'm more eager to see a 1.5 release than to have improved macro design. That can come later and perhaps be more thorough then? Regardless of when it is done, I've no idea if your proposed solution will work, nor have i time right now to dig into the matter more (no surprise there, i'm sure). If you think it will only fix bugs and add some new way(s) to use velocimacros without breaking the ways they are currently used, then i say go for it! That would be very cool. Your proposed calling page scope sounds quite good, but i don't think it would be wise to have this as the default for 1.5. We should stick to the current default for now. On 1/2/06, Will Glass-Husain [EMAIL PROTECTED] wrote: I posted a little note about the JIRA issues on macros on the wiki http://wiki.apache.org/jakarta-velocity/MacroIssues Once I dug into these issues, I realized the scope of macros seems rather odd. Specifically, various users have complained that you can't stick macros in a file called by #parse (I've run into this myself). This is documented but still rather unintuititive. The recommended action is to put such macros in a library, but that may not be feasible with a large heterogenous library of templates. (or a case where template writers do not have control of the environment). What I realized is that this is fundamentally due to a design issue rather than a bug. Would appreciate any comments on this interpretation and my proposed approach to solve this. Thanks, 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: request for comments on Macro issues
Can you give an example of what you mean (macros with bodies)? Best, WILL - Original Message - From: Nathan Bubna [EMAIL PROTECTED] To: Velocity Developers List velocity-dev@jakarta.apache.org Sent: Tuesday, January 03, 2006 11:34 AM Subject: Re: request for comments on Macro issues sounds good. and i agree it would be nice to be able to #parse a macro file and have them work in the parent template. another thing that might be good to keep in mind for 1.6/2.0 when we address some of these macro design issues is the possibility of supporting macros with bodies. i know that's likely to be 2.0 stuff, but i figure it doesn't hurt to keep it in mind. :) and i'll be more eager to help with that. On 1/3/06, Will Glass-Husain [EMAIL PROTECTED] wrote: Thanks, Nathan... Appreciate the feedback - I was indeed looking for these types of general comments rather then specific technical points. Also, I wanted to point out to the community that we've had repeated bug reports on this item and it's a feature not a bug, i.e. it's an issue with the design instead of an easily fixable bug. (Rather than just keep these notes in my work journal I thought I'd post them to the Wiki.) On thinking about it, I'm not eager to do extensive rewrites in functionality (at this point) for 1.5, so these issues may get pushed back to 1.6 or 2.0 unless there's a revolt. Ultimately, I'd definitely like to see this work in a common sense way (i.e. be able to #parse a file with macros). But in the meantime we can point user's to this Wiki article. WILL - Original Message - From: Nathan Bubna [EMAIL PROTECTED] To: Velocity Developers List velocity-dev@jakarta.apache.org Sent: Tuesday, January 03, 2006 8:51 AM Subject: Re: request for comments on Macro issues Disclaimer: This stuff is pushing the edges of my understanding of Velocity internals; i know how velocimacros behave far better than i know how they are implemented internally. So, i'm not sure how competently i can comment here. Nonetheless, here are some thoughts... I've long thought macros could use a rewrite, but i'm skeptical that we can do that without breaking some key b.c. stuff. I suspect it might be wiser to stick to documented behavior for 1.5 and just fix what bugs we can for now. I'm more eager to see a 1.5 release than to have improved macro design. That can come later and perhaps be more thorough then? Regardless of when it is done, I've no idea if your proposed solution will work, nor have i time right now to dig into the matter more (no surprise there, i'm sure). If you think it will only fix bugs and add some new way(s) to use velocimacros without breaking the ways they are currently used, then i say go for it! That would be very cool. Your proposed calling page scope sounds quite good, but i don't think it would be wise to have this as the default for 1.5. We should stick to the current default for now. On 1/2/06, Will Glass-Husain [EMAIL PROTECTED] wrote: I posted a little note about the JIRA issues on macros on the wiki http://wiki.apache.org/jakarta-velocity/MacroIssues Once I dug into these issues, I realized the scope of macros seems rather odd. Specifically, various users have complained that you can't stick macros in a file called by #parse (I've run into this myself). This is documented but still rather unintuititive. The recommended action is to put such macros in a library, but that may not be feasible with a large heterogenous library of templates. (or a case where template writers do not have control of the environment). What I realized is that this is fundamentally due to a design issue rather than a bug. Would appreciate any comments on this interpretation and my proposed approach to solve this. Thanks, 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] - 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: request for comments on Macro issues
#macro( minilayout $style )
a bunch of stuff...
div style=$style
${BODY}
/div
a bit more stuff...
#end
#minilayout( color: red; )
This stuff should be rendered and then inserted where the BODY
reference is in the macro definition.
#end
at least, that's a rough idea. the body insertion part might be done
differently than a simple reference.
On 1/3/06, Will Glass-Husain [EMAIL PROTECTED] wrote:
Can you give an example of what you mean (macros with bodies)?
Best,
WILL
- Original Message -
From: Nathan Bubna [EMAIL PROTECTED]
To: Velocity Developers List velocity-dev@jakarta.apache.org
Sent: Tuesday, January 03, 2006 11:34 AM
Subject: Re: request for comments on Macro issues
sounds good. and i agree it would be nice to be able to #parse a
macro file and have them work in the parent template.
another thing that might be good to keep in mind for 1.6/2.0 when we
address some of these macro design issues is the possibility of
supporting macros with bodies. i know that's likely to be 2.0 stuff,
but i figure it doesn't hurt to keep it in mind. :) and i'll be more
eager to help with that.
On 1/3/06, Will Glass-Husain [EMAIL PROTECTED] wrote:
Thanks, Nathan...
Appreciate the feedback - I was indeed looking for these types of general
comments rather then specific technical points. Also, I wanted to point
out
to the community that we've had repeated bug reports on this item and
it's
a feature not a bug, i.e. it's an issue with the design instead of an
easily fixable bug. (Rather than just keep these notes in my work journal
I
thought I'd post them to the Wiki.)
On thinking about it, I'm not eager to do extensive rewrites in
functionality (at this point) for 1.5, so these issues may get pushed back
to 1.6 or 2.0 unless there's a revolt. Ultimately, I'd definitely like
to
see this work in a common sense way (i.e. be able to #parse a file with
macros). But in the meantime we can point user's to this Wiki article.
WILL
- Original Message -
From: Nathan Bubna [EMAIL PROTECTED]
To: Velocity Developers List velocity-dev@jakarta.apache.org
Sent: Tuesday, January 03, 2006 8:51 AM
Subject: Re: request for comments on Macro issues
Disclaimer: This stuff is pushing the edges of my understanding of
Velocity internals; i know how velocimacros behave far better than i
know how they are implemented internally. So, i'm not sure how
competently i can comment here. Nonetheless, here are some
thoughts...
I've long thought macros could use a rewrite, but i'm skeptical that
we can do that without breaking some key b.c. stuff. I suspect it
might be wiser to stick to documented behavior for 1.5 and just fix
what bugs we can for now. I'm more eager to see a 1.5 release than to
have improved macro design. That can come later and perhaps be more
thorough then?
Regardless of when it is done, I've no idea if your proposed solution
will work, nor have i time right now to dig into the matter more (no
surprise there, i'm sure). If you think it will only fix bugs and add
some new way(s) to use velocimacros without breaking the ways they are
currently used, then i say go for it! That would be very cool.
Your proposed calling page scope sounds quite good, but i don't
think it would be wise to have this as the default for 1.5. We should
stick to the current default for now.
On 1/2/06, Will Glass-Husain [EMAIL PROTECTED] wrote:
I posted a little note about the JIRA issues on macros on the wiki
http://wiki.apache.org/jakarta-velocity/MacroIssues
Once I dug into these issues, I realized the scope of macros seems
rather
odd. Specifically, various users have complained that you can't stick
macros in a file called by #parse (I've run into this myself). This is
documented but still rather unintuititive. The recommended action is to
put such macros in a library, but that may not be feasible with a large
heterogenous library of templates. (or a case where template writers do
not have control of the environment).
What I realized is that this is fundamentally due to a design issue
rather
than a bug. Would appreciate any comments on this interpretation and my
proposed approach to solve this.
Thanks,
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED
Re: request for comments on Macro issues
+1 on the 1.5 macro release approach. I would also love to see the macro with nested content (I think we are talking about the same thing) brought in into a Velocity 1.6 release. In FM they are referred to as the nested directive file:///c:/java/freemarker-2.3.4/docs/docs/ref_directive_macro.html regards Malcolm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
request for comments on Macro issues
I posted a little note about the JIRA issues on macros on the wiki http://wiki.apache.org/jakarta-velocity/MacroIssues Once I dug into these issues, I realized the scope of macros seems rather odd. Specifically, various users have complained that you can't stick macros in a file called by #parse (I've run into this myself). This is documented but still rather unintuititive. The recommended action is to put such macros in a library, but that may not be feasible with a large heterogenous library of templates. (or a case where template writers do not have control of the environment). What I realized is that this is fundamentally due to a design issue rather than a bug. Would appreciate any comments on this interpretation and my proposed approach to solve this. Thanks, WILL
