GWT-2.8-SNAPSHOT jar questions

[Hristo Stoyanov]

Hi all,

 I have a couple of questions regarding GWT 2.8 SNAPSHOT:

1. Why am I picking up  tons of jetty libraries for doing a simple gwt compilation? I could understand the need for the Jetty jars, if I was running the code server, or including the servlet library, but just for compilation...? Seems like this is coming from the gwt-dev.jar? Here is what my Gradle dependency report looks like:

+--- com.google.gwt:gwt-codeserver:2.8.0-SNAPSHOT

|    \--- com.google.gwt:gwt-dev:2.8.0-SNAPSHOT

|         +--- org.ow2.asm:asm:5.0.3

|         +--- org.ow2.asm:asm-util:5.0.3 (*)

|         +--- org.ow2.asm:asm-commons:5.0.3

|         |    \--- org.ow2.asm:asm-tree:5.0.3 (*)

|         +--- org.eclipse.jetty.websocket:websocket-client:9.2.14.v20151106

|         |    +--- org.eclipse.jetty:jetty-util:9.2.14.v20151106

|         |    +--- org.eclipse.jetty:jetty-io:9.2.14.v20151106

|         |    |    \--- org.eclipse.jetty:jetty-util:9.2.14.v20151106

|         |    \--- org.eclipse.jetty.websocket:websocket-common:9.2.14.v20151106

|         |         +--- org.eclipse.jetty.websocket:websocket-api:9.2.14.v20151106

|         |         +--- org.eclipse.jetty:jetty-util:9.2.14.v20151106

|         |         \--- org.eclipse.jetty:jetty-io:9.2.14.v20151106 (*)

|         +--- org.eclipse.jetty:jetty-webapp:9.2.14.v20151106

|         |    +--- org.eclipse.jetty:jetty-xml:9.2.14.v20151106

|         |    |    \--- org.eclipse.jetty:jetty-util:9.2.14.v20151106

|         |    \--- org.eclipse.jetty:jetty-servlet:9.2.14.v20151106

|         |         \--- org.eclipse.jetty:jetty-security:9.2.14.v20151106

|         |              \--- org.eclipse.jetty:jetty-server:9.2.14.v20151106

|         |                   +--- javax.servlet:javax.servlet-api:3.1.0

|         |                   +--- org.eclipse.jetty:jetty-http:9.2.14.v20151106

|         |                   |    \--- org.eclipse.jetty:jetty-util:9.2.14.v20151106

|         |                   \--- org.eclipse.jetty:jetty-io:9.2.14.v20151106 (*)

|         +--- org.eclipse.jetty:jetty-servlets:9.2.14.v20151106

|         |    +--- org.eclipse.jetty:jetty-continuation:9.2.14.v20151106

|         |    +--- org.eclipse.jetty:jetty-http:9.2.14.v20151106 (*)

|         |    +--- org.eclipse.jetty:jetty-util:9.2.14.v20151106

|         |    \--- org.eclipse.jetty:jetty-io:9.2.14.v20151106 (*)

|         +--- org.eclipse.jetty:jetty-annotations:9.2.14.v20151106

|         |    +--- org.eclipse.jetty:jetty-plus:9.2.14.v20151106

|         |    |    +--- org.eclipse.jetty:jetty-webapp:9.2.14.v20151106 (*)

|         |    |    \--- org.eclipse.jetty:jetty-jndi:9.2.14.v20151106

|         |    |         \--- org.eclipse.jetty:jetty-util:9.2.14.v20151106

|         |    +--- org.eclipse.jetty:jetty-webapp:9.2.14.v20151106 (*)

|         |    +--- javax.annotation:javax.annotation-api:1.2

|         |    +--- org.ow2.asm:asm:5.0.1 -> 5.0.3

|         |    \--- org.ow2.asm:asm-commons:5.0.1 -> 5.0.3 (*)

|         \--- org.eclipse.jetty:apache-jsp:9.2.14.v20151106

|              +--- org.eclipse.jetty:jetty-util:9.2.14.v20151106

|              +--- org.eclipse.jetty:jetty-server:9.2.14.v20151106 (*)

|              +--- org.eclipse.jetty.toolchain:jetty-schemas:3.1.M0

|              +--- javax.servlet:javax.servlet-api:3.1.0

|              +--- org.mortbay.jasper:apache-jsp:8.0.9.M3

|              |    +--- org.eclipse.jetty.toolchain:jetty-schemas:3.1.M0

|              |    \--- org.mortbay.jasper:apache-el:8.0.9.M3

|              \--- org.eclipse.jetty.orbit:org.eclipse.jdt.core:3.8.2.v20130121

+--- com.google.gwt:gwt-dev:2.8.0-SNAPSHOT (*)

+--- javax.validation:validation-api:1.0.0.GA -> 1.1.0.Final (See next question)

2. When is the validation api in GWT 2.8 going to be upgraded to 1.1.0.Final? Other libraries are forcing a dependency upgrade, which results in this mess:

Tracing compile failure path for type 'com.google.gwt.validation.client.impl.ConstraintDescriptorImpl'

      [ERROR] Errors in 'com/google/gwt/validation/client/impl/ConstraintDescriptorImpl.java'

         [ERROR] Line 35: The type ConstraintDescriptorImpl<T> must implement the inherited abstract method ConstraintDescriptor<T>.getMessageTemplate()

         [ERROR] Line 35: The type ConstraintDescriptorImpl<T> must implement the inherited abstract method ConstraintDescriptor<T>.getValidationAppliesTo()

   Tracing compile failure path for type 'com.google.gwt.validation.client.impl.GwtValidatorContext'

      [ERROR] Errors in 'com/google/gwt/validation/client/impl/GwtValidatorContext.java'

         [ERROR] Line 29: The type GwtValidatorContext must implement the inherited abstract method ValidatorContext.parameterNameProvider(ParameterNameProvider)

   Tracing compile failure path for type 'com.google.gwt.validation.client.impl.NodeImpl'

      [ERROR] Errors in 'com/google/gwt/validation/client/impl/NodeImpl.java'

         [ERROR] Line 25: The type NodeImpl must implement the inherited abstract method Path.Node.as(Class<T>)

         [ERROR] Line 25: The type NodeImpl must implement the inherited abstract method Path.Node.getKind()

   Tracing compile failure path for type 'com.google.gwt.validation.client.impl.ConstraintViolationImpl'

      [ERROR] Errors in 'com/google/gwt/validation/client/impl/ConstraintViolationImpl.java'

         [ERROR] Line 31: The type ConstraintViolationImpl<T> must implement the inherited abstract method ConstraintViolation<T>.getExecutableReturnValue()

         [ERROR] Line 31: The type ConstraintViolationImpl<T> must implement the inherited abstract method ConstraintViolation<T>.getExecutableParameters()

         [ERROR] Line 31: The type ConstraintViolationImpl<T> must implement the inherited abstract method ConstraintViolation<T>.unwrap(Class<U>)

   Tracing compile failure path for type 'com.google.gwt.validation.client.impl.ConstraintValidatorContextImpl'

      [ERROR] Errors in 'com/google/gwt/validation/client/impl/ConstraintValidatorContextImpl.java'

         [ERROR] Line 46: The type ConstraintValidatorContextImpl<A,T>.ConstraintViolationBuilderImpl must implement the inherited abstract method ConstraintValidatorContext.ConstraintViolationBuilder.addPropertyNode(String)

         [ERROR] Line 39: The type ConstraintValidatorContextImpl<A,T> must implement the inherited abstract method ConstraintValidatorContext.unwrap(Class<T>)

         [ERROR] Line 112: The type ConstraintValidatorContextImpl<A,T>.NodeBuilderDefinedContextImpl must implement the inherited abstract method ConstraintValidatorContext.ConstraintViolationBuilder.NodeBuilderDefinedContext.addPropertyNode(String)

         [ERROR] Line 79: The type ConstraintValidatorContextImpl<A,T>.NodeBuilderCustomizableContextImpl must implement the inherited abstract method ConstraintValidatorContext.ConstraintViolationBuilder.NodeBuilderCustomizableContext.addBeanNode()

         [ERROR] Line 79: The type ConstraintValidatorContextImpl<A,T>.NodeBuilderCustomizableContextImpl must implement the inherited abstract method ConstraintValidatorContext.ConstraintViolationBuilder.NodeBuilderCustomizableContext.addPropertyNode(String)

         [ERROR] Line 112: The type ConstraintValidatorContextImpl<A,T>.NodeBuilderDefinedContextImpl must implement the inherited abstract method ConstraintValidatorContext.ConstraintViolationBuilder.NodeBuilderDefinedContext.addBeanNode()

         [ERROR] Line 46: The type ConstraintValidatorContextImpl<A,T>.ConstraintViolationBuilderImpl must implement the inherited abstract method ConstraintValidatorContext.ConstraintViolationBuilder.addParameterNode(int)

         [ERROR] Line 46: The type ConstraintValidatorContextImpl<A,T>.ConstraintViolationBuilderImpl must implement the inherited abstract method ConstraintValidatorContext.ConstraintViolationBuilder.addBeanNode()

         [ERROR] Line 142: The type ConstraintValidatorContextImpl<A,T>.NodeContextBuilderImpl must implement the inherited abstract method ConstraintValidatorContext.ConstraintViolationBuilder.NodeContextBuilder.addBeanNode()

         [ERROR] Line 142: The type ConstraintValidatorContextImpl<A,T>.NodeContextBuilderImpl must implement the inherited abstract method ConstraintValidatorContext.ConstraintViolationBuilder.NodeContextBuilder.addPropertyNode(String)

   Tracing compile failure path for type 'javax.validation.ParameterNameProvider'

      [ERROR] Errors in 'javax/validation/ParameterNameProvider.java'

         [ERROR] Line 54: No source code is available for type java.lang.reflect.Method; did you forget to inherit a required module?

         [ERROR] Line 44: No source code is available for type java.lang.reflect.Constructor<T>; did you forget to inherit a required module?

   Tracing compile failure path for type 'com.google.gwt.validation.client.GwtConstraintValidatorFactory'

      [ERROR] Errors in 'com/google/gwt/validation/client/GwtConstraintValidatorFactory.java'

         [ERROR] Line 26: The type GwtConstraintValidatorFactory must implement the inherited abstract method ConstraintValidatorFactory.releaseInstance(ConstraintValidator<?,?>)

   Tracing compile failure path for type 'javax.validation.executable.ExecutableValidator'

      [ERROR] Errors in 'javax/validation/executable/ExecutableValidator.java'

         [ERROR] Line 53: No source code is available for type java.lang.reflect.Method; did you forget to inherit a required module?

         [ERROR] Line 94: No source code is available for type java.lang.reflect.Constructor<T>; did you forget to inherit a required module?

   Tracing compile failure path for type 'com.google.gwt.validation.client.impl.PropertyDescriptorImpl'

      [ERROR] Errors in 'com/google/gwt/validation/client/impl/PropertyDescriptorImpl.java'

         [ERROR] Line 31: The type PropertyDescriptorImpl must implement the inherited abstract method CascadableDescriptor.getGroupConversions()

      [ERROR] Errors in 'com/google/gwt/validation/client/impl/ConstraintDescriptorImpl.java'

         [ERROR] Line 35: The type ConstraintDescriptorImpl<T> must implement the inherited abstract method ConstraintDescriptor<T>.getMessageTemplate()

         [ERROR] Line 35: The type ConstraintDescriptorImpl<T> must implement the inherited abstract method ConstraintDescriptor<T>.getValidationAppliesTo()

   Tracing compile failure path for type 'com.google.gwt.validation.client.impl.GwtBeanDescriptorImpl'

      [ERROR] Errors in 'com/google/gwt/validation/client/impl/GwtBeanDescriptorImpl.java'

         [ERROR] Line 38: The type GwtBeanDescriptorImpl<T> must implement the inherited abstract method BeanDescriptor.getConstraintsForConstructor(Class<?>...)

         [ERROR] Line 38: The type GwtBeanDescriptorImpl<T> must implement the inherited abstract method BeanDescriptor.getConstrainedConstructors()

         [ERROR] Line 38: The type GwtBeanDescriptorImpl<T> must implement the inherited abstract method BeanDescriptor.getConstraintsForMethod(String, Class<?>...)

         [ERROR] Line 38: The type GwtBeanDescriptorImpl<T> must implement the inherited abstract method BeanDescriptor.getConstrainedMethods(MethodType, MethodType...)

      [ERROR] Errors in 'com/google/gwt/validation/client/impl/ConstraintDescriptorImpl.java'

         [ERROR] Line 35: The type ConstraintDescriptorImpl<T> must implement the inherited abstract method ConstraintDescriptor<T>.getMessageTemplate()

         [ERROR] Line 35: The type ConstraintDescriptorImpl<T> must implement the inherited abstract method ConstraintDescriptor<T>.getValidationAppliesTo()

      [ERROR] Errors in 'com/google/gwt/validation/client/impl/PropertyDescriptorImpl.java'

         [ERROR] Line 31: The type PropertyDescriptorImpl must implement the inherited abstract method CascadableDescriptor.getGroupConversions()

   [ERROR] Aborting compile due to errors in some input files

[Thomas Broyer]

On Wednesday, June 15, 2016 at 6:42:11 AM UTC+2, Hristo Stoyanov wrote:

Hi all,

 I have a couple of questions regarding GWT 2.8 SNAPSHOT:

1. Why am I picking up  tons of jetty libraries for doing a simple gwt compilation? I could understand the need for the Jetty jars, if I was running the code server, or including the servlet library, but just for compilation...? Seems like this is coming from the gwt-dev.jar?

Jetty is needed by CodeServer and DevMode (which is used as the basis for the JUnitShell for running GWTTestCases), all of them are inside gwt-dev.jar (yes, gwt-codeserver.jar is absolutely useless, all its classes are in gwt-dev.jar since GWT 2.7 at least) so Jetty is a dependency of gwt-dev.jar, even though it's not always being used.

If you never use the above, then you can safely exclude them:

dependencies {

  gwtSdk('com.google.gwt:gwt-dev:2.8.0-SNAPSHOT') {

    exclude group: 'org.eclipse.jetty'

  }

}

or

configurations {

  gwtSdk.exclude group: 'org.eclipse.jetty'

}

2. When is the validation api in GWT 2.8 going to be upgraded to 1.1.0.Final? Other libraries are forcing a dependency upgrade, which results in this mess:

Those "other libraries" are likely not related to GWT, so it should be easy to get 1.0.0.GA for GWT and 1.1.0.Final for the server side.

Using gwt-gradle-plugin, that'd likely be:

configurations.gwt {

  resolutionStrategy {

    force 'javax.validation:validation-api:1.0.0.GA'

  }

}

As for the first part of the question: whenever someone will roll up his sleeves and pick the task (without abandoning in the last miles, as we've seen before).

See https://github.com/gwtproject/gwt/issues/7658 and https://github.com/gwtproject/gwt/issues/8869

I think that, by the next version, we might try to remove javax.validation support from GWT altogether, other than a few supersourced classes for backwards compatibility (ConstraintViolations are used by EditorDriver, and many widgets depend on the Editor Framework, so unless we split the Editor Framework in 2 –which BTW seems entirely possible– this is a transitive dependency of com.google.gwt.user.User)

[Jens]

1. Why am I picking up  tons of jetty libraries for doing a simple gwt compilation? I could understand the need for the Jetty jars, if I was running the code server, or including the servlet library, but just for compilation...? Seems like this is coming from the gwt-dev.jar?

gwt-dev.jar contains DevMode and also bundles CodeServer (because of older GPE which does not put gwt-codeserver.jar on classpath automatically) and both depend on embedded Jetty. Thats why you have jetty dependencies.

 

2. When is the validation api in GWT 2.8 going to be upgraded to 1.1.0.Final? 

Probably never if no one contributes it. There is a patch in review that updates Hibernate Validator to 4.3.2 but that is still not validation api 1.1.0, see https://gwt-review.googlesource.com/#/c/9320/

If it wouldn't be a feature RequestFactory depends on I think validation support would have been extracted already from GWT into its own project and either let it die or let someone pick it up to maintain it. 

-- J.

[Thomas Broyer]

On Wednesday, June 15, 2016 at 10:49:56 AM UTC+2, Jens wrote:

If it wouldn't be a feature RequestFactory depends on

Oh, you're right, the Editor Framework depends on javax.validation.ConstraintViolation but doesn't implement it so one could probably have 1.1.0.Final in classpath without problem (assuming all interface dependencies are usable without super-source).

The real issue here (besides JSR 303 emulation itself) is RequestFactory, which *implements* ConstraintViolation; but we could possibly add the 1.1.0.Final methods (without the @Override, to be compatible with 1.0.0.GA). For the longer term, use of ConstraintViolation in the Editor Framework and RequestFactory should be sunsetted, a new method taking EditorErrors (or some other custom type, e.g. SimpleViolation) added to EditorDriver, and RequestFactoryEditorDriver#setViolations and Receiver#onViolation de-deprecated, possibly with a public API to turn an RF Violation into an EditorError/SimpleViolation for those using a SimpleEditorDriver.

 

I think validation support would have been extracted already from GWT into its own project and either let it die or let someone pick it up to maintain it.

Absolutely!

Given the above, we could actually do that already I believe.

Probably won't be for 2.8.0 though (too late; sorry for not realizing this before); but I think we should at least officially deprecate JSR303 support in GWT 2.8 (this is long overdue actually): https://github.com/gwtproject/gwt/issues/9367

[Hristo Stoyanov]

Thank you Jens and Thomas!
I am trying to cut down get compile time and produce thin wars ...

[Hristo Stoyanov]

Another idea:

Can we create a gwtcompile.jar for GWT 2.8, which is basically going to be the same as gwt-dev.jar , minus all jetty jars? With GWT compilation being so slow, eliminating tons of unrelated jars would help with compilation time? Plus, GWT 2.8 will remain backward-compatible.

[Thomas Broyer]

On Wednesday, June 22, 2016 at 8:57:30 AM UTC+2, Hristo Stoyanov wrote:

Another idea:

Can we create a gwtcompile.jar for GWT 2.8, which is basically going to be the same as gwt-dev.jar , minus all jetty jars? With GWT compilation being so slow, eliminating tons of unrelated jars would help with compilation time? Plus, GWT 2.8 will remain backward-compatible.

That'd be ideal, and we actually already build such a JAR (or at least we know how to build it, and Google builds it internally so we know it can be built).

Not sure if I could get it done for 2.8 though.