struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@gmail.com>
Subject 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/webapp/WEB-INF/ blank/src/main/webapp/example/ mai
Date Tue, 07 Aug 2007 01:49:11 GMT
On 8/7/07, Don Brown <mrdon@twdata.org> 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 like the compressing idea, but it does make development harder,
> particularly if you use something like Firebug.  Maybe we could have
> two versions of our jar - compressed and uncompressed text.  Or, maybe
> I should write a tool that will process a jar and strip all the
> license headers out of all the text files... ;)

Yes we ship both in the validator jar - perhaps should follow up with
Wicket to see if they found an accomodation. I can't believe that the
ASF can't come up with a one line solution for javascript files -
something along the lines "This is licensed under the AL 2.0 - go see
foo file/url for full license/copyright details" - i.e. "detached
license" - similar to signatures.

Niall

> Don
>
> On 8/7/07, Niall Pemberton <niall.pemberton@gmail.com> wrote:
> > On 8/7/07, Don Brown <mrdon@twdata.org> wrote:
> > > Is it absolutely necessary for that huge license header to go on every
> > > single file?  It is rather annoying to scroll through all this license
> > > text just for a couple-line config file.  I'm also concerned it bloats
> > > the Javascript and CSS unnecessarily.
> >
> > The source file policy [1] doesn't actually mandate a license header
> > on every file - it has the following in the FAQ:
> >
> > "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 in doubt about the extent
> > of the file's creativity, add the license header to the file."
> >
> > I think for config and CSS files you could easily argue these fall
> > under this category - although for config files it doesn't really
> > matter that much from any performance PoV - same goes for anything
> > compiled. The one place that (AFAIK) the ASF hasn't resolved is for
> > interpreted files such as JavaScript - I'm sure this was raised by the
> > Wicket team for their JavaScript during incubation - but I can't
> > remember the outcome. For Commons Validator we got round this by
> > adding the source file header to the JavaScript files - and then
> > produced "compressed" versions using the Dojo/Rhino compressor[2] (now
> > called ShrinkSafe) - which, as well as other things, removes all
> > comments - since as I understand it generated files are not
> > copyrightable (just original source). From memory the compressor
> > reduced all Validators script from 54k to 17k. The good thing is the
> > Dojo/Rhino compressor was recently added to the maven repository - I
> > keep thinking I should write a m2 plugin using it, but haven't got
> > round to it yet (Commons Validator m2 build calls an ant script[3] to
> > do it). Anyway might be something worth considering for S2 anyway?
> >
> > Niall
> >
> > [1] http://www.apache.org/legal/src-headers.html
> > [2] http://dojotoolkit.org/docs/shrinksafe
> > [3] http://svn.apache.org/repos/asf/commons/proper/validator/trunk/build-javascript.xml
> > > Don
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message