v1.6 - Add appengine-remote-api.jar and appengine-tools-api.jar to Exclude about play-gae HOT 11 CLOSED

But what does it do when you don't exclude them? Does it create problems?

from play-gae.

When you don't exclude them you get the 'file too large' exception when
deploying.

On Sat, Dec 3, 2011 at 2:37 AM, Pascal Voitot <
[email protected]

wrote:

But what does it do when you don't exclude them? Does it create problems?

---

Reply to this email directly or view it on GitHub:
#32 (comment)

from play-gae.

but is it because your WAR was really too large (BTW what size?) or is it
an error linked to including those 2 jars?

On Sat, Dec 3, 2011 at 11:43 AM, carchrae <
[email protected]

wrote:

When you don't exclude them you get the 'file too large' exception when
deploying.

On Sat, Dec 3, 2011 at 2:37 AM, Pascal Voitot <
[email protected]

wrote:

But what does it do when you don't exclude them? Does it create problems?

---

Reply to this email directly or view it on GitHub:
#32 (comment)

---

Reply to this email directly or view it on GitHub:
#32 (comment)

from play-gae.

It is not the WAR size, but rather the size of the individual jar files.

I guess you didn't see the error with GAE 1.6 because it looks like they
upped the limit to 32mb from 10mb.

GAE 1.5.3:
-rw-r--r-- 1 tom tom 9684808 2011-08-17 17:42 appengine-remote-api.jar
-rw-r--r-- 1 tom tom 9850239 2011-08-17 17:42 appengine-tools-api.jar

GAE 1.6:
-rw-r--r-- 1 tom tom 10093898 2011-11-29 03:01 appengine-remote-api.jar
-rw-r--r-- 1 tom tom 10282214 2011-11-29 03:01 appengine-tools-api.jar

Not clear this is a real bug, but rather the issue is trying to use the GAE
module with GAE 1.5.x. You are quite right to ask more questions because
it is possible you might want to use these jar files on GAE. I guess they
repackaged things in 1.6 given the new file limit.

But this begs another point in terms of the GAE play module design. Why
include the jar files from a specific GAE distribution instead of having
the module get them from GAE_PATH? (I'm not suggesting you do this unless
it is trivial and robust on different platforms - somehow I doubt it is)

from play-gae.

On Sat, Dec 3, 2011 at 12:10 PM, carchrae <
[email protected]

wrote:

It is not the WAR size, but rather the size of the individual jar files.

I guess you didn't see the error with GAE 1.6 because it looks like they
upped the limit to 32mb from 10mb.

GAE 1.5.3:
-rw-r--r-- 1 tom tom 9684808 2011-08-17 17:42 appengine-remote-api.jar
-rw-r--r-- 1 tom tom 9850239 2011-08-17 17:42 appengine-tools-api.jar

GAE 1.6:
-rw-r--r-- 1 tom tom 10093898 2011-11-29 03:01 appengine-remote-api.jar
-rw-r--r-- 1 tom tom 10282214 2011-11-29 03:01 appengine-tools-api.jar

Not clear this is a real bug, but rather the issue is trying to use the GAE
module with GAE 1.5.x. You are quite right to ask more questions because
it is possible you might want to use these jar files on GAE. I guess they
repackaged things in 1.6 given the new file limit.

But this begs another point in terms of the GAE play module design. Why
include the jar files from a specific GAE distribution instead of having
the module get them from GAE_PATH? (I'm not suggesting you do this unless
it is trivial and robust on different platforms - somehow I doubt it is)

This is a good question... I don't really have the solution basically :D
It's part of reflexion we must have in refactoring this module.
Using GAE_PATH could be better IMO. As you can see, I replaced provided-XXX
files from play-gae-1.4 with real file names and added the excluded JARs in
commands.py. So we can use the real files from GAE SDK from now!

Pascal

---

Reply to this email directly or view it on GitHub:
#32 (comment)

from play-gae.

Yes, your exclude code is great! I think you saw my lamenting post on the
mailing list about how I had to deploy by deleting files from the war. (I
really need to learn more python!)

What about some ant magic that copies the jar files into lib from GAE_PATH?
Could add this to build.xml.

from play-gae.

On Sat, Dec 3, 2011 at 12:32 PM, carchrae <
[email protected]

wrote:

Yes, your exclude code is great! I think you saw my lamenting post on the
mailing list about how I had to deploy by deleting files from the war. (I
really need to learn more python!)

What about some ant magic that copies the jar files into lib from GAE_PATH?
Could add this to build.xml.

I don't think it's at ANT level that we must do that.
Certainly at commands.py level or play conf because you need them when you
create a new project with Play and add GAE module.
Define GAE_PATH somewhere and either use a play command to copy the libs in
your application or even ask play to search the JARs in GAE_PATH but I'm
not sure it's possible.

Pascal

---

Reply to this email directly or view it on GitHub:
#32 (comment)

from play-gae.

Yes, ant is not an ideal way to do this, since people who install the
module won't run ant. It would, however, make it easier to create modules
with the correct jars for GAE 1.5.3, GAE 1.5.4, GAE 1.6.1 and so on.

If it is possible to add arbitrary class path elements to a play project,
then it would be possible for the play project to point to the jars in
GAE_PATH - I don't know if that is possible. That would really be the
ideal I think. I guess copying the JAR into the application is reasonable
too - maybe specificying this using dependencies.yml - but need to match
the GAE version in the dependency file with the one on GAE_PATH.

(wow, we are down the path now. :) )

from play-gae.

On Sat, Dec 3, 2011 at 1:02 PM, carchrae <
[email protected]

wrote:

Yes, ant is not an ideal way to do this, since people who install the
module won't run ant. It would, however, make it easier to create modules
with the correct jars for GAE 1.5.3, GAE 1.5.4, GAE 1.6.1 and so on.

If it is possible to add arbitrary class path elements to a play project,
then it would be possible for the play project to point to the jars in
GAE_PATH - I don't know if that is possible. That would really be the
ideal I think. I guess copying the JAR into the application is reasonable
too - maybe specificying this using dependencies.yml - but need to match
the GAE version in the dependency file with the one on GAE_PATH.

(wow, we are down the path now. :) )

The ideal IMO would be not to generate a new play-gae version for each GAE
SDK. It's not viable or I'll do a bot doing that for me running somewhere :)

---

Reply to this email directly or view it on GitHub:
#32 (comment)

from play-gae.

The ideal IMO would be not to generate a new play-gae version for each GAE

SDK. It's not viable or I'll do a bot doing that for me running somewhere :)

For sure.

I had a look at doing this with
http://www.playframework.org/documentation/1.2.4/dependency#Localrepositories

It seems like it should be possible to add these dependencies properly. If
they are specified as a local repository, it should be possible to
reference each JAR from GAE_PATH in the module's conf/dependency.yml file.

I tried it, but it seems whatever parses the YML file can't find my
environment variable GAE_PATH - or maybe I did it wrong? Perhaps this
needs to be passed in somewhere in the commands.py file?

from play-gae.

On Sat, Dec 3, 2011 at 1:44 PM, carchrae <
[email protected]

wrote:

The ideal IMO would be not to generate a new play-gae version for each
GAE

SDK. It's not viable or I'll do a bot doing that for me running somewhere
:)

For sure.

I had a look at doing this with

http://www.playframework.org/documentation/1.2.4/dependency#Localrepositories

It seems like it should be possible to add these dependencies properly. If
they are specified as a local repository, it should be possible to
reference each JAR from GAE_PATH in the module's conf/dependency.yml file.

I tried it, but it seems whatever parses the YML file can't find my
environment variable GAE_PATH - or maybe I did it wrong? Perhaps this
needs to be passed in somewhere in the commands.py file?

from commands.py, we could copy jars into APP/lib
from PlayGaePlugin, I don't know if we can ask the classloader to load
those JARs or to add dependencies on them...

---

Reply to this email directly or view it on GitHub:
#32 (comment)

from play-gae.