Have we codified this somewhere? I didn't see a commit go by, but then I'm
still catching up.
--
Martin Cooper
On 8/4/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
>
> Discovering that there is a way to avoid having to wait 24hrs for the
> mirrors to sync for security releases is a great find -
Don, the PITA truth is the only reason why I use Resolved up to a release.
:-)
On 8/7/07, Don Brown <[EMAIL PROTECTED]> wrote:
>
> My 2c is I don't see any practical value in resolved/closed. They are
> functionally the same thing, only closed is a PITA because to change
> it, you have to reopen
My 2c is I don't see any practical value in resolved/closed. They are
functionally the same thing, only closed is a PITA because to change
it, you have to reopen it. I know many orgs have workflows where the
two states mean very different things, but for Struts, I think it
would be overkill.
Sti
Ok, here is the wierdness - yes, you can override interceptor stacks,
kinda, only it doesn't work how you might expect. If you define an
override in a subpackage, it not only overrides it for that subpackage
(and its children), but overrides it in the parent as well. This is
kinda a pain in Confl
I have been doing the same: resolving when finishing the issue and then
closing once the release is finished.
On 8/7/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
>
> On 8/7/07, Antonio Petrelli <[EMAIL PROTECTED]> wrote:
> > 2007/8/7, James Mitchell <[EMAIL PROTECTED]>:
> > >
> > > That makes se
Ok, not really ;) But this is kinda weird.
The app that gets generated from the starter archetype makes a bad
assumption about the date format that is displayed by default. When
this date is submitted, it gets converted using a date format of /
MM/dd, but was displayed initially as M/d
Please ask this question to the Struts Users Mailing List:
http://struts.apache.org/mail.html
Antonio
2007/8/7, Suresh MKVS <[EMAIL PROTECTED]>:
> Hi All,
> When i am submitting a page which holds a list of objects, this list is not
> getting populated in form object.
> In form object i am holdin
On 8/7/07, Antonio Petrelli <[EMAIL PROTECTED]> wrote:
> 2007/8/7, James Mitchell <[EMAIL PROTECTED]>:
> >
> > That makes sense to me. I don't remember what the decision was on
> > that. I think this has more to do with making the release managers
> > life easier than policy per se.
> >
> > I can
Hi All,
When i am submitting a page which holds a list of objects, this list is not
getting populated in form object.
In form object i am holding data as an arraylist of objects and I
am populating a series of rows in JSP using struts nested:iterate tag over
the array list. But when i am submitttin
2007/8/7, James Mitchell <[EMAIL PROTECTED]>:
>
> That makes sense to me. I don't remember what the decision was on
> that. I think this has more to do with making the release managers
> life easier than policy per se.
>
> I can reopen and resolve if needed.
It wasn't an "accusation" for your p
I might have, if it's still hosted at opensymphony? If implemented,
what do you feel would be the best way to do it? Override by default
if there's an interceptor with the same name in a sub-package, or add
an attribute to the xml configuration syntax (which I assume would
require a new schema/DTD)
That makes sense to me. I don't remember what the decision was on
that. I think this has more to do with making the release managers
life easier than policy per se.
I can reopen and resolve if needed.
--
James Mitchell
On Aug 7, 2007, at 10:03 AM, Antonio Petrelli wrote:
Hi all!
Just
In the immortal words of Homer ... Doh!!
--
James Mitchell
On Aug 7, 2007, at 10:02 AM, Antonio Petrelli (JIRA) wrote:
[ https://issues.apache.org/struts/browse/WW-2060?
page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel#action_41757 ]
Antonio Petrelli commented
Having the ability to override makes sense to me. I haven't looked into how
complicated this would be to implement though. It will probably have to occur at
the XWork level. Do you have committer access there?
James
On Tue Aug 7 10:07 , 'Nils-Helge Garli' <[EMAIL PROTECTED]> sent:
>Hm...that w
Hm...that was not the answer I wanted ;) That's unecessary duplication
of xml, and it requires manual synchronization of the interceptor
stacks... It might be that the portlet plugin is the only plugin with
this need, but to me it seems like a good feature to be able to
override interceptors, maybe
Hi all!
Just a (maybe stupid) question: what is the policy about
resolving/closing issues?
At Tiles, we resolve issues when we finish committing, and close them
once a vote has been positive for a release.
Thoughts?
Antonio
-
To
Well, with ~1,500 emails coming and going through my mail client per
week (and that's *after* the spam filter), it would be a miracle if I
had actually saved something from those discussions. Problem is that
some of those lists are not public, so we'd be out of luck if it were
one of those
Ok, since Nifty Corners is not used we should create an issue to remove it.
Moreover, this issue should be reopened, since we need to add domTT.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL P
2007/8/7, James Mitchell <[EMAIL PROTECTED]>:
>
> To all:
>
> I am very certain that this has been discussed at length (beating a
> dead horse) on multiple occasions on community@, legal@, user and dev
> @ commons, and probably others as well.
>
> Do we really have to go over all of this again?
On 8/7/07, Antonio Petrelli <[EMAIL PROTECTED]> wrote:
> I agree with you, Ted: I think that the license headers are not useful at
> all. But I don't think this is the place for such a discussion, since I
> think that it should be decided at a "foundation-level". I think that, if we
> remove the li
To all:
I am very certain that this has been discussed at length (beating a
dead horse) on multiple occasions on community@, legal@, user and dev
@ commons, and probably others as well.
Do we really have to go over all of this again?
--
James Mitchell
On Aug 7, 2007, at 8:40 AM, Antoni
On 8/7/07, Antonio Petrelli <[EMAIL PROTECTED]> wrote:
> In other words, it reminds the user that he is free to use it :-)
Yes, but the header doesn't grant us or the user any additional
rights. But, if the user utilizes the example, it does oblige the user
to embed the header into his or her own
2007/8/7, Ted Husted <[EMAIL PROTECTED]>:
>
> On 8/6/07, Don Brown <[EMAIL PROTECTED]> wrote:
> > *sigh* Sometimes the ASF overhead can be such a pain... The headers
> > are fine when you use an IDE, but when you use vi, it means scrolling
> > down the 50 or whatever lines every time, which is so
2007/8/7, Ted Husted <[EMAIL PROTECTED]>:
> All of the creative works in the distribution are covered by the
> license in the root directory.
>
> We over perform in the case of source code files in case the file is
> separated from the distribution. But I don't see why that concern
> should apply t
On 8/6/07, Don Brown <[EMAIL PROTECTED]> wrote:
> *sigh* Sometimes the ASF overhead can be such a pain... The headers
> are fine when you use an IDE, but when you use vi, it means scrolling
> down the 50 or whatever lines every time, which is so annoying.
I agree with Don. Injecting all the licen
All of the creative works in the distribution are covered by the
license in the root directory.
We over perform in the case of source code files in case the file is
separated from the distribution. But I don't see why that concern
should apply to example files. If our charter were to create CSS an
2007/8/7, Ted Husted <[EMAIL PROTECTED]>:
>
> They did. We had that discussion already, and we definitely don't need
> the license headers in script files that are interpreted at runtime.
But I think that script files are creative works, so are CSS files and
simple (not-generated) HTML files. It
They did. We had that discussion already, and we definitely don't need
the license headers in script files that are interpreted at runtime.
On 8/6/07, Don Brown <[EMAIL PROTECTED]> wrote:
> On 8/7/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> > Yes we ship both in the validator jar - perhaps sh
Yes, I'd say you will need to redefine the stacks users of the portlet
plugin can use.
Don
On 8/7/07, Nils-Helge Garli <[EMAIL PROTECTED]> wrote:
> Hi!
>
> In the portlet plugin, I need to customize the workflow interceptors.
> So I have extended them, and added them to the struts-plugin file wit
Hi!
In the portlet plugin, I need to customize the workflow interceptors.
So I have extended them, and added them to the struts-plugin file with
the same names they have in struts-default. Unfortunately, this has
not the desired effect. The interceptors from the struts-default
package are still th
2007/8/7, Niall Pemberton <[EMAIL PROTECTED]>:
>
> "What files in an Apache release do not require a license header?
> A file without any degree of creativity in either its literal elements
> or its structure is not protected by copyright law; therefore, such a
> file does not require a license hea
31 matches
Mail list logo