Am 11.09.13 07:54, schrieb Lukasz Lenart:
2013/9/11 David Black dbl...@atlassian.com:
On 9 September 2013 20:52, Christian Grobmeier grobme...@gmail.com wrote:
From a security standpoint we may have the man power to improve things.
For example, if we manage to disable static method calls
Yes, but we can do it via custom SecurityManager - as I understand
OGNL uses SM internally quite often.
2013/9/11 Christian Grobmeier grobme...@gmail.com:
Am 11.09.13 07:54, schrieb Lukasz Lenart:
2013/9/11 David Black dbl...@atlassian.com:
On 9 September 2013 20:52, Christian Grobmeier
I think we can go live with the new website even now - it looks much
better the old one and the rest can be improved in meantime.
2013/9/10 Christian Grobmeier grobme...@gmail.com:
Am 10.09.13 18:11, schrieb Rene Gielen:
If I'd use [Publish Site] now in the Bookmarklet, the site gets - well -
2013/9/10 Christian Grobmeier grobme...@gmail.com:
Hi all,
i am currently documenting a way people can contribute using github.
Basically its all pretty easy with one exception: people cannot send us
pull requests
when they work with the official Struts mirror:
Hi,
I'd like to start discussion about the migration process - there are
few things we must clarify, at least:
- Git structure
- development flow
I think we should have just one repo: git.apache.org/struts.git and
diverse versions internally via branches - so the current S2 source
become the
Hi,
its easy to mess up the svn repos with git - prove below :-)
I forked from the official struts-mirror and added our svn as git svn repos.
The I tried to merge the strutsathon outcome (angularjs) with my repo.
Somewhere in between Johannes added the files manually to SVN.
I fetched and tried
See https://builds.apache.org/job/Struts2-JDK6/797/changes
Changes:
[grobmeier] Add archetype for Struts2 with AngularJS
--
[...truncated 9597 lines...]
[JENKINS] Archiving
https://builds.apache.org/job/Struts2-JDK6/ws/struts2/plugins/embeddedjsp/pom.xml
I use gitflow in my day job and its a great workflow. +1
On Wednesday, September 11, 2013, Lukasz Lenart wrote:
Hi,
I'd like to start discussion about the migration process - there are
few things we must clarify, at least:
- Git structure
- development flow
I think we should have just
See https://builds.apache.org/job/Struts2-JDK6/798/changes
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Am 11.09.13 11:24, schrieb Lukasz Lenart:
Hi,
I'd like to start discussion about the migration process - there are
few things we must clarify, at least:
- Git structure
- development flow
I think we should have just one repo: git.apache.org/struts.git and
diverse versions internally via
Use tags for all released versions, rather than keeping branches for them.
As for Struts 2.5 or 3.0, I'd probably use feature branches for those.
On Wed, Sep 11, 2013 at 10:19 AM, Christian Grobmeier
grobme...@gmail.comwrote:
Am 11.09.13 11:24, schrieb Lukasz Lenart:
Hi,
I'd like to
So as not to pollute the JIRAs too much with speculation or suggestions
that haven't been thought out, I'd like to have a discussion about the
required attribute here on the list.
I propose that we revert the changes made in WW-3908, namely -- turn
requiredLabel back into required. Then, to
I already updated to requiredLabel, so I vote we stick with that. :)
Besides, requiredLabel actually makes more sense, since that's all it does.
You could invert the logic you proposed so that if a required attribute is
detected with a value of anything but false, you consider that to trigger
See https://builds.apache.org/job/Struts2-JDK6/799/changes
Changes:
[jogep] Revert: WW-4197 Update Archetypes READMEs
[jogep] WW-4197 Update Archetypes READMEs
--
[...truncated 7516 lines...]
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0
Sep 11, 2013
Okay thank you for the clarification. I had changed my copy of
themes/simple/text.ftl to add the html5 attribute in the case when
required=true was set. This continues to work fine for me when I set
requiredLabel=true -- so in my case it does have an additional
(beneficial) side effect, in that
I see -- I was under the mistaken impression that requiredLabel before
2.3.12 defined -- at the field level -- which character would be used to
indicate that a field is required. Similar to how labelSeparator works.
I see now that the character used is hard-coded to an asterisk, and that
Nope, it's just the asterisk. Backend validation is handled in the action's
validate method or validation XML.
On Wednesday, September 11, 2013, struts wrote:
I see -- I was under the mistaken impression that requiredLabel before
2.3.12 defined -- at the field level -- which character would be
So as not to pollute the JIRAs too much with speculation or suggestions
that haven't been thought out, I'd like to have a discussion about the
required attribute here on the list.
I propose that we revert the changes made in WW-3908, namely -- turn
requiredLabel back into required. Then, to
18 matches
Mail list logo
