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> 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> 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
>