Is there a reason for using a repacked version of guava #253

Activity

1. aozarov commented on May 24, 2016

   

   aozarov

   on May 24, 2016

   ContributorAuthor

   More actions

   Also, I would expect that even though the runtime may depend on guava (or any other library) the application would be able to use their own independent version as they run in a separate/clean class-loader? /cc @gregw
2. gregw commented on May 25, 2016

   

   gregw

   on May 25, 2016

   Contributor

   More actions

   By default, any extra classes put on the jetty server class path are exposed to the webapplication. But it is an easy thing to configure in jetty and we have the concepts of:

   • server-classes: packages and/or classes that are used to implement the server and are hidden from the webapp, so they cannot be loaded by the application.
   • system-classes: packages and/or classes that are on the server classpath, are exposed to the webapplication, but cannot be replaced by the web application. eg java.lang.* is a system class pattern. Some deployments will make things like CDI system classes, others allow it to be an application component.
   • parent-loader-priority: The servlet spec breaks the java classloader contract in that it allows the application classloader to be used before trying the parent classloader (modulo in jetty the system/server classes above). We are able to turn that off if need be and run a strict java compliant classloader hierarchy if needed.

   So I very much prefer to use all dependencies directly and not to rebundle and/or rename them.

   We probably need to do a bit of work to improve the configuration of server-classes so that such classes are hidden (either at their normal names or even any renaming we do).
3. aozarov

   added this to the Beta milestone on Jun 2, 2016
4. gregw commented on Jun 2, 2016

   

   gregw

   on Jun 2, 2016

   Contributor

   More actions

   So the repackaging is already done in the appengine-api-1.0-sdk-1.9.38.jar that we consume from maven repository:

   com/google/appengine/api/
   com/google/appengine/repackaged/com/fasterxml/jackson/
   com/google/appengine/repackaged/com/google/api/client/
   com/google/appengine/repackaged/com/google/api/client/util/store/
   com/google/appengine/repackaged/com/google/appengine/api/search/
   com/google/appengine/repackaged/com/google/common/
   com/google/appengine/repackaged/com/google/datastore/
   com/google/appengine/repackaged/com/google/gson/
   com/google/appengine/repackaged/com/google/io/
   com/google/appengine/repackaged/com/google/net/
   com/google/appengine/repackaged/com/google/protobuf/
   com/google/appengine/repackaged/com/google/protos
   com/google/appengine/repackaged/com/google/rpc/
   com/google/appengine/repackaged/com/google/storage/
   com/google/appengine/repackaged/com/google/type/
   com/google/appengine/repackaged/org/antlr/
   com/google/appengine/repackaged/org/apache/commons/codec/
   com/google/appengine/repackaged/org/codehaus/jackson/
   com/google/appengine/repackaged/org/joda/time/
   com/google/appengine/spi/
   com/google/appengine/tools/
   com/google/apphosting/api/
   com/google/apphosting/base/
   com/google/apphosting/client/datastoreservice/
   com/google/apphosting/client/searchservice/
   com/google/apphosting/client/serviceapp/
   com/google/apphosting/datastore/
   com/google/apphosting/utils/remoteapi/
   com/google/apphosting/utils/servlet/
   com/google/cloud/sql/jdbc/
   com/google/cloudsearch/
   com/google/protos/cloud/sql/
   com/google/storage/onestore/
   javax/activation/
   javax/cache/
   javax/mail/
   javax/mail/event/
   javax/mail/internet/
   javax/mail/search/
   javax/mail/util/
   org/apache/geronimo/mail/
   

   Note that it appears very inconsistent with what is or is not repackaged within that jar as some com.google packages are just bundled and not repackaged.

   However, I'm guessing there is not much that we can do about this, unless there is a version of that artefact available in maven that does not bundle/repackage its dependencies? I've had a quick look and could not find one.

   Long term it would be best to avoid bundling dependencies and impls within an API jar

   Mid term it would be good to ask for a pur api jar artefact without bundled dependencies, so we could at least pull in and manage dependencies ourselves.

   Short term we can probably not do much to avoid the repackaging, unless we are prepared to strip the jar and rewrite classes back to using the unrepackaged versions. So I will put this on hold for now and work on #259 to at least hide the dependencies from the webapp