gretty-gradle-plugin / gretty Goto Github PK

View Code? Open in Web Editor NEW

This project forked from akhikhl/gretty

126.0 126.0 35.0 5.94 MB

Advanced gradle plugin for running web-apps on jetty and tomcat.

License: MIT License

Groovy 71.43% HTML 11.02% Java 14.34% CSS 1.76% JavaScript 1.45%

gradle-plugin groovy-code jetty jetty9 tomcat tomcat9

gretty's People

Contributors

$octylfractal avatar$

Stargazers

Watchers

gretty's Issues

Gretty 2.2 cannot find resources in java-library project dependencies

Please see the example at https://github.com/carey/gretty-resources.

If I start this by running

./gradlew clean :web:appRun

then the servlet in the lib module cannot load the hello.properties resource in the same module from the class path. I can fix this by using the java plugin for lib instead of java-library, or by running

./gradlew clean :lib:jar :web:appRun

I assume this is related to #37.

Parallelize integrationTests/testAll by target container, avoid Travis 50-minute timeout

This is a follow-up to #35 . Now that we have a few extra container-branches, the integration-tests take a long time to run. We should provide parameters and/or tasks (if they aren't already there, should check) so that integration tests can be run separately/in-parallel by-container (jetty94, tomcat8 etc.).

Currently the testAll task collects all NxM combinations of test/container. The current execution time on Travis is between 40-50 minutes and has already timed-out once. Let's run these in-parallel which is the preferred Travis approach.

Webapp with Form-Based Authentication shows empty page instead of login page

I have a webapp with Form-Based Authentication configured in web.xml and gretty configured to use tomcat9 with a serverConfigFile where Realm is configured.

The the app works fine when run from war on normal tomcat install, but when started with gretty's tomcat, trying to load a secured page shows only a blank page (or browser's own 403 page on chrome). Non-secured pages work as intended.

Gretty version is 2.2.0

Feature request: Faster Startups

Given that Gretty is used heavily for testing, I'm surprised there isn't more discussion about minimizing startup time. Both Tomcat and Jetty waste 5-8 seconds waiting for SecureRandom to initialize.

WINDOWS:

The easiest solution is to promote the windows-specific security provider:
https://stackoverflow.com/questions/49322948/

gretty {
    // Do not use SystemProperty, which replaces the JRE's java.security settings.
    jvmArgs = ['-Djava.security.properties=java-overrides.security']
    // Only needed for tomcat
    contextConfigFile = "test-context.xml"
}

java-overrides.security:

security.provider.1=SunMSCAPI
security.provider.12=SUN

test-context.xml (Only needed for Tomcat):

<Context>
    <Manager pathname="" secureRandomAlgorithm="Windows-PRNG"/>
</Context>

LINUX:

For production systems, the easiest solution is haveged :
https://stackoverflow.com/questions/28201794/

System-level configurations aren't appropriate for a gradle plugin, but it's probably helpful to point the jvm to file:/dev/urandom instead:

java-overrides.security:

securerandom.source=file:/dev/urandom

These configurations are probably complex enough that most people probably won't bother. It should be possible for gretty to expose a single option that applies the appropriate solution for the given servlet container / operating system:

gretty {
    fastSecureRandomInitialization = true
}

Either way, I'm happy to add small section to the gretty documentation on how to improve startup times, which would also include information on how to configure jar scanning on tomcat.

farmSecure tests broken for Jetty 9.3 and 9.4

09:00:25 INFO  Configuring /MyWebApp with realm 'auth', /home/travis/build/javabrett/gretty/integrationTests/farmSecure/security/jetty-realm.properties
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
09:00:27 INFO  Configuring /MyWebService with realm 'auth', /home/travis/build/javabrett/gretty/integrationTests/farmSecure/security/jetty-realm.properties
09:00:27 INFO  Jetty 9.3.23.v20180228 started and listening on port 8443
09:00:27 INFO  MyWebApp runs at:
09:00:27 INFO    https://localhost:8443/MyWebApp
09:00:27 INFO  MyWebService runs at:
09:00:27 INFO    https://localhost:8443/MyWebService
> Task :gretty-integrationTests:farmSecure:MyWebApp:farmBeforeIntegrationTestjetty9.3
> Task :gretty-integrationTests:farmSecure:MyWebApp:beforeIntegrationTest_jetty9.3 SKIPPED
> Task :gretty-integrationTests:farmSecure:MyWebApp:compileIntegrationTestJava NO-SOURCE
> Task :gretty-integrationTests:farmSecure:MyWebApp:compileIntegrationTestGroovy
> Task :gretty-integrationTests:farmSecure:MyWebApp:processIntegrationTestResources NO-SOURCE
> Task :gretty-integrationTests:farmSecure:MyWebApp:integrationTestClasses
> Task :gretty-integrationTests:farmSecure:MyWebApp:integrationTest_jetty9.3
org.akhikhl.examples.gretty.mywebapp.LogonSpec > should accept valid credentials FAILED
    org.spockframework.runtime.ConditionFailedWithExceptionError at LogonSpec.groovy:50
        Caused by: geb.waiting.WaitTimeoutException at LogonSpec.groovy:50
            Caused by: org.openqa.selenium.UnhandledAlertException at LogonSpec.groovy:50
2 tests completed, 1 failed
> Task :gretty-integrationTests:farmSecure:MyWebApp:integrationTest_jetty9.3 FAILED
> Task :gretty-integrationTests:farmSecure:MyWebApp:afterIntegrationTest_jetty9.3 SKIPPED

Gretty, Spring MVC and hot deployment

Hi! Thanks for the great plugin, but I have an issue with its hot deployment feature, which I have described here as well. The issue is as follows:

I am learning Spring MVC and trying to use it together with Gradle and Gretty plugin. I have successfully created a "Hello World" project, however I am not able to use hot deployment with Gretty, despite setting the managedClassReload=true. I run the application by using appRun gretty task from IntelliJ. My build.gradle is as follows:

apply plugin: 'java'
apply plugin: 'application'
apply plugin: 'war'
apply from: 'https://raw.github.com/gretty-gradle-plugin/gretty/master/pluginScripts/gretty.plugin'

group = 'lukeg'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = 1.8
mainClassName = 'lukeg.LearnApplication'

repositories {
	mavenCentral()
	maven {
		url 'https://repo.spring.io/libs-snapshot'
	}
}


dependencies {
	compileOnly('org.projectlombok:lombok:+')
	compile('org.springframework:spring-webmvc:4.3.17.RELEASE')
	compile("org.aspectj:aspectjweaver:1.8.11")
	compile('org.springframework:spring-context:4.3.18.BUILD-SNAPSHOT')
	providedCompile group: 'javax.servlet', name: 'javax.servlet-api', version: '3.1.0'
}

gretty {
	httpPort = 8080
	contextPath = '/'
	servletContainer = 'tomcat9'
	//reloadOnClassChange=true
	managedClassReload=true
	loggingLevel='DEBUG'
}

It does not matter whether I use tomcat9 or jetty9 for servlet container: the logs do not show that the changes to source files in project are detected by Gretty.

Interesingly enough, when I comment out the managedClassReload=true line and uncomment reloadOnClassChange=true the changes to source files are detected and the project is automatically reloaded.

What can be the cause for gretty's hot deployment not working? Does springloaded not work together with Spring MVC?

Gretty plugin resolves Gradle configurations in a user-managed thread

I wanted to provide a heads up around a coming Gradle deprecation that will affect the Gretty plugin. With Gradle 5.0, we will output a deprecation warning whenever a configuration is resolved outside of a Gradle-managed thread. The reason for this is because configuration resolution is an event that modifies the Gradle project model and if multiple threads are changing the model at the same time, this can produce inconsistent results. In 5.0, we are introducing some safety for this in Gradle-managed threads, but we can't guarantee safety in user-managed threads. The gretty plugin is resolving a configuration here that is being executed in a user-managed thread started here and produces a deprecation warning when run with Gradle 5.0.

To avoid this warning, I believe there's a fairly simple fix. Instead of resolving the configuration inside of the spawned thread, the plugin should resolve the configuration in the task thread (which is Gradle-managed) immediately before spawning the child thread. This will allow the configuration to be resolved safely under Gradle's control and then only the resolution results will be used in the user-managed thread.

From a reproduction/testing perspective, the first Gradle 5.0 RC is due out next week, but in the meantime, nightly builds are available here.

I hope that makes sense - if it doesn't, I'm happy to answer any questions or help with finding an alternate solution if the one proposed is not workable for some reason.

Convert most classes to use `@CompileStatic`

The Gretty plugin can have a negative impact on configuration time since all of it currently uses dynamic Groovy. Using CompileStatic on a significant number if not on all classes would improve configuration time already a lot.

Update base jetty94 to 9.4.9

Jetty 9.4.9 has been released. Has JDK10 support.

JDK9 simple smoke-test fails during logback initialization

Project with this build.gradle:

apply plugin: 'war'
apply from: 'https://raw.githubusercontent.com/gretty-gradle-plugin/gretty/master/pluginScripts/gretty-SNAPSHOT.plugin'

gretty {
  servletContainer = 'jetty9.4'
  httpPort = 8080
}

..., a Gradle 4.6 wrapper and a single file src/main/webapp/index.html.

Running appRun with JDK8 is fine, with JDK9 fails with:

Exception in thread "main" java.lang.NullPointerException: Cannot invoke method getText() on null object
        at org.codehaus.groovy.runtime.NullObject.invokeMethod(NullObject.java:91)
        at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:48)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.NullCallSite.call(NullCallSite.java:35)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
        at org.akhikhl.gretty.Runner.initLogback(Runner.groovy:65)
        at org.akhikhl.gretty.Runner$initLogback.callStatic(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:56)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:194)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:206)
        at org.akhikhl.gretty.Runner.run(Runner.groovy:115)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:210)
        at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.call(PogoMetaMethodSite.java:71)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
        at org.akhikhl.gretty.Runner.main(Runner.groovy:44)

Relevant line of code https://github.com/gretty-gradle-plugin/gretty/blob/master/libs/gretty-runner/src/main/groovy/org/akhikhl/gretty/Runner.groovy#L65:

logbackConfigText = this.getClass().getResourceAsStream('/grettyRunnerLogback.groovy').getText('UTF-8')

getResourceAsStream returns null.

I have a candidate fix with a slightly different way of loading the resource file, but wondered if others could reproduce this. Maybe something changes in Groovy with JDK9 and classloaders/resources. Reproduces with 2.0.0 and JDK9.

Release 2.1.0

Barring some documentation updates, I believe the current master is fairly ready for a release. I'm using approximately the same build in production, and it has solved the jdk9, gradle and spring related problems that I had with 2.0.0.

Is anything else missing?

Edit

List of potential release-blockers:

~~#13 JDK9 simple smoke-test fails during logback initialization~~
~~#15 JDK9 cannot complete testAll: Jasper Source option 1.5 is no longer supported. Use 1.6 or later.~~
#23 JDK9 Jasper/JSPC for Jetty 9.4.8.v20171121 is not fully JDK9-ready

Farm does not properly handle duplicate webapps

The following spec will bring up only the last specified server:

farms {
  farm 'DoubleDeploy,' {
    webapp ':server', contextPath: "/control"
    webapp ':server', contextPath: "/test"
  }
}

For now, it is possible to specify 2 separate servlet containers, but its messy and results in 2 servlet containers:

farms {
    farm 'Control', {
        webapp ':karmata-server', contextPath: "/"
        httpPort = 8000
        servicePort = 8002
        statusPort = 8003
        portPropertiesFileName = "control_ports.properties"
    }
    farm 'Test', {
        webapp ':karmata-server', contextPath: "/"
        httpPort = 8004
        servicePort = 8006
        statusPort = 8007
        portPropertiesFileName = "test_ports.properties"
    }
}

Our goal is to support end-to-end visual difference testing of the webapp's javascript frontend. This approach requires separate sandboxed endpoints for the control and test sides.

Work out how to run testAll on Travis

From what I can see, testAll currently won't run on Travis, despite the efforts in-place to run xvfb for Selenium/WebDriver to run the tests. Per https://travis-ci.org/gretty-gradle-plugin/gretty/jobs/349197672 currently this fails with:

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
09:17:25 INFO  Jetty 7.6.16.v20140903 started and listening on port 8080
09:17:25 INFO  extraResourceBases runs at:
09:17:25 INFO    http://localhost:8080/extraResourceBases
...
:gretty-integrationTests:extraResourceBases:integrationTest_jetty7
org.akhikhl.examples.gretty.hellogretty.ExtraResourceBasesSpec > should get expected static page FAILED
    geb.driver.DriverCreationException at ExtraResourceBasesSpec.groovy:23
        Caused by: org.openqa.selenium.WebDriverException at ExtraResourceBasesSpec.groovy:23
            Caused by: org.apache.http.conn.HttpHostConnectException at ExtraResourceBasesSpec.groovy:23
                Caused by: java.net.ConnectException at ExtraResourceBasesSpec.groovy:23
    geb.driver.DriverCreationException
        Caused by: org.openqa.selenium.WebDriverException
            Caused by: org.apache.http.conn.HttpHostConnectException
                Caused by: java.net.ConnectException
    geb.driver.DriverCreationException
        Caused by: org.openqa.selenium.WebDriverException
            Caused by: org.apache.http.conn.HttpHostConnectException
                Caused by: java.net.ConnectException

So either the port is not up, or Selenium is trying to connect to something other than localhost:8080, or there's some proxy-config problem. What am I missing?

Glancing at the code it looks like the test-framework queries the running server to gather host/port details for the test client - maybe something goes wrong there.

I was a little surprised to find no integration tests running on Travis at all. It does do an NxM run across all container/versions, so took ~30 minutes on my machine, so might be better as a nightly run. But otherwise this is a manual task on developer machines.

JDK9 Tomcat8 testAll java.lang.NoSuchFieldException: loaderRef

Saw this running testAll with JDK9:

Mar. 06, 2018 12:16:42 PM org.apache.coyote.AbstractProtocol pause
INFO: Pausing ProtocolHandler ["http-nio-8080"]
Mar. 06, 2018 12:16:42 PM org.apache.catalina.core.StandardService stopInternal
INFO: Stopping service Tomcat
Mar. 06, 2018 12:16:42 PM org.apache.catalina.loader.WebappClassLoaderBase clearReferencesResourceBundles
WARNING: Failed to clear ResourceBundle references for web application [ROOT]
java.lang.NoSuchFieldException: loaderRef
        at java.base/java.lang.Class.getDeclaredField(Class.java:2368)
        at org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesResourceBundles(WebappClassLoaderBase.java:2402)
        at org.apache.catalina.loader.WebappClassLoaderBase.clearReferences(WebappClassLoaderBase.java:1617)
        at org.apache.catalina.loader.WebappClassLoaderBase.stop(WebappClassLoaderBase.java:1537)
        at org.apache.catalina.loader.WebappLoader.stopInternal(WebappLoader.java:446)
        at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:221)
        at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5572)
        at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:221)
        at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1424)
        at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1413)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.base/java.lang.Thread.run(Thread.java:844)

Note that this seems to be a clean-up exception only, and does not impact nor fail the test.

Unable to use Gretty with Gradle 4.6+

I get a stack trace that looks like this:

* Exception is:
org.gradle.api.ProjectConfigurationException: A problem occurred configuring project ':tems-struts'.
        at org.gradle.configuration.project.LifecycleProjectEvaluator.addConfigurationFailure(LifecycleProjectEvaluator.java:94)
        at org.gradle.configuration.project.LifecycleProjectEvaluator.notifyAfterEvaluate(LifecycleProjectEvaluator.java:89)
        at org.gradle.configuration.project.LifecycleProjectEvaluator.doConfigure(LifecycleProjectEvaluator.java:70)
        at org.gradle.configuration.project.LifecycleProjectEvaluator.access$100(LifecycleProjectEvaluator.java:34)
        at org.gradle.configuration.project.LifecycleProjectEvaluator$ConfigureProject.run(LifecycleProjectEvaluator.java:110)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
        at org.gradle.configuration.project.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:50)
        at org.gradle.api.internal.project.DefaultProject.evaluate(DefaultProject.java:667)
        at org.gradle.api.internal.project.DefaultProject.evaluate(DefaultProject.java:136)
        at org.gradle.execution.TaskPathProjectEvaluator.configure(TaskPathProjectEvaluator.java:35)
        at org.gradle.execution.TaskPathProjectEvaluator.configureHierarchy(TaskPathProjectEvaluator.java:62)
        at org.gradle.configuration.DefaultBuildConfigurer.configure(DefaultBuildConfigurer.java:38)
        at org.gradle.initialization.DefaultGradleLauncher$ConfigureBuild.run(DefaultGradleLauncher.java:261)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
        at org.gradle.initialization.DefaultGradleLauncher.configureBuild(DefaultGradleLauncher.java:173)
        at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:132)
        at org.gradle.initialization.DefaultGradleLauncher.executeTasks(DefaultGradleLauncher.java:115)
        at org.gradle.internal.invocation.GradleBuildController$1.call(GradleBuildController.java:78)
        at org.gradle.internal.invocation.GradleBuildController$1.call(GradleBuildController.java:75)
        at org.gradle.internal.work.DefaultWorkerLeaseService.withLocks(DefaultWorkerLeaseService.java:152)
        at org.gradle.internal.invocation.GradleBuildController.doBuild(GradleBuildController.java:100)
        at org.gradle.internal.invocation.GradleBuildController.run(GradleBuildController.java:75)
        at org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:28)
        at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
        at org.gradle.tooling.internal.provider.ValidatingBuildActionRunner.run(ValidatingBuildActionRunner.java:32)
        at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner$1.run(RunAsBuildOperationBuildActionRunner.java:43)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
        at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner.run(RunAsBuildOperationBuildActionRunner.java:40)
        at org.gradle.tooling.internal.provider.SubscribableBuildActionRunner.run(SubscribableBuildActionRunner.java:51)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:49)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:32)
        at org.gradle.launcher.exec.BuildTreeScopeBuildActionExecuter.execute(BuildTreeScopeBuildActionExecuter.java:39)
        at org.gradle.launcher.exec.BuildTreeScopeBuildActionExecuter.execute(BuildTreeScopeBuildActionExecuter.java:25)
        at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:80)
        at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:53)
        at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:57)
        at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:32)
        at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:36)
        at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:25)
        at org.gradle.tooling.internal.provider.ParallelismConfigurationBuildActionExecuter.execute(ParallelismConfigurationBuildActionExecuter.java:43)
        at org.gradle.tooling.internal.provider.ParallelismConfigurationBuildActionExecuter.execute(ParallelismConfigurationBuildActionExecuter.java:29)
        at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:64)
        at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:29)
        at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:59)
        at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:44)
        at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:45)
        at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:30)
        at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:51)
        at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:173)
        at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:285)
        at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:258)
        at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
        at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
        at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:251)
        at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:185)
        at org.gradle.launcher.Main.doAction(Main.java:36)
        at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
        at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:60)
        at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:37)
        at org.gradle.launcher.GradleMain.main(GradleMain.java:23)
        at org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:31)
        at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:108)
        at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:61)
Caused by: org.gradle.api.tasks.TaskInstantiationException: Could not create task of type 'AppStartTask'.
        at org.gradle.api.internal.project.taskfactory.TaskFactory$1.call(TaskFactory.java:121)
        at org.gradle.api.internal.project.taskfactory.TaskFactory$1.call(TaskFactory.java:116)
        at org.gradle.util.GUtil.uncheckedCall(GUtil.java:458)
        at org.gradle.api.internal.AbstractTask.injectIntoNewInstance(AbstractTask.java:189)
        at org.gradle.api.internal.project.taskfactory.TaskFactory.create(TaskFactory.java:116)
        at org.gradle.api.internal.project.taskfactory.TaskFactory.createTask(TaskFactory.java:74)
        at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory.createTask(AnnotationProcessingTaskFactory.java:44)
        at org.gradle.api.internal.tasks.DefaultTaskContainer.create(DefaultTaskContainer.java:80)
        at org.gradle.api.internal.project.DefaultProject.task(DefaultProject.java:1209)
        at org.gradle.api.Project$task$6.call(Unknown Source)
        at org.akhikhl.gretty.GrettyPlugin.addTasks(GrettyPlugin.groovy:343)
        at org.akhikhl.gretty.GrettyPlugin.afterProjectEvaluate(GrettyPlugin.groovy:701)
        at org.akhikhl.gretty.GrettyPlugin$_apply_closure64.doCall(GrettyPlugin.groovy:808)
        at org.gradle.listener.ClosureBackedMethodInvocationDispatch.dispatch(ClosureBackedMethodInvocationDispatch.java:40)
        at org.gradle.listener.ClosureBackedMethodInvocationDispatch.dispatch(ClosureBackedMethodInvocationDispatch.java:25)
        at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:42)
        at org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:230)
        at org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:149)
        at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:58)
        at org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:324)
        at org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:234)
        at org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:140)
        at org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:37)
        at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
        at com.sun.proxy.$Proxy27.afterEvaluate(Unknown Source)
        at org.gradle.configuration.project.LifecycleProjectEvaluator.notifyAfterEvaluate(LifecycleProjectEvaluator.java:76)
        ... 70 more
Caused by: java.lang.NullPointerException
        at org.gradle.testing.jacoco.plugins.JacocoPluginExtension.applyTo(JacocoPluginExtension.java:117)
        at org.gradle.testing.jacoco.plugins.JacocoPluginExtension$applyTo.call(Unknown Source)
        at org.akhikhl.gretty.StartBaseTask.initJacoco(StartBaseTask.groovy:156)
        at org.akhikhl.gretty.StartBaseTask.<init>(StartBaseTask.groovy:41)
        at org.akhikhl.gretty.AppStartTask.<init>(AppStartTask.groovy)
        at org.akhikhl.gretty.AppStartTask_Decorated.<init>(Unknown Source)
        at org.gradle.api.internal.DependencyInjectingInstantiator.newInstance(DependencyInjectingInstantiator.java:81)
        at org.gradle.api.internal.project.taskfactory.TaskFactory$1.call(TaskFactory.java:119)
        ... 95 more

ArtifactResolveException: Could not resolve all files for configuration 'grettyRunnerTomcat7'

After upgrading to 2.2.0 I get this error. The documentation says that Tomcat 7 is still supported, so I'm not sure why it's not being found.

In order to get it to work, I had to add jcenter() to my project repository section (as opposed to the build script repository)

I'd prefer to keep jcenter in the buildscript section only if possible.

Tomcat9 testTomcatServerConfig fails with ReadOnlyPropertyException: Cannot set readonly property: service for class: org.apache.catalina.startup.Tomcat

Mar 12, 2018 12:42:05 PM org.apache.catalina.startup.Catalina addClusterRuleSet
INFO: Cluster RuleSet not found due to [java.lang.ClassNotFoundException: org.apache.catalina.ha.ClusterRuleSet]. Cluster configuration disabled.
Mar 12, 2018 12:42:05 PM org.apache.catalina.startup.Catalina addClusterRuleSet
INFO: Cluster RuleSet not found due to [java.lang.ClassNotFoundException: org.apache.catalina.ha.ClusterRuleSet]. Cluster configuration disabled.
Exception in thread "main" groovy.lang.ReadOnlyPropertyException: Cannot set readonly property: service for class: org.apache.catalina.startup.Tomcat
        at groovy.lang.MetaClassImpl.setProperty(MetaClassImpl.java:2744)
        at groovy.lang.MetaClassImpl.setProperty(MetaClassImpl.java:3770)
        at org.codehaus.groovy.runtime.InvokerHelper.setProperty(InvokerHelper.java:201)
        at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setProperty(ScriptBytecodeAdapter.java:484)
        at org.akhikhl.gretty.TomcatServerConfigurer.createAndConfigureServer(TomcatServerConfigurer.groovy:72)
        at org.akhikhl.gretty.TomcatServerConfigurer.createAndConfigureServer(TomcatServerConfigurer.groovy)
        at org.akhikhl.gretty.TomcatServerConfigurer$createAndConfigureServer.call(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
        at org.akhikhl.gretty.TomcatServerManager.startServer(TomcatServerManager.groovy:45)
        at org.akhikhl.gretty.ServerManager$startServer$0.call(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
        at org.akhikhl.gretty.Runner.run(Runner.groovy:117)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:210)
        at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.call(PogoMetaMethodSite.java:71)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
        at org.akhikhl.gretty.Runner.main(Runner.groovy:44)

testAll run (JDK8) then blocks at:

> :testAllIntegrationTests
> :gretty-integrationTests:testTomcatServerConfig:beforeIntegrationTest_tomcat9

Relevant code: https://github.com/gretty-gradle-plugin/gretty/blob/master/libs/gretty-runner-tomcat/src/main/groovy/org/akhikhl/gretty/TomcatServerConfigurer.groovy#L72

    Tomcat tomcat = new Tomcat()
...
      tomcat.service = service

@boris-petrov PTAL if you get a chance.

Retire Gradle 1.x support

This is hopefully mostly a small doc task. Need to decide, based on the release version and branch whether we will deprecate Gradle 2.x (last release v2.14.1 Jul 18, 2016, v3.0 Aug 15, 2016).

/cc #46 .

Respond to JEP 320: Removal of deprecated Java EE and CORBA Modules (jdk11)

Ref: http://openjdk.java.net/jeps/320 . This was discussing in #40 when JDK_JAVA_OPTIONS="--add-modules=java.xml.bind" was added to JDK9 builds as a quick-fix.

Proper fix is to add external dependencies.

Register/release org.gretty plugin with Gradle Central Plugin Repository https://plugins.gradle.org/

Currently this works:

build.gradle

plugins {
  id "org.akhikhl.gretty" version "2.0.0"
}

apply plugin: 'war'

repositories {
  jcenter()
}

gretty {
  servletContainer = 'jetty9.4'
  httpPort = 8080
}

... due to the registration at https://plugins.gradle.org/plugin/org.akhikhl.gretty . org.gretty (release 2.1.0) is not registered so the equivalent:

plugins {
  id "org.gretty" version "2.1.0"
}

... does not work. This issue is about setting-up the best publishing-mechanism according to https://plugins.gradle.org/docs/publish-plugin and following that for either 2.1.0 or 2.2.0.

Fragile integration test websocket:

Intermittent test-failure - seems like it can occur at any time or container. Fails with geb.error.NoNewWindowException at RequestResponseIT.groovy:38.

> Task :gretty-integrationTests:websocket:compileJava UP-TO-DATE
> Task :gretty-integrationTests:websocket:compileGroovy NO-SOURCE
> Task :gretty-integrationTests:websocket:processResources UP-TO-DATE
> Task :gretty-integrationTests:websocket:classes UP-TO-DATE
> Task :gretty-integrationTests:websocket:compileTestJava NO-SOURCE
> Task :gretty-integrationTests:websocket:compileTestGroovy NO-SOURCE
> Task :gretty-integrationTests:websocket:processTestResources NO-SOURCE
> Task :gretty-integrationTests:websocket:testClasses UP-TO-DATE
> Task :gretty-integrationTests:websocket:test NO-SOURCE
> Task :gretty-integrationTests:websocket:prepareInplaceWebAppFolder
> Task :gretty-integrationTests:websocket:createInplaceWebAppFolder
> Task :gretty-integrationTests:websocket:prepareInplaceWebAppClasses UP-TO-DATE
> Task :gretty-integrationTests:websocket:prepareInplaceWebApp
May 17, 2018 3:51:21 AM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-nio-8080"]
May 17, 2018 3:51:21 AM org.apache.tomcat.util.net.NioSelectorPool getSharedSelector
INFO: Using a shared selector for servlet write/read
May 17, 2018 3:51:22 AM org.apache.catalina.core.StandardService startInternal
INFO: Starting service [Tomcat]
May 17, 2018 3:51:22 AM org.apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet Engine: Apache Tomcat/8.5.30
May 17, 2018 3:51:22 AM org.apache.catalina.startup.ContextConfig getDefaultWebXmlFragment
INFO: No global web.xml found
May 17, 2018 3:51:22 AM org.apache.jasper.servlet.TldScanner scanJars
INFO: At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
May 17, 2018 3:51:23 AM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-nio-8080"]
03:51:23 INFO  Tomcat 8.5.30 started and listening on port 8080
03:51:23 INFO  websocket runs at:
03:51:23 INFO    http://localhost:8080/websocket
> Task :gretty-integrationTests:websocket:beforeIntegrationTest_tomcat85
> Task :gretty-integrationTests:websocket:compileIntegrationTestJava NO-SOURCE
> Task :gretty-integrationTests:websocket:compileIntegrationTestGroovy
> Task :gretty-integrationTests:websocket:processIntegrationTestResources NO-SOURCE
> Task :gretty-integrationTests:websocket:integrationTestClasses
Socket Connected: org.apache.tomcat.websocket.WsSession@44e6672d
Socket Closed: CloseReason: code [1001], reason [null]
Socket Connected: org.apache.tomcat.websocket.WsSession@6fd87ef7
Socket Connected: org.apache.tomcat.websocket.WsSession@6ab0ea0b
> Task :gretty-integrationTests:websocket:integrationTest_tomcat85
org.akhikhl.examples.gretty.websocket.RequestResponseIT > should send chat messages FAILED
    geb.error.NoNewWindowException at RequestResponseIT.groovy:38
Socket Closed: CloseReason: code [1001], reason [null]
Socket Closed: CloseReason: code [1001], reason [null]
> Task :gretty-integrationTests:websocket:integrationTest_tomcat85 FAILED
2 tests completed, 1 failed
May 17, 2018 3:51:31 AM org.apache.coyote.AbstractProtocol pause
INFO: Pausing ProtocolHandler ["http-nio-8080"]
May 17, 2018 3:51:31 AM org.apache.catalina.core.StandardService stopInternal
INFO: Stopping service [Tomcat]
May 17, 2018 3:51:31 AM org.apache.coyote.AbstractProtocol stop
INFO: Stopping ProtocolHandler ["http-nio-8080"]
May 17, 2018 3:51:31 AM org.apache.coyote.AbstractProtocol destroy
INFO: Destroying ProtocolHandler ["http-nio-8080"]
> Task :gretty-integrationTests:websocket:afterIntegrationTest_tomcat85
Server stopped.

Restarting the single failed test-group in Travis and it passes with no other changes.

Hard to say whether this is:

A real intermittent bug
Something Travis-related
Selenium / WebDriver / Gecko related
A Geb problem

Not Working With Java 9 and Overriding Jetty 9.4

Its not working with Java 9 if we oveide version of Jetty 9.4 to latest in gradle.properties
with property:
jetty94Version = 9.4.13.v20181111

Remove Tomcat 7+8 support

Remove Tomcat 7 support for release 3.x. See also discussion in #43 (comment) .

Also remove Tomcat 8.0 support, since this version was replaced by Tomcat 8.5.

Upgrade Tomcat 8.0.x support to 8.5.x

Tomcat 8.0 was end-of-lifed and Tomcat 8.5 is a mostly drop-in replacement. We should check whether the build and default Tomcat 8 can be easily switched to the Tomcat 8.5.x stream.

Missing configuration dependency resolution

It looks like the gretty tasks (like jettyRun, appRun and so on) do not actually resolve the gretty configuration though they rely on it. In my case, I added a dependency to a test-configuration artifact in a sibling module like this:

gretty project(path: ':my-library', configuration: 'testConfig')

During jetty startup, I then got an error telling me that the corresponding jar file was missing on the file system. Adding this snippet solved the problem for jettyRun:

project.afterEvaluate {
    jettyRun.dependsOn configurations.gretty
}

I guess the gretty tasks should declare this dependency themselves out-of-the-box.

Could not get unknown property 'mainClass' for object of type org.springframework.boot.gradle.dsl.SpringBootExtension.

see： rssdev10@583b230#diff-dce4984e08a1962cae1a388a6305a75a

gretty version: 2.2.0
spring boot version : 2.0.2.RELEASE

JDK9 Jasper/JSPC for Jetty 9.4.8.v20171121 is not fully JDK9-ready

I'm seeing some JSPC/Jasper JSP-compilation issues with JDK9 running testAll. Not sure yet if related, but I notice via jetty/jetty.project#2079 that Jetty 9.4.8.v20171121 running Jasper 8.5.23 is not 100% JDK9-ready. The first such Jasper release is 8.5.24, which is on the Jetty 9.4.x branch presumably to be released as 9.4.9. Snapshots are available.

We will need to determine whether its worth pulling in a Jetty 9.4.9 snapshot to see if it addresses JDK9 test-issues in order to continue, or wait for 9.4.9 release.

Deprecate JDK7 support

For Gretty 3.x it is proposed to deprecate JDK7 support. See also #43 .

master build fails when --refresh-dependencies

./gradlew build --refresh-dependencies
or
./gradlew clean build --refresh-dependencies

... fails with:

* What went wrong:
Could not resolve all files for configuration ':libs:gretty-springboot:compileClasspath'.
> Could not resolve org.springframework.boot:spring-boot-starter-web:1.5.4.RELEASE.
  Required by:
      project :libs:gretty-springboot
   > Could not resolve org.springframework.boot:spring-boot-starter-web:1.5.4.RELEASE.
      > Could not parse POM https://jcenter.bintray.com/org/springframework/boot/spring-boot-starter-web/1.5.4.RELEASE/spring-boot-starter-web-1.5.4.RELEASE.pom
         > Could not resolve org.springframework.boot:spring-boot-starters:1.5.4.RELEASE.
            > Could not resolve org.springframework.boot:spring-boot-starters:1.5.4.RELEASE.
               > Could not parse POM https://jcenter.bintray.com/org/springframework/boot/spring-boot-starters/1.5.4.RELEASE/spring-boot-starters-1.5.4.RELEASE.pom
                  > Could not find org.springframework.boot:spring-boot-parent:1.5.4.RELEASE.
                    Searched in the following locations:
                       <redacted>
                        https://jcenter.bintray.com/org/springframework/boot/spring-boot-parent/1.5.4.RELEASE/spring-boot-parent-1.5.4.RELEASE.pom
                        https://jcenter.bintray.com/org/springframework/boot/spring-boot-parent/1.5.4.RELEASE/spring-boot-parent-1.5.4.RELEASE.jar
                        https://oss.jfrog.org/artifactory/repo/org/springframework/boot/spring-boot-parent/1.5.4.RELEASE/spring-boot-parent-1.5.4.RELEASE.pom
                        https://oss.jfrog.org/artifactory/repo/org/springframework/boot/spring-boot-parent/1.5.4.RELEASE/spring-boot-parent-1.5.4.RELEASE.jar
                        https://oss.jfrog.org/artifactory/repo/org.springframework.boot/spring-boot-parent/ivy-1.5.4.RELEASE.xml
                        https://oss.jfrog.org/artifactory/repo/org.springframework.boot/spring-boot-parent/1.5.4.RELEASE/spring-boot-parent-1.5.4.RELEASE.jar

Looking at spring-boot on jcenter: https://jcenter.bintray.com/org/springframework/boot/spring-boot-parent/1.5.4.RELEASE/ it looks like there might have been a purge of old versions there or something, only the .asc signatures remain for versions older than 1.5.9.

Good encouragement to upgrade, but might need to add mavenCentral() in for now to fix this.

I gather this must have happened somewhat recently or builds on new environments would have been failing.

Some integrationTests run with the default (now Jetty 9.4.x) container

There's hopefully some easy explanation for this - I've been meaning to chase it down for a while but haven't found the time, so hopefully someone with a few spare cycles can take a look. You'll probably want a fork and active in Travis.

Since the integration tests were matrixed-out by jdk/container in Travis, I've noticed this - regardless of the container run for the bulk of the tests, on more than a few occasions the default (Jetty) container gets started. This used to be Jetty 9.2.x but is now Jetty 9.4.x (9.4.10 at the time of raising this issue).

Here's some Travis build links for an oraclejdk8:tomcat9 build, showing each occasion when Jetty is started:

Jetty 9.4.10 is started 6 times. Tomcat 9.0.7 is started 21 times.

implementation dependency not included cause ClassNotFoundException

Hi,
In recent versions of gradle, compile dependency is deprecated and replaced by implementation dependency. I find this is not considered by gretty and hence not have implementation dependencies included when doing appRun and cause ClassNotFoundException.

No signature of method: static org.akhikhl.gretty.ProjectUtils.getClassPath() is applicable for argument types: (org.gradle.api.internal.project.DefaultProject_Decorated, null, java.lang.String)

Hi,
When I run gradle appRun --stacktrace for sample web project under gradle-4.9\samples\webApplication\quickstart I get the following output:

> Task :prepareInplaceWebAppFolder
> Task :createInplaceWebAppFolder
> Task :compileJava
> Task :processResources
> Task :classes
> Task :prepareInplaceWebAppClasses
> Task :prepareInplaceWebApp
> Task :appRun FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':appRun'.
> No signature of method: static org.akhikhl.gretty.ProjectUtils.getClassPath() is applicable for argument types: (org.gradle.api.internal.project.DefaultProject_Decorated, null, java.lang.String) values: [root project 'quickstart', null, runtimeClasspath]
  Possible solutions: getClassPath(org.gradle.api.Project, boolean, java.lang.String), getClass()

* Try:
Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':appRun'.
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:110)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:77)
	at org.gradle.api.internal.tasks.execution.OutputDirectoryCreatingTaskExecuter.execute(OutputDirectoryCreatingTaskExecuter.java:51)
	at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:59)
	at org.gradle.api.internal.tasks.execution.ResolveTaskOutputCachingStateExecuter.execute(ResolveTaskOutputCachingStateExecuter.java:54)
	at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:59)
	at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:101)
	at org.gradle.api.internal.tasks.execution.FinalizeInputFilePropertiesTaskExecuter.execute(FinalizeInputFilePropertiesTaskExecuter.java:44)
	at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:91)
	at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:62)
	at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:59)
	at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54)
	at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
	at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.run(EventFiringTaskExecuter.java:51)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:300)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:292)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:174)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:90)
	at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:46)
	at org.gradle.execution.taskgraph.LocalTaskInfoExecutor.execute(LocalTaskInfoExecutor.java:42)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareWorkItemExecutor.execute(DefaultTaskExecutionGraph.java:273)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareWorkItemExecutor.execute(DefaultTaskExecutionGraph.java:258)
	at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$ExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:135)
	at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$ExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:130)
	at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$ExecutorWorker.execute(DefaultTaskPlanExecutor.java:200)
	at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$ExecutorWorker.executeWithWork(DefaultTaskPlanExecutor.java:191)
	at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$ExecutorWorker.run(DefaultTaskPlanExecutor.java:130)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
Caused by: groovy.lang.MissingMethodException: No signature of method: static org.akhikhl.gretty.ProjectUtils.getClassPath() is applicable for argument types: (org.gradle.api.internal.project.DefaultProject_Decorated, null, java.lang.String) values: [root project 'quickstart', null, runtimeClasspath]
Possible solutions: getClassPath(org.gradle.api.Project, boolean, java.lang.String), getClass()
	at org.akhikhl.gretty.StartBaseTask$1$2.resolveWebAppClassPath(StartBaseTask.groovy:213)
	at org.akhikhl.gretty.WebAppClassPathResolver$resolveWebAppClassPath.call(Unknown Source)
	at org.akhikhl.gretty.LauncherBase.writeWebAppClassPath(LauncherBase.groovy:392)
	at org.akhikhl.gretty.LauncherBase$_writeRunConfigJson_closure6$_closure7$_closure8.doCall(LauncherBase.groovy:365)
	at org.akhikhl.gretty.LauncherBase.launchThread(LauncherBase.groovy:274)
	at org.akhikhl.gretty.LauncherBase.launch(LauncherBase.groovy:199)
	at org.akhikhl.gretty.Launcher$launch.call(Unknown Source)
	at org.akhikhl.gretty.StartBaseTask.action(StartBaseTask.groovy:76)
	at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
	at org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:46)
	at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:39)
	at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:26)
	at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:786)
	at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:753)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$1.run(ExecuteActionsTaskExecuter.java:131)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:300)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:292)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:174)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:90)
	at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:120)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:99)
	... 31 more


* Get more help at https://help.gradle.org

BU?LD FAILED in 3s
5 actionable tasks: 5 executed

This happens on my Windows machine. I can successfully build the same project on my Linux machine.

I think wconfig.inplace parameter for resolvedClassPath.addAll(ProjectUtils.getClassPath(proj, wconfig.inplace, runtimeConfig)) in gretty/libs/gretty/src/main/groovy/org/akhikhl/gretty/StartBaseTask.groovy:216 is being passed as null.

Unfortunately setting,

gretty {
    httpPort = 8080
    inplace = true
}

doesn't help. I think this is a bug.

JDK10 testing/support

JDK10 has been released. This is a skeleton issue to track testing and support for Gretty and various containers which will support JDK10 (Jetty 9.4.9 is released and claims support).

Note that Travis support is pending.

Support All Dependencies Override In Project gradle.properties file

I have tried gretty 3.0.0-SNAPSHOT. But not supporting overide of following dependencies:
jetty7_version = 7.6.21.v20160908
jetty7_servlet_api_version = 2.5
jetty8_version = 8.1.22.v20160922
jetty8_servlet_api_version = 3.0.1
jetty9_version = 9.2.26.v20180806
jetty93_version = 9.3.24.v20180605
jetty94_version = 9.4.11.v20180605
jetty9_servlet_api_version = 3.1.0
tomcat85_version = 8.5.33
tomcat85_servlet_api_version = 3.1.0
tomcat9_version = 9.0.11
tomcat9_servlet_api_version = 4.0.0
asm_version = 7.0
groovy_version = 2.4.15
spock_version = 1.1-groovy-2.4
logback_version = 1.1.3
slf4j_version = 1.7.12
springBootVersion = 2.0.2.RELEASE
springLoadedVersion = 1.2.8.RELEASE
springVersion = 5.0.6.RELEASE

by gradle.properties of my project:. When I list following dependecies in my project gradle.properties file by:
jetty94_version = 9.4.14.v20181114
tomcat85_version = 8.5.35
tomcat9_version = 9.0.13
Its downloading the version listed in plugin instead of version listed by me. I ahve read in this stackflow post that overiding dependencies version are supported:
https://stackoverflow.com/questions/37339515/how-to-select-specific-jetty-version-in-gretty-plugin
And in plugin documentation at this url:
http://akhikhl.github.io/gretty-doc/Overriding-servlet-container-versions.html
So please add support for this dependency overide as well. The only alternative we have if we don't have this feature is to build plugin from source code overiding dependencies ourself and use it from
local maven repository.

Release 3.0.0

Issue to collect release 3.0.0 tasks and commentary.

TODO

See https://github.com/gretty-gradle-plugin/gretty/projects/1
Deprecate JDK7 #49
Deprecate Gradle 1.x support #47
Deprecate Jettty 7+8 #51
Spring Boot 2 #43
Groovy 2.x #40

Upgrade gradle-bintray-plugin once Gradle 4.8 compatibility achieved

Current version is 1.2. We should upgrade to something newer than 1.8 once bintray/gradle-bintray-plugin#234 is resolved.

JDK9 with Jetty 9.2 testAll error with AnnotationParser/asm

11:54:46 WARN  Failed startup of context o.a.g.JettyWebAppContext@78830d9a{/extraResourceBases,[file:/Users/bsrandal/git/gretty/integrationTests/extraResourceBases/build/inplaceWebapp/, file:/Users/bsrandal/git/gretty/integrationTests/extraResourceBases/extra1/, jar:file:/Users/bsrandal/.gradle/caches/modules-2/files-2.1/org.webjars/bootstrap/3.2.0/aadbf822539bc170014701382cff887094c4c3df/bootstrap-3.2.0.jar!/META-INF/resources, jar:file:/Users/bsrandal/.gradle/caches/modules-2/files-2.1/org.webjars/jquery/2.1.1/dd89e356066869550b5509c4370f995ad6698d9a/jquery-2.1.1.jar!/META-INF/resources],STARTING}
java.lang.RuntimeException: Error scanning file ExampleServlet.class
        at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:708) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:688) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:688) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:688) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:688) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:688) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.annotations.AnnotationParser.parse(AnnotationParser.java:824) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.annotations.AnnotationConfiguration$ParserTask.call(AnnotationConfiguration.java:164) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.annotations.AnnotationConfiguration$1.run(AnnotationConfiguration.java:549) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) ~[jetty-util-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) ~[jetty-util-9.2.22.v20170606.jar:9.2.22.v20170606]
        at java.base/java.lang.Thread.run(Thread.java:844) ~[na:na]
Caused by: java.lang.IllegalArgumentException: null
        at org.objectweb.asm.ClassReader.<init>(Unknown Source) ~[asm-5.0.3.jar:5.0.3]
        at org.objectweb.asm.ClassReader.<init>(Unknown Source) ~[asm-5.0.3.jar:5.0.3]
        at org.objectweb.asm.ClassReader.<init>(Unknown Source) ~[asm-5.0.3.jar:5.0.3]
        at org.eclipse.jetty.annotations.AnnotationParser.scanClass(AnnotationParser.java:973) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:702) ~[jetty-annotations-9.2.22.v20170606.jar:9.2.22.v20170606]
        ... 11 common frames omitted
11:54:46 INFO  Jetty 9.2.22.v20170606 started and listening on port 8080
11:54:46 INFO  extraResourceBases runs at:
11:54:46 INFO    http://localhost:8080/extraResourceBases

> Task :gretty-integrationTests:extraResourceBases:integrationTest_jetty9 
...

org.akhikhl.examples.gretty.hellogretty.ExtraResourceBasesSpec > should get expected static page FAILED
    org.spockframework.runtime.SpockComparisonFailure at ExtraResourceBasesSpec.groovy:25

org.akhikhl.examples.gretty.hellogretty.ExtraResourceBasesSpec > should get expected response from servlet FAILED
    org.spockframework.runtime.SpockComparisonFailure at ExtraResourceBasesSpec.groovy:33

org.akhikhl.examples.gretty.hellogretty.ExtraResourceBasesSpec > should get page from extra resource base FAILED
    org.spockframework.runtime.SpockComparisonFailure at ExtraResourceBasesSpec.groovy:41

3 tests completed, 3 failed

> Task :gretty-integrationTests:extraResourceBases:afterIntegrationTest_jetty9 
Server stopped.

This will possibly become another case of don't-bother-with-Jetty-9.2 with JDK9.

Edit actually this is also occurring with latest Jetty 9.4.8.v20171121 so not-so-simple.

Override, not merge, the default welcome-file-list of Tomcat

Usually (with standalone Tomcat) welcome-file-list of the application overriders welcome-file-list from TOMCAT_HOME/conf/web.xml.
With Gretty it happens so that in the end we have a union of default welcome files (index.html etc. inserted by DefaultWebXmlListener) and the application welcome files.

Those default welcome files are unwanted in our case and it would be nice to get rid of them.

I managed to do this by changing
TomcatServerConfigurer.groovy like this:

-      context.addLifecycleListener(new DefaultWebXmlListener())
+      context.addLifecycleListener(new DefaultWebXmlListener() {
+          @Override
+          public void lifecycleEvent(LifecycleEvent event) {
+            super.lifecycleEvent(event);
+            if (Lifecycle.BEFORE_START_EVENT.equals(event.getType())) {
+              context.setReplaceWelcomeFiles(true)
+            }
+          }
+      })

Gretty could have such feature, enabled even by default.

Remove Jetty 7+8 support

Proposed for 3.x (#50). See also #43 .

Exception running application with gretty

After setting up gretty with a minimal conifguration I tried to run it with the following command:

$webproject> gradle --refresh-dependencies clean appStartWar -Pproperty=value -Pproperty2=value2

After the various build tasks I have in my project, the ones of gretty start running and get the following exception:

org.akhikhl.gretty.JettyScannerManager$1@66196cfd failed on '[....]
org.gradle.tooling.GradleConnectionException: Could not execute build using Gradle installation 'C:\opt\gradle'.
        at org.gradle.tooling.internal.consumer.ExceptionTransformer.transform(ExceptionTransformer.java:55)
        at org.gradle.tooling.internal.consumer.ExceptionTransformer.transform(ExceptionTransformer.java:29)
        at org.gradle.tooling.internal.consumer.ResultHandlerAdapter.onFailure(ResultHandlerAdapter.java:41)
        at org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerAction
Executor$1$1.run(DefaultAsyncConsumerActionExecutor.java:57)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
        at java.lang.Thread.run(Thread.java:745)
        at org.gradle.tooling.internal.consumer.BlockingResultHandler.getResult(BlockingResultHandler.java:46)
        at org.gradle.tooling.internal.consumer.DefaultBuildLauncher.run(DefaultBuildLauncher.java:77)
        at org.gradle.tooling.BuildLauncher$run.call(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
        at org.akhikhl.gretty.scanner.BaseScannerManager$_scanFilesChanged_closure6.doCall(BaseScannerManager.groovy:227)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
        at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
        at groovy.lang.Closure.call(Closure.java:414)
        at org.codehaus.groovy.runtime.DefaultGroovyMethods.callClosureForMapEntry(DefaultGroovyMethods.java:5276)
        at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:2117)
        at org.codehaus.groovy.runtime.dgm$164.invoke(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:274)
        at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
        at org.akhikhl.gretty.scanner.BaseScannerManager.scanFilesChanged(BaseScannerManager.groovy:220)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1213)
        at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:82)
        at org.akhikhl.gretty.JettyScannerManager.this$dist$invoke$2(JettyScannerManager.groovy)
        at org.akhikhl.gretty.JettyScannerManager$1.methodMissing(JettyScannerManager.groovy)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
        at groovy.lang.MetaClassImpl.invokeMissingMethod(MetaClassImpl.java:939)
        at groovy.lang.MetaClassImpl.invokePropertyOrMissing(MetaClassImpl.java:1262)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1215)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
        at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:69)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:52)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:166)
        at org.akhikhl.gretty.JettyScannerManager$1.filesChanged(JettyScannerManager.groovy:33)
        at org.eclipse.jetty.util.Scanner.reportBulkChanges(Scanner.java:691)
        at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:551)
        at org.eclipse.jetty.util.Scanner.scan(Scanner.java:403)
        at org.eclipse.jetty.util.Scanner$1.run(Scanner.java:353)
        at java.util.TimerThread.mainLoop(Timer.java:555)
        at java.util.TimerThread.run(Timer.java:505)
Caused by: org.gradle.api.GradleException: Unable to start the daemon process.
This problem might be caused by incorrect configuration of the daemon.
For example, an unrecognized jvm option is used.
Please refer to the user guide chapter on the daemon at https://docs.gradle.org/4.4/userguide/gradle_daemon.html
Please read the following process output to find out more:
-----------------------
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=4g; support was removed in 8.0
ERROR: transport error 202: bind failed: Address already in use
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [debugInit.c:750]

        at org.gradle.launcher.daemon.bootstrap.DaemonGreeter.parseDaemonOutput(DaemonGreeter.java:34)
        at org.gradle.launcher.daemon.client.DefaultDaemonStarter.startProcess(DefaultDaemonStarter.java:152)
        at org.gradle.launcher.daemon.client.DefaultDaemonStarter.startDaemon(DefaultDaemonStarter.java:135)
        at org.gradle.launcher.daemon.client.DefaultDaemonConnector.doStartDaemon(DefaultDaemonConnector.java:210)
        at org.gradle.launcher.daemon.client.DefaultDaemonConnector.startDaemon(DefaultDaemonConnector.java:204)
        at org.gradle.launcher.daemon.client.DefaultDaemonConnector.connect(DefaultDaemonConnector.java:128)
        at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:138)
        at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:92)
        at org.gradle.tooling.internal.provider.DaemonBuildActionExecuter.execute(DaemonBuildActionExecuter.java:60)
        at org.gradle.tooling.internal.provider.DaemonBuildActionExecuter.execute(DaemonBuildActionExecuter.java:41)
        at org.gradle.tooling.internal.provider.LoggingBridgingBuildActionExecuter.execute(LoggingBridgingBuildActionExecuter.java:60)
        at org.gradle.tooling.internal.provider.LoggingBridgingBuildActionExecuter.execute(LoggingBridgingBuildActionExecuter.java:34)
        at org.gradle.tooling.internal.provider.ProviderConnection.run(ProviderConnection.java:156)
        at org.gradle.tooling.internal.provider.ProviderConnection.run(ProviderConnection.java:122)
        at org.gradle.tooling.internal.provider.DefaultConnection.getModel(DefaultConnection.java:204)
        at org.gradle.tooling.internal.consumer.connection.CancellableModelBuilderBackedModelProducer.produceModel(CancellableModelBuilderBackedModelProducer.java:53)
        at org.gradle.tooling.internal.consumer.connection.PluginClasspathInjectionSupportedCheckModelProducer.produceModel(PluginClasspathInjectionSupportedCheckModelProducer.java:41)
        at org.gradle.tooling.internal.consumer.connection.AbstractConsumerConnection.run(AbstractConsumerConnection.java:58)
        at org.gradle.tooling.internal.consumer.connection.ParameterValidatingConsumerConnection.run(ParameterValidatingConsumerConnection.java:46)
        at org.gradle.tooling.internal.consumer.DefaultBuildLauncher$1.run(DefaultBuildLauncher.java:89)
        at org.gradle.tooling.internal.consumer.DefaultBuildLauncher$1.run(DefaultBuildLauncher.java:83)
        at org.gradle.tooling.internal.consumer.connection.LazyConsumerActionExecutor.run(LazyConsumerActionExecutor.java:84)
        at org.gradle.tooling.internal.consumer.connection.CancellableConsumerActionExecutor.run(CancellableConsumerActionExecutor.java:45)
        at org.gradle.tooling.internal.consumer.connection.ProgressLoggingConsumerActionExecutor.run(ProgressLoggingConsumerActionExecutor.java:58)
        at org.gradle.tooling.internal.consumer.connection.RethrowingErrorsConsumerActionExecutor.run(RethrowingErrorsConsumerActionExecutor.java:38)
        at org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerActionExecutor$1$1.run(DefaultAsyncConsumerActionExecutor.java:55)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
        at java.lang.Thread.run(Thread.java:745)Error: Could not find or load main class org.akhikhl.gretty.Runner
Exception in thread "Thread-32" org.gradle.process.internal.ExecException: Process 'command 'C:\Program Files\Java\jdk1.8.0_121\bin\java.exe'' finished with non-zero exit value 1
        at org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:382)
        at org.gradle.process.internal.DefaultJavaExecAction.execute(DefaultJavaExecAction.java:31)
        at org.gradle.api.internal.file.DefaultFileOperations.javaexec(DefaultFileOperations.java:182)
        at org.gradle.api.internal.project.DefaultProject.javaexec(DefaultProject.java:1076)
        at org.gradle.api.internal.project.DefaultProject.javaexec(DefaultProject.java:1071)
        at org.gradle.api.Project$javaexec$8.call(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
        at org.akhikhl.gretty.DefaultLauncher.javaExec(DefaultLauncher.groovy:89)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
        at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:384)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
        at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:69)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:52)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:166)
        at org.akhikhl.gretty.LauncherBase$_launchThread_closure4.doCall(LauncherBase.groovy:256)
        at org.akhikhl.gretty.LauncherBase$_launchThread_closure4.doCall(LauncherBase.groovy)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
        at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
        at groovy.lang.Closure.call(Closure.java:414)
        at groovy.lang.Closure.call(Closure.java:408)
        at groovy.lang.Closure.run(Closure.java:495)

The problem I see here is this line:
Error: Could not find or load main class org.akhikhl.gretty.Runner

My configuration

...
apply plugin: 'war'
apply from: 'https://raw.github.com/gretty-gradle-plugin/gretty/master/pluginScripts/gretty.plugin'
...

gretty {
	httpPort = 9091
}

Has anyone had this issue and how can it be solved?

Reinstate Jetty 9.3 + 9.4 integration tests

These have been disabled since before the fork. There's a comment about problems with authentication/login (test helloGrettySecure and a farm test) and I've been doing a little work on that. There will probably be other issues.

Obviously important for integration-tests to run on latest/default Jetty 9.4 at a minimum. Currently Jetty 9.2 is being tested.

JDK9 cannot complete testAll: Jasper Source option 1.5 is no longer supported. Use 1.6 or later.

Once you get past the issue in #13, running testAll with JDK9 the next problem encountered is:

> Task :gretty-integrationTests:extraResourceBases:integrationTest_jetty7 
...
Mar. 06, 2018 8:35:15 AM org.apache.jasper.compiler.Compiler generateClass
SEVERE: Error compiling file: /Users/bsrandal/git/gretty/integrationTests/extraResourceBases/build/serverBaseDir_jetty7/webapps-exploded/extraResourceBases/jsp/org/apache/jsp/index_html.java
08:35:15 WARN  
org.apache.jasper.JasperException: PWC6033: Error in Javac compilation for JSP

PWC6199: Generated servlet error:
Source option 1.5 is no longer supported. Use 1.6 or later.

PWC6199: Generated servlet error:
Target option 1.5 is no longer supported. Use 1.6 or later.


        at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:126) ~[org.apache.jasper.glassfish-2.1.0.v201110031002.jar:na]
        at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:296) ~[org.apache.jasper.glassfish-2.1.0.v201110031002.jar:na]
        at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:372) ~[org.apache.jasper.glassfish-2.1.0.v201110031002.jar:na]
        at org.apache.jasper.compiler.Compiler.compile(Compiler.java:433) ~[org.apache.jasper.glassfish-2.1.0.v201110031002.jar:na]
        at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:608) ~[org.apache.jasper.glassfish-2.1.0.v201110031002.jar:na]
        at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374) ~[org.apache.jasper.glassfish-2.1.0.v201110031002.jar:na]
        at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:476) ~[org.apache.jasper.glassfish-2.1.0.v201110031002.jar:na]
        at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:366) ~[org.apache.jasper.glassfish-2.1.0.v201110031002.jar:na]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) ~[servlet-api-2.5.jar:2.5]
        at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:652) ~[jetty-servlet-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1317) ~[jetty-servlet-7.6.16.v20140903.jar:7.6.16.v20140903]
        at javax.servlet.FilterChain$doFilter.call(Unknown Source) ~[na:na]
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48) ~[groovy-2.4.13.jar:2.4.13]
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113) ~[groovy-2.4.13.jar:2.4.13]
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:133) ~[groovy-2.4.13.jar:2.4.13]
        at org.akhikhl.gretty.RedirectFilter.doFilter(RedirectFilter.groovy:123) ~[gretty-filter-2.0.1-20180305.213359-2.jar:na]
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1288) ~[jetty-servlet-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:443) [jetty-servlet-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:556) [jetty-security-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1044) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:372) [jetty-servlet-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:189) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:978) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.Server.handle(Server.java:369) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:486) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:933) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:995) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) [jetty-http-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) [jetty-http-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) [jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) [jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
        at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) [jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
        at java.base/java.lang.Thread.run(Thread.java:844) [na:na]

Appears that some source/target-directives will be needed if possible for Jetty7 tests, or they will need to be excluded from JDK9 test-runs.

systemProperty/systemProperties and jvmArg(s) apply to pre-container Runner, can cause Groovy side-effects

The gretty extension allows the definition of jvmArg/jvmArgs and systemProperty/systemProperties (undocumented) which will be applied to the launched servlet-container. These are applied via the JavaExec which launches (in a separate JVM) the Gretty Runner which wraps, starts and monitors that servlet-container.

An issue can arise where either of these are used in a way that interacts with code in the Runner which executes prior to the embedded servlet-container launch. An example of this is shown in this stack-trace as highlighted in akhikhl#412 :

gretty {
  ...
  systemProperty 'java.util.logging.manager', 'org.apache.logging.log4j.jul.LogManager'
}

Could not load Logmanager "org.apache.logging.log4j.jul.LogManager"
java.lang.ClassNotFoundException: org.apache.logging.log4j.jul.LogManager
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
        at java.logging/java.util.logging.LogManager$1.run(LogManager.java:239)
        at java.logging/java.util.logging.LogManager$1.run(LogManager.java:223)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.logging/java.util.logging.LogManager.<clinit>(LogManager.java:223)
        at java.logging/java.util.logging.Logger.demandLogger(Logger.java:648)
        at java.logging/java.util.logging.Logger.getLogger(Logger.java:717)
        at java.logging/java.util.logging.Logger.getLogger(Logger.java:701)
        at org.codehaus.groovy.runtime.DefaultGroovyMethodsSupport.<clinit>(DefaultGroovyMethodsSupport.java:37)
        at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:97)
        at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:74)
        at groovy.lang.GroovySystem.<clinit>(GroovySystem.java:36)
        at org.codehaus.groovy.runtime.InvokerHelper.<clinit>(InvokerHelper.java:66)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallConstructorSite(CallSiteArray.java:87)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:60)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:235)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:239)
        at org.akhikhl.gretty.Runner.main(Runner.groovy:36)

In this case the project also has:

dependencies {
    compile group: 'org.apache.logging.log4j', name: 'log4j-api', version: '2.8'
    compile group: 'org.apache.logging.log4j', name: 'log4j-core', version: '2.8'
    compile group: 'org.apache.logging.log4j', name: 'log4j-web', version: '2.8'
    compile group: 'org.apache.logging.log4j', name: 'log4j-jul', version: '2.8'
}

The systemProperty 'java.util.logging.manager', 'org.apache.logging.log4j.jul.LogManager' requests JUL to be configured with a specific manager, which will eventually be on the container classpath, but is only on the classpath for the execution of the embedded container via its configured classloader. The above stacktrace shows a Groovy runtime init problem, since it sees the JVM arg too, but does not have access to the matching class.

One potential solution I can think of for this is to split the meaning of jvmArgs and systemProperties. For JavaExec and currently also for Gretty, systemProperties can be thought of as a shortcut to jvmArgs with -Dname=value. It might be possible to change the meaning of systemProperties, pass it as an argument rather than a JVM-argument, then use embedded container support to apply it. Some versions of Jetty at least support this, Tomcat I would need to check.

I don't expect that the meaning of jvmArgs could or should be changed - it would still apply to the entire Runner launch, so if you needed sysprops to only apply once the container is launched, you would need to use systemProperties.

Any feedback on the above idea is welcome.

getFreeRandomPort() should work for httpsPort

Doing

gretty {
    httpPort = getRandomFreePort()
}

is super-convenient for integration tests.

Is there any reason that it is not supported for HTTPS?

For example, in TomcatServerConfigurer, it checks the httpPort property, but not the httpsPort property.

Not working with Java 11 selecting Jetty9.4 as servlet container

On running it with Java 11 and selecting jetty9.4 asservlet coontainer we end with following stack trace:
java.lang.RuntimeException: Error scanning file /home/ankur/Development/projects/gradle-web/build/classes/java/main/HelloWorldServlet.class
at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:743) ~[jetty-annotations-9.4.9.v20180320.jar:9.4.9.v20180320]
at org.eclipse.jetty.annotations.AnnotationParser.parse(AnnotationParser.java:829) ~[jetty-annotations-9.4.9.v20180320.jar:9.4.9.v20180320]
at org.eclipse.jetty.annotations.AnnotationConfiguration$ParserTask.call(AnnotationConfiguration.java:163) ~[jetty-annotations-9.4.9.v20180320.jar:9.4.9.v20180320]
at org.eclipse.jetty.annotations.AnnotationConfiguration$1.run(AnnotationConfiguration.java:471) ~[jetty-annotations-9.4.9.v20180320.jar:9.4.9.v20180320]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:754) ~[jetty-util-9.4.9.v20180320.jar:9.4.9.v20180320]
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:672) ~[jetty-util-9.4.9.v20180320.jar:9.4.9.v20180320]
at java.base/java.lang.Thread.run(Thread.java:834) ~[na:na]
Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 55
at org.objectweb.asm.ClassReader.(ClassReader.java:166) ~[asm-6.1.1.jar:na]
at org.objectweb.asm.ClassReader.(ClassReader.java:148) ~[asm-6.1.1.jar:na]
at org.objectweb.asm.ClassReader.(ClassReader.java:136) ~[asm-6.1.1.jar:na]
at org.objectweb.asm.ClassReader.(ClassReader.java:237) ~[asm-6.1.1.jar:na]
at org.eclipse.jetty.annotations.AnnotationParser.scanClass(AnnotationParser.java:932) ~[jetty-annotations-9.4.9.v20180320.jar:9.4.9.v20180320]
at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:737) ~[jetty-annotations-9.4.9.v20180320.jar:9.4.9.v20180320]
... 6 common frames omitted

Clean up TomcatServerConfigurer in gretty-runner-tomcat9

TomcatServerConfigurer in gretty-runner-tomcat9 basically overwrites TomcatServerConfigurer from gretty-runner-tomcat on the classpath, with two lines of change.

Try to that more configurable instead of copypasting code.

Ref. #26 (comment)

Task appRun doesn't deploy class files to inplaceWebapp

I'm just tinkering around with Java, groovy, gradle and jetty/gretty.

My little sample app has one java class, one groovy class and an index.xhtml (JSF).

If I run the appRun task, my app doesn't work, because gretty just copies the configuration files and index.xhtml to the inplaceWebApp directory:

build/inplaceWebapp/
build/inplaceWebapp/index.xhtml
build/inplaceWebapp/WEB-INF
build/inplaceWebapp/WEB-INF/web.xml
build/inplaceWebapp/WEB-INF/faces-config.xml
build/inplaceWebapp/META-INF

I couldn't help myself other than adding a sync task:

task sync(type: Sync) {
from "$sourceSets.main.java.outputDir"
from "$sourceSets.main.groovy.outputDir"
into "${project.buildDir}/inplaceWebapp/WEB-INF/classes"
}

project.afterEvaluate {
appRun.dependsOn sync
}

Now the inplaceWebapp folder also contains the class files:

build/inplaceWebapp/
build/inplaceWebapp/index.xhtml
build/inplaceWebapp/WEB-INF
build/inplaceWebapp/WEB-INF/web.xml
build/inplaceWebapp/WEB-INF/classes
build/inplaceWebapp/WEB-INF/classes/de
build/inplaceWebapp/WEB-INF/classes/de/dumischbaenger
build/inplaceWebapp/WEB-INF/classes/de/dumischbaenger/GroovyUserView.class
build/inplaceWebapp/WEB-INF/classes/de/dumischbaenger/UserView.class
build/inplaceWebapp/WEB-INF/faces-config.xml
build/inplaceWebapp/META-INF

I guess this job should be done by gretty, shouldn't it?

Unexpected behavior compared to legacy jetty plugin

(this is a cross-post of the original issue posted here)

We're in the process of migrating our projects from Gradle 3.x to 4.x and thus, migrating from the legacy jetty core-plugin to gretty as advertised by the Gradle folks. At first, gretty looks like a drop-in replacement for the legacy jetty plugin. However, we're seeing an unexpected change in behavior:

The way it used to work

We build jax-ws webservices with Metro. The way we deploy them is that we have a classic WEB-INF/web.xml file which declares a servlet of type com.sun.xml.ws.transport.http.servlet.WSServlet. This makes Metro look for a WEB-INF/sun-jaxws.xml file which in turn declares the WebService implementation classes and handler-chains. When we comment out the servlet declaration in web.xml, the whole Metro jax-ws isn't deployed anymore. It works that way in the legacy jetty plugin as well as in our own custom JettyLauncher class, which simply uses the programmatic Jetty API to configure and launch the container.

The way gretty behaves

In gretty, the jax-ws WebService seems to be deployed as soon as a WEB-INF/sun-jaxws.xml file and the Metro webservice runtime jar webservices-rt.jar are present in the war. It doesn't seem to be looking at the WEB-INF/web.xml file for that. When I declare a spring ContextLoaderListener in the web.xml, I see that the jax-ws WebService is deployed way before the Spring context is being initialized, so my guess is that gretty deploys anything it can find, regardless of whether there is a web.xml or not.

This behavior, however, isn't compatible with the legacy jetty plugin and our Jetty-API-based launcher. It doesn't seem to be on jetty's end however: I made sure I was using the same jetty version in our launcher and it turns out the exact same jetty version is behaving differently when used in our launcher class compared to gretty, so I'm assuming it must be something gretty does...

I built a simple project to demonstrate the change in behavior. It can be run with Gradle 3.x's jettyRun and with Gradle 4.x/Gretty's appRun tasks, just comment out the inappropriate section in build.gradle.
This project shows that while the Metro Servlet is commented out in web.xml, with Gradle 3.x, the WebService isn't instantiated, while with Gradle 4.x, it's the very first thing that happens.

gretty-org-test.zip

Can this be considered a bug? And if it's intentional behavior, could you explain what is causing the different behavior and how to make it backwards-compatible? (of course, we'd need the behavior which is compatible to our launcher class, used in production).

Release 2.2.0

Placeholder issue for Release 2.2.0 discussion and finalisation/release.

Done

#37 (implementation-scope dependencies)
#30 (Tomcat 8.5)

Defer to 3.x, possible backport

#40 Upgrade to Groovy 2.5 GA when final

Unrelated module's transitive dependency resolution affected in composite build

I have some weird behavior. I will also try to get a minimal project example together for reproducibility when I have time.

Context

gretty 2.2.0
Gradle 4.10-rc-3 with kotlin-dsl
using Intellij IDEA to import the Gradle project.
I'm trying to use gretty with the js module that is a kotlin multiplatform module. It is part of an app build included (a subproject of a multiproject included build) in a composite gradle project with the library it relies on.

Issue - Unrelated module composite dependency resolution affected

If I sync the project in the IDE (IDE is running task :wrapper) without the plugin applied, everything is normal (confirmed no dependency resolution issues lurking in debug output).

If I apply the gretty plugin to the js child project, gradle runs through everything fine, and then the IDE reports that it cannot resolve two modules that are transitive dependencies of the affected module. It also tries to change the dependencies to runtime dependencies (I'm not seeing any of this behavior on the actual js module where the gretty plugin was applied). The following facts I think are interesting with these results.

the affected module is a fellow child project of the js module (aka they both share the same multiproject root).
the affected module is the jvm project, and really shouldn't be touched at all (does this mean this is a side effect of some other bug? Possibly).
the transitive dependencies were supposed to be (and confirmed in debug output that they were) already substituted via composite build substitution (where gradle identifies modules and substitutes them for project dependencies).
the affected transitive dependencies, in the same sync, are also transitive dependencies of the js subproject, and resolved a-okay there.
I compared the output in the .idea/libraries directory of the run without gretty and the run with gretty applied in this way. Normally, the IDE will not generate library .xmls for local modules in a Composite build. With the gretty plugin applied, I can confirm that the IDE is the culprit for not being able to resolve, as it generates two .xmls for these particular transitive dependencies.