Hello - I’m a looking to see if there is a way to specify a secondary gradleclasspathcontainer.
I see that in GradleClassPathContainer.java - there is only a single reference to the container, so I’m not sure this is possible yet.
I have put together a small example project to illustrate the classpath loader issue that occurs when a GWT container is required to appear in the classpath before the gradleclasspathcontainer - see build.gradle.
The issue is that the gwt-dev.jar contains a very old version of org.apache.http.conn.ssl.SSLConnectionSocketFactory (1.5 actually), which doesn’t contain the necessary methods, resulting in the following exception when the test case is run:
Exception in thread "main" java.lang.NoSuchMethodError: org.apache.http.conn.ssl.SSLConnectionSocketFactory.<init>(Ljavax/net/ssl/SSLContext;Ljavax/net/ssl/HostnameVerifier;)V
If it were possible to create a secondary gradle class path container, and possibly annotate the dependencies to indicate which container they belong to, then theoretically, this new container could appear before the GWT container and resolve this class loader issue.
I imagine something like this to be necessary:
@Container("custom")
dependencies {
compile group: 'org.apache.httpcomponents', name: 'httpclient', version: '4.5.9'
}
dependencies {
// everything else
}
The eclipse classpath task could then be updated to reflect the new container and respective order:
eclipse {
classpath {
defaultOutputDir = file('src/main/webapp/WEB-INF/classes')
`containers 'org.eclipse.buildship.core.gradleclasspathcontainer.custom'`
containers 'com.google.gwt.eclipse.core.GWT_CONTAINER'
containers 'com.gwtplugins.gwt.eclipse.core.GWT_CONTAINER'
containers 'org.eclipse.buildship.core.gradleclasspathcontainer'
}
}
I prefer this approach over manually attaching libraries in the WEB-INF/lib folder so that dependency versions can still be managed.
Thank you in advance for your time in reviewing this help/discussion topic.