Ted and I disagree on this - I don't believe the intention of that policy is to make headers for source files optional. If you read the whole policy document rather than focusing on a single word it seems pretty clear to me that they are required. For example in the FAQ it states the following about why source file headers are required:
Why is a licensing header necessary? License headers allow someone examining the file to know the terms for the work, even when it is distributed without the rest of the distribution. Without a licensing notice, it must be assumed that the author has reserved all rights, including the right to copy, modify, and redistribute. Niall On 2/1/07, Ted Husted <[EMAIL PROTECTED]> wrote:
All release *must* include the license.txt ... and ... all source files *should* include the header. So, assuming there's a difference between "must" and "should", I would say that we only need to correct it in future releases. * http://apache.org/legal/src-headers.html The rationale for "should" is to cover the case where the source file becomes detached from the distribution. And, in this case, we're only talking about an interface. From the discussion, I'm thinking 2.0.4 is only going to be beta anyway, so we should just fix it for 2.0.5, and move on. -Ted. On 2/1/07, David H. DeWolf <[EMAIL PROTECTED]> wrote: > One thing I did notice when looking through the api quickly is that > a lot of the api doesn't have license headers. We should probably fix > that ASAP. > > https://issues.apache.org/struts/browse/WW-1698 > > Does this mean we should stop the current release that's about to go out? > > David > > Rene Gielen wrote: > > Working on the ProxyPrincipal problem, I discovered that we have two > > different ServletRequestAware interfaces: > > - org.apache.struts2.servlet.ServletRequestAware in api > > - org.apache.struts2.interceptor.ServletRequestAware in core > > > > I doubt this is by intention. ServletConfigInterceptor uses the second > > variant, which is IMO bad choice and makes it difficult to remove it in > > favor for the api variant, as it will most likely break many users code. > > On the other hand, since we are not in production yet, we should work on > > clean interfaces and risk some minor/easy to fix code breaks for users. > > > > I'm +1 for dropping the core variant. > > > > - Rene > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
