Re: svn commit: r563238 [1/6] - in /struts/struts2/trunk/apps: ./ blank/ blank/src/main/java/example/ blank/src/main/resources/ blank/src/main/resources/example/ blank/src/main/webapp/ blank/src/main/

2007-08-07 Thread Antonio Petrelli
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 header. If

Override interceptors in struts-default from plugin

2007-08-07 Thread Nils-Helge Garli
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

Re: svn commit: r563238 [1/6] - in /struts/struts2/trunk/apps: ./ blank/ blank/src/main/java/example/ blank/src/main/resources/ blank/src/main/resources/example/ blank/src/main/webapp/ blank/src/main/

2007-08-07 Thread Ted Husted
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 should

Re: svn commit: r563238 [1/6] - in /struts/struts2/trunk/apps: ./ blank/ blank/src/main/java/example/ blank/src/main/resources/ blank/src/main/resources/example/ blank/src/main/webapp/ blank/src/main/

2007-08-07 Thread Antonio Petrelli
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's

Re: svn commit: r563238 [1/6] - in /struts/struts2/trunk/apps: ./ blank/ blank/src/main/java/example/ blank/src/main/resources/ blank/src/main/resources/example/ blank/src/main/webapp/ blank/src/main/

2007-08-07 Thread Ted Husted
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

Licensing OCD (was Re: svn commit: r563238 [1/6])

2007-08-07 Thread Ted Husted
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 licensing

Re: svn commit: r563238 [1/6] - in /struts/struts2/trunk/apps: ./ blank/ blank/src/main/java/example/ blank/src/main/resources/ blank/src/main/resources/example/ blank/src/main/webapp/ blank/src/main/

2007-08-07 Thread Antonio Petrelli
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 to

Re: Licensing OCD (was Re: svn commit: r563238 [1/6])

2007-08-07 Thread Antonio Petrelli
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 annoying.

Re: svn commit: r563238 [1/6] - in /struts/struts2/trunk/apps: ./ blank/ blank/src/main/java/example/ blank/src/main/resources/ blank/src/main/resources/example/ blank/src/main/webapp/ blank/src/main/

2007-08-07 Thread Ted Husted
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

Re: Licensing OCD (was Re: svn commit: r563238 [1/6])

2007-08-07 Thread James Mitchell
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,

Re: Licensing OCD (was Re: svn commit: r563238 [1/6])

2007-08-07 Thread Ted Husted
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 license

Re: Licensing OCD (was Re: svn commit: r563238 [1/6])

2007-08-07 Thread Antonio Petrelli
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? No, if

Re: [jira] Commented: (WW-2060) Add third party license info

2007-08-07 Thread Antonio Petrelli
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

Re: Licensing OCD (was Re: svn commit: r563238 [1/6])

2007-08-07 Thread James Mitchell
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

Resolving/Closing JIRA issues

2007-08-07 Thread Antonio Petrelli
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 -

Re: Override interceptors in struts-default from plugin

2007-08-07 Thread Nils-Helge Garli
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,

Re: Override interceptors in struts-default from plugin

2007-08-07 Thread James Holmes
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 was

Re: [jira] Commented: (WW-2060) Add third party license info

2007-08-07 Thread James Mitchell
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

Re: Override interceptors in struts-default from plugin

2007-08-07 Thread Nils-Helge Garli
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

Re: Resolving/Closing JIRA issues

2007-08-07 Thread Antonio Petrelli
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 particular

Struts list regeneration problem

2007-08-07 Thread Suresh MKVS
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

Re: Resolving/Closing JIRA issues

2007-08-07 Thread Niall Pemberton
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 reopen and

Re: Struts list regeneration problem

2007-08-07 Thread Antonio Petrelli
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 holding

Starter app is jacked

2007-08-07 Thread James Mitchell
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

Re: Resolving/Closing JIRA issues

2007-08-07 Thread Paul Benedict
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 sense to me. I

Re: Override interceptors in struts-default from plugin

2007-08-07 Thread Don Brown
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

Re: Resolving/Closing JIRA issues

2007-08-07 Thread Don Brown
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.

Re: Resolving/Closing JIRA issues

2007-08-07 Thread Paul Benedict
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 it.

Re: Voting Process -- Recap

2007-08-07 Thread Martin Cooper
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 -