On 8/7/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 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 <[EMAIL PROTECTED]> wrote: > > On 8/7/07, Don Brown <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
