Application size due to Internationalization

[Rana]

Hi,

Does anyone have a solution to the huge size of application, when we apply to it internationalization using the static method? We are supposed to support 66 languages. The application takes a long time during compilation and the size of the application is huge, we cannot upload it to google app engine.

Many thanks

Rana

[Joseph Lust]

Rana,

I've read that internal Google apps must build to 240 permutations for the supported browsers and languages. To support this they:

• Conduct draft compilations only using their desired dev permutation
• Do complete compiles for releases/CI/test on a server farm

There are instructions out there that do this sort of thing:

• gwt-distcc 
• GWT Distributed Build documentation

Of course you probably don't need to do a complete build that often (CI machine, pre-release), so collapsing the permutations or just doing a single permutation draft compile might suffice.

Sincerely,

Joseph

[Rana]

Hi Joseph,

Thanks a lot for the information. I will go through both links, and see if it helps in solving the problem.

Many thanks again

Rana

[Richard]

Rana - are you combining class files into a jar? That'll help reduce the file count for GAE, if that's an issue for you.

Wishlist:

upload the code/basic .classes, have GWT compilation happen on Google infrastructure.

[Tony Rah]

I use a special "DevModule.gwt.xml" module during development that only compiles the permutations I am interested in. This way I can control the user agent, locale, and other GWT based switches without compromising the production builds. Below is a rough overview of this approach:

Create a new module file XXXDev.gwt.xml where XXX is the name of your applications top level module used for production builds. You will inherit your apps module from here. Set your various property overrides (e.g. "<set-property name='user.agent' value='safari'/>" and "<set-property name='locale' value='en'/>").

I personally use Ant to build my project and created a separate dev target that builds the dev module instead of the production module.

Obviously, there are countless ways to orchestrate this but the basic idea is that you only compile the permutations you care about while doing development. You let an automated build/test system build the really big production builds and perform all of the automated tests.

Hope that helps...

[Rana]

Dear Tony,

Thanks for your suggestions. Yes, I did this. But the main issue I am unable to solve is the size of the code. It is too big to deploy on app.spot.

Many thanks

Rana

[Rana]

Hi,

Many thanks, I will see if we are deploying the  class files in the jar.

Thanks a lot for the idea

Rana

[Thomas Broyer]

On Wednesday, July 25, 2012 11:34:13 AM UTC+2, Rana wrote:

Dear Tony,

Thanks for your suggestions. Yes, I did this. But the main issue I am unable to solve is the size of the code. It is too big to deploy on app.spot.

Are you also trying to deploy some WEB-INF/deploy folder?

If you don't know what it's for, then you can safely keep it out (you can pass the -deploy argument to the GWT Compiler to output those files in a different folder, outside your WAR)

[Rana]

Hello Tony,

No, we don't seem to be putting things we don't need from WEB-INF/deploy, but we are supporting I think 66 languages. And they are making the application very big in size. That is why. Also, originally the application is big, we are doing mathematical drawing and calculations... that adds to the size as well, I think.

Best wishes

Rana

[Rana]

:) :) Sorry, I got confused with the posting area:

No, we don't seem to be putting things we don't need from WEB-INF/deploy, but we are supporting I think 66 languages. And they are making the application very big in size. That is why. Also, originally the application is big, we are doing mathematical drawing and calculations... that adds to the size as well, I think.

Best wishes

Rana

On Wednesday, July 25, 2012 11:43:37 AM UTC+2, Thomas Broyer wrote:

[Shawn Brown]

> Thanks for your suggestions. Yes, I did this. But the main issue I am unable
> to solve is the size of the code. It is too big to deploy on app.spot.

I don't think that is the case.

Prior to AE1.7, I was over the limit due to permutations as well.
AE1.6 was 150MB/app right, and 1.7 is 1gb (total for all apps)

It wasn't that difficult to serve the permutation files out of the blobstore.

The overview is:

1) ant task to move permutation stuff into /serve_from_blobstore folder
2) class to upload /serve_from_blobstore permutations (including .rpc
files, and no-cache stuff) using BlobstoreService
3) servlet to handle the upload - stores blob and map (in datastore
entity) the req url and blob key
4) filter to serve blobs. If request matches /myAppName, serve blob
by looking up blob key from request url using the enitity map created
in 3 [my *.gwt.xml file was using <module rename-to='myAppName'>]
5) task to delete blobs for particular app version

Probably the trickiest things were catching the failed uploads (it
sporadically happened) and making sure they were retried until
successful and ensuring a versions blobs were all deleted.

I'm under 500 mb now so I just have two versions (and stay under the
1gb limit) and don't serve from the blobstore but have the
infrastructure in place should the need arise.

There is no way your app minus permutations is over 1gb I think. I
don't see the size of language permutations as a barrier to deploying
on AppEngine.