Re: Duplicate action ids - how to handle?
On 8/27/06, Paul Benedict <[EMAIL PROTECTED]> wrote: I will add this to the comments of STR-2864 when finished. Let's not duplicate labor. JIRA posts to the issue lists, and people who care about such things should be following the issue list too. Once we have an issue open, it's much better to keep the thread in one place, on the issue ticket. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch all or individual commits?
On 8/27/06, Paul Benedict <[EMAIL PROTECTED]> wrote: Do you have an example commit message? If there's a special format, please let me know. The thing to keep in mind is that alot of the team communication happens through the commits and the commit logs. (And *all* of the team communication goes over the dev, commits, or issues lists.) People are watching the commits, and they are trying to follow what changes are being made. The reason we group the commits around issues is that it's easier for other people to follow the changes, both now and years from now. Put into the commit message anything that will make it easier for people to follow what is happening. (Where people include yourself six months or six years from now.) Remember that the commit messages not only go out by email, and stored in the repository, but they are available online as well. * http://svn.apache.org/viewvc/struts/struts1/trunk/core/src/main/java/org/apache/struts/config/ActionConfig.java?view=log When reports come in on code that we haven't worked on, most of us will review the commit messages, to see if the issue has been addressed before. Short one-line messages are fine, if they provide all the information that an observer would need to understand the commit. I've also seen two-thousand word messages for commits that included a lot of functionality. PS: When this is all done, I should probably collect all these tips and add them to our home page. Unless I missed all these guidelines (it is quite possible!), it's worth documenting. We conduct all of the development work and team communications on the public lists, so to a degree, we expect people to learn to be committers by watching other committers. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Duplicate action ids - how to handle?
On 8/27/06, Ted Husted <[EMAIL PROTECTED]> wrote: Let's not duplicate labor. JIRA posts to the issue lists, and people who care about such things should be following the issue list too. Once we have an issue open, it's much better to keep the thread in one place, on the issue ticket. Okay, but this was a step in the right direction. The question was originally posted [1] in a thread that began as a reply to one of JIRA's automated messages. At least here, it's a separate thread with a sensible subject line. [1] http://www.nabble.com/-Fwd%3A--jira--Updated%3A-%28STR-2864%29-Add-actionId-attribute-to-action-mapping--t2168058.html#a6004227 -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Maven build changes
On 7/19/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote:
Yup, the xwork profile is very nice for when generating the IDEA projects.
Agreed, but ../xwork is not where my xwork lives. :)
Any objection to making this configurable as a property?
If you and Jason can add this to settings.xml:
xwork
../xwork
...
Then we can change the struts2-parent pom to:
xwork
${struts2.xwork.location}
and it should work for everyone.
Thanks,
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
