Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 71242 invoked from network); 13 Jul 2008 14:04:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Jul 2008 14:04:03 -0000 Received: (qmail 6794 invoked by uid 500); 13 Jul 2008 14:04:03 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 6703 invoked by uid 500); 13 Jul 2008 14:04:02 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 6692 invoked by uid 99); 13 Jul 2008 14:04:02 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 13 Jul 2008 07:04:02 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [88.198.46.98] (HELO indoqa.com) (88.198.46.98) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 13 Jul 2008 14:03:08 +0000 Received: from [192.168.1.2] (static-92-61-50-208.htb.wnt-isp.net [92.61.50.208]) by indoqa.com (Postfix) with ESMTP id 68F2825565E for ; Sun, 13 Jul 2008 16:03:30 +0200 (CEST) Message-ID: <487A0AED.8040903@apache.org> Date: Sun, 13 Jul 2008 16:02:21 +0200 From: =?ISO-8859-1?Q?Reinhard_P=F6tz?= User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Proposal - JS Reader References: <487831E8.7060805@tt.com.au> In-Reply-To: <487831E8.7060805@tt.com.au> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Kamal wrote: > Hi, > It occured to me that Cocoon could probably benefit from a Javascript > Reader. This JS Reader would do what a normal resource reader would, > unless the user specifies a compression-method parameter. If the > compression method is supported, then the JS will be compressed. Right > now, I think we can only use JSMin[1] or Package[4], as Dojo > ShrinkSafe[2] and YUI compressor [3] rely on custom version of Rhino. > Packer [4] is written in plain old javascript. JSMin and Packer are open > source, but it is not distributed on any Maven repositories that I can > see, so we would need to include them in source. Have you had a look at http://alchim.sourceforge.net/yuicompressor-maven-plugin/overview.html? This plugin could be used as part of the build process. Then you could use the uncompressed Javascript files for development and then when the module is packaged, the Javascript and CSS files could be compressed. And, AFAICS, this plugin uses standard Rhino (1.6R7). See http://repo1.maven.org/maven2/net/sf/alchim/yuicompressor-maven-plugin/0.7.1/yuicompressor-maven-plugin-0.7.1.pom > This would be useful for the (very large) JS dependencies in CForms > (though, it could be argued that we should be bundling the already > compressed version of Dojo and the other Cocoon JS files). > > I, personally, would find something like this really useful as we have > lots of code that we like to keep uncompressed for development, but > compress at runtime. > > What does everyone think? I don't mind coding this up (using just JSMin). I'm not sure if it is really good idea to compress Javascript files at runtime. If you write the plugin, it would also be possible to reuse the yuicompressor-maven-plugin but not as Maven plugin but as a normal dependency. By doing it this way you wouldn't have to pull in any third-party code into our code base. > Apologies if something like this already exists. Not that I know of. You are welcome! -- Reinhard P�tz Managing Director, {Indoqa} GmbH http://www.indoqa.com/en/people/reinhard.poetz/ Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinhard@apache.org ________________________________________________________________________