Javascript merge/compressing seems to not behave well in all cases and we got a couple of comments from customers and users: https://issues.jboss.org/browse/GTNPORTAL-1182 What's the status on this ? I remember that we looked into other JS compressors but what was the decision on this ? Thomas _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

On 03/24/2011 10:07 AM, Julien Viet wrote: there is one compressor implementation from Google that is done, but I wanted to check before that adding a dependency to Google Guava won't hurt in trunk. if it's ok for you, this can be commited I think. I don't know if the compressor is better though. We should give it a try, Dojo doesn't seem to be working at the moment because of that issue. On Thu, Mar 24, 2011 at 10:04 AM, Thomas Heute <theute(a)redhat.com&gt; wrote: > > Javascript merge/compressing seems to not behave well in all cases and > we got a couple of comments from customers and users: > > https://issues.jboss.org/browse/GTNPORTAL-1182 > > What's the status on this ? I remember that we looked into other JS > compressors but what was the decision on this ? > > > Thomas > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev >

I replaced in our Shindig for Google Collection by Google Guava (GTNPORTAL-1865) and the build seems to work and the unit test pass. So the next step would be to make a release of Shindig and replace the current Google Collection dependency by the Google Guava one.

After that the usage of the other compressor should be possible. On Mar 24, 2011, at 10:29 AM, Julien Viet wrote: > I think there is more to study because we are using currently google collections and google guava redefines a set of classes from google collections (com.google.common.base, com.google.common.collect, com.google.common.annotations). Some of those packages contains new classes in Google Guava. > > It implies that we should get rid of google collections and replace it by guava at runtime. It means that dependencies relying on google collection (like shindig) should be tested to ensure that the usage of Guava works fine before. > > It also implies that google guava should be compatible with google collection, I'm sure it is, but I cannot assess it. > > Perhaps we have also other dependencies that are using google collections but I'm not aware of them (I haven't searched though). > > Could you give a try first at replacing the collection dependency by the guava dependency and see if it's ok ? > > On Thu, Mar 24, 2011 at 10:23 AM, Thomas Heute <theute(a)redhat.com&gt; wrote: > On 03/24/2011 10:07 AM, Julien Viet wrote: >> there is one compressor implementation from Google that is done, but I wanted to check before that adding a dependency to Google Guava won't hurt in trunk. >> >> if it's ok for you, this can be commited I think. >> >> I don't know if the compressor is better though. > > We should give it a try, Dojo doesn't seem to be working at the moment because of that issue. > > > > >> >> On Thu, Mar 24, 2011 at 10:04 AM, Thomas Heute <theute(a)redhat.com&gt; wrote: >> >> Javascript merge/compressing seems to not behave well in all cases and >> we got a couple of comments from customers and users: >> >> https://issues.jboss.org/browse/GTNPORTAL-1182 >> >> What's the status on this ? I remember that we looked into other JS >> compressors but what was the decision on this ? >> >> >> Thomas >> _______________________________________________ >> gatein-dev mailing list >> gatein-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/gatein-dev >> > > _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev