commons-el, commons-logging, jasper-compiler, jasper-runtime, jstl, standard, ant, ant- launcher
rien que ça !
Une petite recherche me fait découvrir une classe de commons-el dont la taille binaire est différente entre les deux JAR. Google aurait-il eu besoin d'adapter ces classes pour son runtime ? Après décompilation : aucune différence !?
Première hypothèse : Google a recompilé lui-même ces librairies. Pourquoi pas, mais ça parrait un drôle d'idée.
Seconde hypothèse : Google a eu besoin de modifier ces classes, non pas dans leur code source mais dans leur structure bytecode. Après tout, le runtime AppEngine a de grande chance de ne pas utiliser une JRE SUN classique, mais plutôt un JVM Dalvik déjà maîtrisé par Google puisqu'elle est au coeur d'Androïd - mais ce n'est que pure spéculation !
Troisème hypothèse : Goole a pris des jars qui trainaient sur un coin de table (ou de disque dur), de toute façon ils n'ont rien compris au problème des dépendances Maven et s'en tappent : ils ne l'utilisent pas (même problème avec GWT-dev). Hypothèse la moins avantageuse car dans ce cas on est pas près de savoir si on peut utiliser les JAR "standard" du dépôt Maven sans risque.
Quatrième hypothèse : Google n'aime tellement pas Maven (il n'y a qu'à voir combien de ses projets majeurs l'utilisent) qu'ils ont décidé de tripatouiller les JARs juste pour nous emmbêter. Un complot mondial je vous dis !
Dernière hypothèse : Jason (Van Zyl, Mr "j'ai créé Maven") a voulu s'assurer l'exlusivité d'un plugin GAE, augmentant ainsi sa mainmise sur l'écosystème Maven. Il a donc collaboré avec Google (dont les bureaux sont voisins) pour s'assurer que ceux qui ne sont pas dans le secret ne s'en sortiraient pas.
Dans tous les cas, il va falloir patienter encore pour avoir une première SNAPSHOT d'un plugin GAE ... ou alors tenter le coup avec les artefacts "officiels" Maven pour voir.
