akhikhl / gretty

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

Gretty is a feature-rich gradle plugin for running web-apps on embedded servlet containers. It supports Jetty versions 7, 8 and 9, Tomcat versions 7 and 8, multiple web-apps and many more. It wraps servlet container functions as convenient Gradle tasks and configuration DSL.

A complete list of Gretty features is available in feature overview.

Where to start

If you are new with Gretty, try getting started page.

⭐ What's new

June 20, 2017, Gretty 2.0.0 is out and immediately available at Bintray and Maven Central.

• Changes in this version:

• Compatibility with Gradle 4.0

• Support of Jetty 9.4 (issue #365).

• Now it's possible to override versions of Jetty, Tomcat and servlet API via properties in "gradle.properties" file (issue #330). See more information in chapter overriding servlet container versions in the documentation.

• All integration tests now run against Firefox 54.

• Fixed product generation.

• Support of Spring Framework 4.3.9 and Spring Boot 1.5.4.

• Dropped support of Java 6.

See also: complete list of changes for more information.

Documentation

You can learn about all Gretty features in online documentation.

System requirements

Gretty requires JDK7 or JDK8 and Gradle 1.10 or newer (Gradle 4.0 is highly recommended!).

Since version 2.0.0 Gretty no longer supports JDK6.

Availability

Gretty is an open-source project and is freely available in sources as well as in compiled form.

All releases of Gretty are available at Bintray

Copyright and License

Copyright 2013-2017 (c) Andrey Hihlovskiy, Timur Shakurov and contributors.

All versions, present and past, of Gretty are licensed under MIT license.

gretty's Issues

Ability to configure connectors

It would be nice to be able to customize the connector configuration. Ideally, this would include being able to choose which connectors are used (HTTP and/or HTTPS), as well as being able to customize all of the parameters for these connectors. See http://www.eclipse.org/jetty/documentation/current/configuring-connectors.html for reference.

Implement support of multiple web-apps per Jetty server

Problem: currently Gretty allows to start only single web-app on Jetty server. There is no way to start multiple web-apps on the same Jetty server.

Approaching solution of the problem with an example:

Lets imagine we have projects A, B and C. A is parent, B and C are children:

A
|-- B
+-- C

B and C are listed in "settings.gradle" of A, so that all 3 projects are included in project tree.
B and C are usual web-apps with standard structure. A is not a web-app.

Task:

We want to start web-apps B and C on the same Jetty server.

Solution:

B and C apply "gretty-plugin".

A applies new "gretty-aggregator-plugin" and contains special configuration:

gretty {
  webapp ':B'
  webapp ':C'
}

• webapp - function(String), optional, multiple
  
  Adds given subproject of the current project tree to the list of aggregated web-apps of this gretty configuration.

When we invoke gradle jettyRun in A directory, Gretty starts all webapps in the same order, as they are listed in gretty configuration.

When we invoke gradle jettyRun in B or C directory, Gretty starts respective single web-app.

loggingLevel problem

Hello.
I get DEBUG level logging in latest IDEA or terminal for jettyRun with:

gretty {
    loggingLevel='INFO'
    port=8081
    contextPath='/'
}

Any hints?
Thank you.

Integrating johnrengelman/shadow plugin

@timyates suggested a nice idea on using @johnrengelman's shadow plugin in Gretty. This would represent a web-application (or even bundle of web-applications) as a single jar.

If I understand it right, shadow plugin iterates the dependencies of the given project and repacks all dependency JARs and compiled classes and resources of the given project into one jar - shadow jar, typically named "${project.name}-all.jar"

I'll try to capture the related questions - with the purpose of constructive discussion.

1. How to deal with separation between servlet container code and webapp code? Gretty can generate so-called products, where servlet container is physically separated from webapp. Gretty passes resourceBase (either WAR or directory) and classpath (standard WEB-INF/lib, WEB-INF/classes) to a servlet container, so that it can initialize servlet context. How to preserve such separation with shadow plugin?
2. How to deal with multiple webapps? Gretty can assemble multiple webapps into product, each webapp gets separate resourceBase (either WAR or directory) and separate classpath (standard WEB-INF/lib, WEB-INF/classes). If we apply shadow plugin, how to separate webapps? How to pass resourceBase and classpaths to a servlet container?
3. Gretty supports servlet-container-specific files "server.xml", "context.xml", "jetty.xml", "jetty-env.xml". These files may contain references to files (for example, realm file or resourceBase for context). How to make them work with in-jar resource references instead of file paths? Will servlet containers understand in-jar resource references?
4. What simplifications can be applied to Gretty-enabled project and configuration (no-X, no-Y), so that we could say: "now we can simply apply shadow plugin and it will just work"?

All interested parties are invited to participate in the discussion.

Possible Bug in JettyScannerManager

Hi,

When changed .jar files are detected, this causes a RuntimeException (MissingPropertyException) due to missing property "absolutePath".

This happens on line 129:

      it.projectPath && project.project(it.projectPath).configurations.compile.dependencies.find { it.absolutePath == f }

I assume, that the object given to the Closure is not an instance of File, thus not having the absolutePath, but an instance of DefaultProjectDependency or something like this.

Maybe a call to ".resolve()" is missing behind ".dependencies"

Thanks in advance,
Tomas

jettyRun tasks automatically closes when run on IntelliJ IDEA

When running Gretty's jettyRun task from IntelliJ IDEA, it gets all the way to the line "Press any key to stop the jetty server.", and then the server just stops and prints out "Jetty server stopped.", even though I have not pressed any keys. Perhaps IntelliJ is automatically feeding the process input? In any event, could we configure the jettyRun task so that not just any input will cause it to stop?

fastReload seems not to work

First many thanks for all your work, it has helped us a lot with our Gradle and Jetty endeavour.

While trying to configure fastReload we have encountered some problems.

Given the following configuration:
fastReload(file('src/main/webapp/static'))

I get the following exception when starting my task:
:webapps:testapp:startJetty
Exception in thread "Thread-3" groovy.lang.MissingMethodException: No signature of method: org.akhikhl.gretty.FileResolver.resolveFile() is applicable for argument types: (org.gradle.api.internal.project.DefaultProject_Decorated, java.io.File, org.akhikhl.gretty.ProjectReloadUtils$_addReloadDirs_closure3) values: [project ':webapps:testapp', E:\projects\finance\sandbox\webapps\testapp\src\main\webapp\static, ...]
Possible solutions: resolveFile(org.gradle.api.Project, java.lang.Object)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:55)
at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:51)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
at org.akhikhl.gretty.ProjectReloadUtils.addReloadDirs(ProjectReloadUtils.groovy:52)
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:483)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite$StaticMetaMethodSiteNoUnwrapNoCoerce.invoke(StaticMetaMethodSite.java:148)
at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.callStatic(StaticMetaMethodSite.java:99)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:53)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:157)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:173)
at org.akhikhl.gretty.ProjectReloadUtils.getReloadSpecs(ProjectReloadUtils.groovy:82)
at org.akhikhl.gretty.ProjectReloadUtils$getReloadSpecs.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:128)
at org.akhikhl.gretty.JettyScannerManager.configureFastReload(JettyScannerManager.groovy:58)
at org.akhikhl.gretty.JettyScannerManager.startScanner(JettyScannerManager.groovy:218)
at org.akhikhl.gretty.ScannerManager$startScanner.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:112)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callSafe(AbstractCallSite.java:75)
at org.akhikhl.gretty.LauncherBase$_launchThread_closure3.doCall(LauncherBase.groovy:98)
at org.akhikhl.gretty.LauncherBase$_launchThread_closure3.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:483)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:909)
at groovy.lang.Closure.call(Closure.java:423)
at groovy.lang.Closure.call(Closure.java:417)
at groovy.lang.Closure.run(Closure.java:504)
at java.lang.Thread.run(Thread.java:745)

I have also tried:
fastReload(['baseDir1' : 'src/main/webapp/static', 'excludesPattern':'dynamic/*', 'pattern':''])

with the expected outcome:
:webapps:testapp:startJetty
Unknown reload property: baseDir1
Reload property baseDir is not specified.
Enabling hot deployment with interval of 1 second(s)

With fastReload(['baseDir' : 'src/main/webapp/static', 'excludesPattern':'dynamic/*', 'pattern':'']) I get the same exception from above. Same goes for:
fastReload(['baseDir' : 'src/main/webapp/static'])
and other combinations.

I try to achieve the same like #40 but in the area of fast reload. Once #40 is closed, everything will be taken care of.

gretty-farm plugin throws IllegalStateException: zip file closed

When defining a farm extension with two or more webapps, it will deploy the first webapp just fine, but then it will throw an IllegalStateException for the rest of the webapps.

2014-05-23 11:54:34.320 WARN - Failed startup of context o.e.j.w.WebAppContext@44a02b9c{/webshop-car,file:/C:/workspace/webshop/PI/webshop-car/build/inplaceWebapp/,null}
java.lang.IllegalStateException: zip file closed
at java.util.zip.ZipFile.ensureOpen(ZipFile.java:634) ~[na:1.7.0_55]
at java.util.zip.ZipFile.getInputStream(ZipFile.java:347) ~[na:1.7.0_55]
at java.util.jar.JarFile.getInputStream(JarFile.java:409) ~[na:1.7.0_55]
at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:162) ~[na:1.7.0_55]
at org.eclipse.jetty.util.resource.URLResource.getInputStream(URLResource.java:219) ~[jetty-util-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jetty.util.resource.JarResource.getInputStream(JarResource.java:121) ~[jetty-util-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jetty.webapp.Descriptor.parse(Descriptor.java:65) ~[jetty-webapp-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jetty.webapp.WebDescriptor.parse(WebDescriptor.java:148) ~[jetty-webapp-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jetty.webapp.FragmentDescriptor.parse(FragmentDescriptor.java:64) ~[jetty-webapp-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jetty.webapp.MetaData.addFragment(MetaData.java:248) ~[jetty-webapp-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jetty.webapp.FragmentConfiguration.findWebFragments(FragmentConfiguration.java:84) ~[jetty-webapp-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jetty.webapp.FragmentConfiguration.preConfigure(FragmentConfiguration.java:44) ~[jetty-webapp-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jetty.webapp.WebAppContext.preConfigure(WebAppContext.java:454) ~[jetty-webapp-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:490) ~[jetty-webapp-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69) [jetty-util-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jettyomponent.ContainerLifeCycle.start(ContainerLifeCycle.java:117) [jetty-util-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:99) [jetty-util-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:60) [jetty-server-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:154) [jetty-server-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69) [jetty-util-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:117) [jetty-util-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jetty.server.Server.start(Server.java:355) [jetty-server-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:99) [jetty-util-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:60) [jetty-server-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jetty.server.Server.doStart(Server.java:324) [jetty-server-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69) [jetty-util-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.eclipse.jetty.util.component.LifeCycle$start.call(Unknown Source) [jetty-util-9.1.0.v20131115.jar:9.1.0.v20131115]
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42) [groovy-all-1.8.6.jar:1.8.6]
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108) [groovy-all-1.8.6.jar:1.8.6]
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:112) [groovy-all-1.8.6.jar:1.8.6]
at org.akhikhl.gretty.RunnerBase.startServer(RunnerBase.groovy:82) [gretty-helper-com0.19.jar:na]
at org.akhikhl.gretty.RunnerBase$startServer.call(Unknown Source) [gretty-helper-commons-0.0.19.jar:na]
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42) [groovy-all-1.8.6.jar:1.8.6]
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108) [groovy-all-1.8.6.jar:1.8.6]
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:112) [groovy-all-1.8.6.jar:1.8.6]
at org.akhikhl.gretty.RunnerThread.run(RunnerThread.groovy:28) [gretty-helper-commons-0.0.19.jar:na]

../build/inplaceWebapp - FileNotFound exception

Do have have a hint what the problem is in my case? I configured my WebApp without and WEB-INF folder using ServletAPI 3.0.

Exception in thread "main" java.io.FileNotFoundException: /home/brian/workspace/news-fetcher/build/inplaceWebapp (Datei oder Verzeichnis nicht gefunden)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:220)
at java.util.zip.ZipFile.(ZipFile.java:150)
at java.util.jar.JarFile.(JarFile.java:166)
at java.util.jar.JarFile.(JarFile.java:130)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:77)
at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:102)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:57)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:182)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:190)
at org.akhikhl.gretty.JettyServerConfigurer.resolveContextFile(JettyServerConfigurer.groovy:123)
at org.akhikhl.gretty.JettyServerConfigurer$resolveContextFile$1.callCurrent(Unknown Source)

Is there anyway to add more dependencies to the plugin?

I wanted to enable annotations that comes with Servelet 3.0, from jetty website it can be done as instructed here http://www.eclipse.org/jetty/documentation/current/using-annotations-embedded.html.
I added the dependencies as below to my build script:

buildscript {

repositories {
mavenLocal()
mavenCentral()
maven {
url "http://maven.ow2.org/maven2/"
}
}
dependencies {
classpath 'org.eclipse.jetty:jetty-annotations:9.1.0.v20131115',
'org.eclipse.jetty:jetty-plus:9.1.0.v20131115',
'asm:asm:3.3.1',
'org.akhikhl.gretty:gretty9-plugin:0.0.8'
}
}
if (!project.plugins.findPlugin(org.akhikhl.gretty9.GrettyPlugin))
project.apply(plugin: org.akhikhl.gretty9.GrettyPlugin)

I get an error as below (ClassNotFound) - I am guessing the plugin is not using this classpath?, It would be nice to have a provision to add libraries to plugin classpath (if this is what causing the issue):
16:51:37.526 [QUIET] [system.out] 2014-01-19 16:51:37,523 1045 [main] INFO org.eclipse.jetty.server.Server - jetty-9.1.0.v20131115
16:51:37.554 [QUIET] [system.out] 2014-01-19 16:51:37,554 1076 [main] WARN o.e.jetty.webapp.WebAppContext - Failed startup of context o.e.j.w.WebAppContext@228376a9{/osu,file:/Users/gsetty/Perforce/perforce/gsetty/sandbox/gsetty/tools/hs2osu/OSU/osu/build/inplaceWebapp/,null}{/osu-1.0.war}
16:51:37.555 [QUIET] [system.out] java.lang.ClassNotFoundException: org.eclipse.jetty.plus.webapp.EnvConfiguration
16:51:37.555 [QUIET] [system.out] at java.net.URLClassLoader$1.run(URLClassLoader.java:366) ~[na:1.7.0_25]
16:51:37.573 [QUIET] [system.out] at java.net.URLClassLoader$1.run(URLClassLoader.java:355) ~[na:1.7.0_25]
16:51:37.573 [QUIET] [system.out] at java.security.AccessController.doPrivileged(Native Method) ~[na:1.7.0_25]
16:51:37.573 [QUIET] [system.out] at java.net.URLClassLoader.findClass(URLClassLoader.java:354) ~[na:1.7.0_25]

Add support for scanDir wildcards

I would like to include all submodules in the scanDir for auto rebuild/deploy. There's currently no way to do this. I have to specify each directory manually. This doesn't scale well.

Thanks in advance.

Run Integration Tests

I installed gretty and it works just fine. jettyStart and jettyStop are sufficient to start and stop a server with my war.

Beside that I use jUnit to test my stuff using a Client which needs a running server for integration tests.

I want to have one gradle task that starts a server, runs my tests and stopps the server. I tried the following:

task testIntegration << {
    tasks.jettyStart.execute()
    tasks.test.execute()
    tasks.jettyStop.execute()
}

However this does not work, because jettyStart starts the server but the task does not finish. It runs until jettyStop. Do you know how I can create a single task to do that?

Execution failed for task ':jettyStartDebug'. > No signature of method: java.util.LinkedHashSet.getAt() is applicable for argument types: (java.lang.Integer) values: [0] Possible solutions: getAt(java.lang.String), getAt(java.lang.String), putAt(java.lang.String, java.lang.Object), wait(), grep(), toSet()

Execution failed for task ':jettyStartDebug'. > No signature of method: java.util.LinkedHashSet.getAt() is applicable for argument types: (java.lang.Integer) values: [0] Possible solutions: getAt(java.lang.String), getAt(java.lang.String), putAt(java.lang.String, java.lang.Object), wait(), grep(), toSet()

allow to specify custom groovyVersion

like "toolVersion" in gradle PMD plugin, please allow to specify groovy version for gretty plugin. Or silently use groovy version already available in classpath.

Currently latest groovy is 2.3.6, gretty uses 2.3.3.

Then during "gradle appRun" exception occurs:

Caused by: groovy.lang.GroovyRuntimeException: Conflicting module versions. Module [groovy-all is loaded in version 2.3.3 and you are trying to load version 2.3.6

As a hint - possible cause can be in "about" gradle plugin:

Groovy [2.3.3], project ':bootstrap', plugin [com.github.goldin.plugins.gradle.about.AboutPlugin] is applied, added task 'about'.

Support fast reload without hot deployment

Hi,

it would be nice if fast reload would work without hot deployment.
Currently fast reload and hot deployment is attached to scan interval. When scan interval is set to 0, fast reload is not working. What I would love to see is basically immediate fast reload when a resource file was changed but no hot deployment or hot deployment only in very large intervals.

Hot deployment of changed JARs or classes tends to cause various troubles in a large web apps, they take some time and are not that often necessary.
On the other hand fast reload of templates, CSS, JS or other resource files is very often necessary, very fast and very efficient. I should be done immediately to reduce waiting. Having a scan interval for fast reload is in my eyes not very important. You usually want changes to be immediately available or at least in less then 2 seconds.

Thanks,
Gregor

gretty-farm plugin throws ExecException (jdk1.7.0_55)

When you run farmRun with the gretty-farm plugin, and there is no farm context, the plugin gives the following error. Translation: "Filnavnet eller filtypen er for lang" is Norwegian and means the file name or the file type is too long.

Exception in thread "Thread-38" org.gradle.process.internal.ExecException: A problem occurred starting process 'command 'C:\Program Files\Java\jdk1.7.0_55\bin\java.exe''
at org.gradle.process.internal.DefaultExecHandle.setEndStateInfo(DefaultExecHandle.java:196)
at org.gradle.process.internal.DefaultExecHandle.failed(DefaultExecHandle.java:325)
at org.gradle.process.internal.ExecHandleRunner.run(ExecHandleRunner.java:83)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:64)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: net.rubygrapefruit.platform.NativeException: Could not start 'C:\Program Files\Java\jdk1.7.0_55\bin\java.exe'
at net.rubygrapefruit.platform.internal.DefaultProcessLauncher.start(DefaultProcessLauncher.java:27)
at net.rubygrapefruit.platform.internal.WindowsProcessLauncher.start(WindowsProcessLauncher.java:22)
at net.rubygrapefruit.platform.internal.WrapperProcessLauncher.start(WrapperProcessLauncher.java:36)
at org.gradle.process.internal.ExecHandleRunner.run(ExecHandleRunner.java:65)
... 4 more
Caused by: java.io.IOException: Cannot run program "C:\Program Files\Java\jdk1.7.0_55\bin\java.exe" (in directory "C:\workspace\webshop\PI"): CreateProcess error=206, Filnavnet eller filtypen er for lang
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1041)
at net.rubygrapefruit.platform.internal.DefaultProcessLauncher.start(DefaultProcessLauncher.java:25)
... 7 more
Caused by: java.io.IOException: CreateProcess error=206, Filnavnet eller filtypen er for lang
at java.lang.ProcessImpl.create(Native Method)
at java.lang.ProcessImpl.(ProcessImpl.java:385)
at java.lang.ProcessImpl.start(ProcessImpl.java:136)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1022)
... 8 more

Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;"

I started having this problem after I updated from version 0.0.17 to 0.0.24. It seems that it started happening between version 0.0.23 and 0.0.24.

It seems to be some conflict between SLF4J versions from Jetty and the one I and Spring are using. I'm using only API version 1.7.6. You can see the whole code here: https://github.com/visola/bearprogrammer-examples/tree/master/gradle-integration-test

It's a sample that I've been working for a blog post that I'm writing. If you download that code and run jettyRun you should get the the error and the stack trace. I'm attaching a part of the log:

I'm running in Oracle Java 7.0.60:

------------------------------------------------------------
Gradle 1.10
------------------------------------------------------------

Build time:   2013-12-17 09:28:15 UTC
Build number: none
Revision:     36ced393628875ff15575fa03d16c1349ffe8bb6

Groovy:       1.8.6
Ant:          Apache Ant(TM) version 1.9.2 compiled on July 8 2013
Ivy:          2.2.0
JVM:          1.7.0_60 (Oracle Corporation 24.60-b09)
OS:           Mac OS X 10.9.3 x86_64

jvmArgs parameter not recognized

When configuring gretty like such:
gretty {
jvmArgs "-Xmx2048m"
}
and running the command: gradle jettyRun

The error message given is:
Could not find method jvmArgs() for arguments [-Xmx2048m] on root project 'myProject'

The jvmArgs is a feature described here: https://github.com/akhikhl/gretty/wiki/Gretty-configuration

This is needed because our webapp is generating OutOfMemoryExceptions.

jettyRunDebug doesn't work in 0.0.16 anymore

I use gretty in my web project with following configuration:

   gretty {
        reload = 'manual'
        contextPath = '/'
    }

After updating to 0.0.16 ./gradlew jettyRunDebug does not suspend to wait for debug port connection and seems like it does not open it at all. Downgrading to 0.0.15 fixes this issue.

Posibility to provide custom logback.xml or logback.groovy configuration

Hi,

I know it is possible to provide custom logback.xml file by placing it into overlay project. But I believe this is a little overhead to maintain another project for just one file.

Otherwise I really enjoy this graddle plugin. Really great job. Thanks.

Sending stop command hangs

At first I want to say that this plugin is great.It fixes a major problem I had with the gradle jetty plugin and since some versions it also eases use of jacoco coverage. This is very very great!
Thanks for creating and sharing it 👍

However, since two days I have a problem with it that I do not understand.
Suddenly the jask "jettyAfterIntegrationTest" causes problems on all of my three systems (I use two jenkins CI servers and and my local development machine).
I already reverted changes I made to my build.gradle and tried an older version of the plugin.
I also added jacoco { toolVersion: '+' } to my buildfile, but nothing helps.

The last few lines of the debug output from gradle looks like this:

22:13:47.121 [INFO] [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] :selenium (Thread[main,5,main]) completed. Took 29.934 s
ecs.
22:13:47.121 [INFO] [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] :jettyAfterIntegrationTest (Thread[main,5,main]) started
.
22:13:47.121 [LIFECYCLE] [class org.gradle.TaskExecutionLogger] :jettyAfterIntegrationTest
22:13:47.121 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Starting to execute task ':jettyAfterInte
grationTest'
22:13:47.122 [DEBUG] [org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter] Determining if task ':jettyAfterIntegrationTes
t' is up-to-date
22:13:47.122 [INFO] [org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter] Executing task ':jettyAfterIntegrationTest' (up
-to-date check took 0.0 secs) due to:
  Task has not declared any outputs.
22:13:47.122 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter] Executing actions for task ':jettyAfterInteg
rationTest'.
22:13:47.145 [DEBUG] [org.akhikhl.gretty.ProjectUtils] collectFilesInOutput filePattern: jetty.xml, result: []
22:13:47.145 [DEBUG] [org.akhikhl.gretty.ProjectUtils] Could not resolve file 'jetty.xml' in root project 'isochrone-web'
22:13:47.150 [DEBUG] [org.akhikhl.gretty.ProjectUtils] collectFilesInOutput filePattern: logback.groovy, result: []
22:13:47.150 [DEBUG] [org.akhikhl.gretty.ProjectUtils] Could not resolve file 'logback.groovy' in root project 'isochrone-web'
22:13:47.155 [DEBUG] [org.akhikhl.gretty.ProjectUtils] collectFilesInOutput filePattern: logback.xml, result: [/home/niko/git/isochron
e-web/build/resources/main/logback.xml]
22:13:47.155 [DEBUG] [org.akhikhl.gretty.JettyServiceTask] Sending command stop to port 9900

I tried to disable all firewalls and double-check network issues (I also changed the jetty service and statusPorts), but since I did not had to do this before and since all of my systems stopped working I guess that is not the problem...

Do you have any idea what's happening here and why my build stopped working after the integrationTests are run (BTW: they all pass)?

Jetty not starting anymore since gretty 1.1.0

Hello..

after I updated to gretty 1.1.0 the Jetty server is not starting anymore for me. It just stops during startup (no usual console log output), is not accepting requests and is not reacting to anything else than "Press any key to stop".

I juse gradle 2.0 and Java 1.8.0_11

Here is my gradle file:

apply plugin: 'java'
apply plugin: 'war'
apply plugin: 'org.akhikhl.gretty'

dependencies {
    compile project(':core')
    compile project(':web-admin')
    compile project(':web-website')

    // to see jetty sources in intellij
    testRuntime('org.eclipse.jetty:jetty-server:9.2.1.v20140609')
    testRuntime('org.eclipse.jetty:jetty-servlet:9.2.1.v20140609')
    testRuntime('org.eclipse.jetty:jetty-util:9.2.1.v20140609')
}

configurations {
    javaAgentSpringInstrument
}

dependencies {
    javaAgentSpringInstrument "org.springframework:spring-instrument:$springVer"

    // module continuation to prevent DWR errors
    gretty 'org.eclipse.jetty:jetty-continuation:9.2.1.v20140609'
}

war {
    archiveName = "${baseName}.${extension}"
    excludes = ['media']
    classpath = classpath.filter { File file ->
        !file.name.contains('-sources')
    }
}

gretty {
    // supported values:
    // 'jetty7', 'jetty8', 'jetty9', 'tomcat7', 'tomcat8'
    servletContainer = 'jetty9'
    contextPath = '/'
    fastReload = true
    scanInterval = 4
    contextConfigFile = 'src/test/resources/jetty-config/'+InetAddress.getLocalHost().getHostName()+'/jetty-env.xml'

    List<String> jvmArgsDebug = ["-Xdebug","-Xrunjdwp:transport=dt_socket,address=9999,server=y,suspend=n"]
    List<String> jvmArgsJmx = ["-Dcom.sun.management.jmxremote","-Dcom.sun.management.jmxremote.port=9998","-Dcom.sun.management.jmxremote.ssl=false","-Dcom.sun.management.jmxremote.authenticate=false"]
    //List<String> jvmArgsJit = ["-XX:+PrintCompilation","-XX:+UnlockDiagnosticVMOptions","-XX:+PrintInlining"]
    String jvmArgsSpringInstrument = "-javaagent:${configurations.javaAgentSpringInstrument.asPath}"
    jvmArgs = jvmArgsDebug + jvmArgsJmx /*+ jvmArgsJit*/ + [jvmArgsSpringInstrument, "-Xmx4096m"]
}

buildscript {
  repositories {
    mavenCentral()
    jcenter()
    //mavenLocal()
  }
  dependencies {
    classpath "org.akhikhl.gretty:gretty:+"
  }
}

I had to change "jettyEnvXmlFile" to "contextConfigFile" because I received the error:

No such property: jettyEnvXmlFile for class: org.akhikhl.gretty.GrettyExtension_Decorated

Not sure if this was right but it would be cool if the changelog could contain breaking changes like that though.

Switching back to version 1.0.0 with jettyEnvXmlFile makes everything work again immediately.

Thanks,
Gregor

Resources filtering in webapp

Hello, thanks for nice plugin ! My application has some props propagating into xml files on build. I use next script block:

war {
    // Enable filtering on all xml files in WEB-INF
    filesMatching('WEB-INF/*.xml', { FileCopyDetails fileDetails ->
        logger.error("File filtered: " + fileDetails.path)
        filter(ReplaceTokens, tokens: [
                "hosts"    : project.property("hosts"),
                "ports"    : project.property("ports"),
                "usernames": project.property("usernames"),
                "passwords": project.property("passwords")
        ])
    })
}

But when I'm using gretty jettyRun task, content inside inplaceWebapp directory is not filtered. I had a look at prepareInplaceWebAppFolder(Project) source code and found that it doesn't support any customization here. What can I do to hook this copy operation and enable flltering for it ?

Not support "web-fragment.xml" and "META-INF/resources" of servlet 3 ?

Hot Reload

Hi,

Is there a hot deploy / reload with Gretty, like "reload" and "scanIntervalSeconds" from gradle jetty plugin ?

Regards,

Yvonnick

Integrate / provide example of use with jacoco

One area where the existing jetty plugin is weak is when doing code coverage with jacoco. Do you know if gretty interoperates well with jacoco, and if so, maybe could you add an example showing this?

No signature of method: java.util.LinkedHashSet.getAt()

hi:
i use gretty ,but found a error
Execution failed for task ':appStartDebug'.

No signature of method: java.util.LinkedHashSet.getAt() is applicable for argument types: (java.lang.Integer) values: [0]
Possible solutions: getAt(java.lang.String), getAt(java.lang.String), putAt(java.lang.String, java.lang.Object), wait(), grep(), toSet()

my build.gradle:
apply plugin: 'war'
apply from: 'https://raw.github.com/akhikhl/gretty/master/pluginScripts/gretty.plugin'
tasks.withType(JavaCompile) {
options.encoding = "UTF-8"
options.debug = "on"
sourceCompatibility = 1.7
targetCompatibility = 1.7
}
gradle version:
gradle-1.12

.GroovyCastException Exception when using GrettyStartTask

Relevant gradle parts

...
import org.akhikhl.gretty.*

buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'org.akhikhl.gretty:gretty7-plugin:0.0.17'
}
}

apply from: 'https://raw.github.com/akhikhl/gretty/master/pluginScripts/gretty7-0.0.17.plugin'
....
task ('jettyRunForIntegrationTest', type: GrettyStartTask) {
integrationTest = true
}

Result

Exception in thread "Thread-3" org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'org.akhikhl.gretty7.ScannerManager@45b109c6' with class 'org.akhikhl.gretty7.ScannerManager' to class 'org.akhikhl.gretty.ScannerManagerBase'
at org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:360)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.castToType(ScriptBytecodeAdapter.java:599)
at org.akhikhl.gretty.GrettyStartTask.runJetty(GrettyStartTask.groovy:199)

servicePort is docummented as stopPort in README.md

"servicePort" is documented as "stopPort" in README.md, or to rephrase it:
stopPort does not exist in class GrettyPluginExtension as documented in README.md.

Implement custom tasks

By @bgaborg:
I'd like to create a custom task - named runFatJs - which compiles the js files in the webapp (frontend) right before creating the war (which will be deployed to jetty).
It's also important that this task should be a separate task from jettyRunWarDebug, because debugging without compiling the js app should be available too.

Debugger doesn't work on IntelliJ

I read the documentation here (http://akhikhl.github.io/gretty-doc/Debugger-support.html) about using the debugger. I'm using IntelliJ IDEA, but I can't get the debugger to work. I've tried using the debugger from both the command line and the gradle plugin, and I've tried both the jettyStartDebug and jettyRunDebug tasks. I also tried using the jettyStart task with the IntelliJ debug icon, but that didn't work either.

managedClassReload not effective

Hello,

we have a constellation of an application depending on multiple jars where these are project dependencies of the webapp project, which creates a war.

If changes occur to classes within the webapp module, gretty reloading mechanism works fine, and the server is reloaded, and changes become active.

However, if the changes occur inside the dependency project modules, the IDEs generate new .class files, but normally, no new .jar file is assembled. We assumed, that the configuration directive of "managedClassReload" is designed for this case, however it is not working.

Maybe we do something wrong? What is the right way of making gretty reload the service, should classes inside libraries other than the main webapp change?

If the answer is to assemble a .jar file to make gretty reload, this is not working. For this specific case, I will also open a new issue ticket.

Thanks in advance,
Tomas.

Jidea problem

Anyone had this error when importing gradle multimodule project into jidea?

Error:Cause: groovy.lang.MissingMethodException: No signature of method: org.gradle.api.internal.artifacts.ivyservice.resolutionstrategy.DefaultResolutionStrategy.eachDependency() is applicable for argument types: (org.akhikhl.gretty.SpringBootResolutionStrategy$_resolveDependencyVersions_closure3_closure4) values: [org.akhikhl.gretty.SpringBootResolutionStrategy$_resolveDependencyVersions_closure3_closure4@66663074]
Possible solutions: eachDependency(org.gradle.api.Action)
No signature of method: org.gradle.api.internal.artifacts.ivyservice.resolutionstrategy.DefaultResolutionStrategy.eachDependency() is applicable for argument types: (org.akhikhl.gretty.SpringBootResolutionStrategy$_resolveDependencyVersions_closure3_closure4) values: [org.akhikhl.gretty.SpringBootResolutionStrategy$_resolveDependencyVersions_closure3_closure4@66663074]
Possible solutions: eachDependency(org.gradle.api.Action)

Thank you.

Hot deployment - refreshing files without restaring (for specific files)

Hi.
I think that Gretty is a great project, but personally I would like to see one more feature.
Currently gretty scans "${projectDir}/src/main/webapp" for changes. But not all changes requires restarting. For CSS files, images and HTMLs (and possibly other kind of files) I would like only to refresh content of the "build/inplaceWebapp/" directory by synchronizing it with "${projectDir}/src/main/webapp".
What do you think about this feature?

JDK 6 causes exception when gretty tries to find files

Java version:
java version "1.6.0_45"
Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)

Exception:
Caused by: groovy.lang.MissingMethodException: No signature of method: java.io.File.toPath() is applicable for argument types: () values: []
Possible solutions: getPath(), length(), toURI(), toURL(), each(groovy.lang.Closure), with(groovy.lang.Closure)
at org.akhikhl.gretty.ProjectUtils$_collectFilesInOutput_closure3_closure11_closure12_closure13.doCall(ProjectUtils.groovy:81)
at org.akhikhl.gretty.ProjectUtils$_collectFilesInOutput_closure3_closure11_closure12.doCall(ProjectUtils.groovy:79)
at org.akhikhl.gretty.ProjectUtils$_collectFilesInOutput_closure3_closure11_closure12_closure13.doCall(ProjectUtils.groovy:87)
at org.akhikhl.gretty.ProjectUtils$_collectFilesInOutput_closure3_closure11_closure12.doCall(ProjectUtils.groovy:79)
at org.akhikhl.gretty.ProjectUtils$_collectFilesInOutput_closure3_closure11_closure12_closure13.doCall(ProjectUtils.groovy:87)
at org.akhikhl.gretty.ProjectUtils$_collectFilesInOutput_closure3_closure11_closure12.doCall(ProjectUtils.groovy:79)
at org.akhikhl.gretty.ProjectUtils$_collectFilesInOutput_closure3_closure11_closure12_closure13.doCall(ProjectUtils.groovy:87)
at org.akhikhl.gretty.ProjectUtils$_collectFilesInOutput_closure3_closure11_closure12.doCall(ProjectUtils.groovy:79)
at org.akhikhl.gretty.ProjectUtils$_collectFilesInOutput_closure3_closure11_closure12_closure13.doCall(ProjectUtils.groovy:87)
at org.akhikhl.gretty.ProjectUtils$_collectFilesInOutput_closure3_closure11_closure12.doCall(ProjectUtils.groovy:79)
at org.akhikhl.gretty.ProjectUtils$_collectFilesInOutput_closure3_closure11_closure12_closure13.doCall(ProjectUtils.groovy:87)
at org.akhikhl.gretty.ProjectUtils$_collectFilesInOutput_closure3_closure11_closure12.doCall(ProjectUtils.groovy:79)
at org.akhikhl.gretty.ProjectUtils$_collectFilesInOutput_closure3_closure11.doCall(ProjectUtils.groovy:90)
at org.akhikhl.gretty.ProjectUtils$_collectFilesInOutput_closure3.doCall(ProjectUtils.groovy:76)
at org.akhikhl.gretty.ProjectUtils.collectFilesInOutput(ProjectUtils.groovy:96)
at org.akhikhl.gretty.ProjectUtils$collectFilesInOutput.callStatic(Unknown Source)
at org.akhikhl.gretty.ProjectUtils.findFileInOutput(ProjectUtils.groovy:119)
at org.akhikhl.gretty.ProjectUtils$findFileInOutput.callStatic(Unknown Source)
at org.akhikhl.gretty.ProjectUtils.resolveFileProperty(ProjectUtils.groovy:315)
at org.akhikhl.gretty.ProjectUtils$resolveFileProperty.callStatic(Unknown Source)
at org.akhikhl.gretty.ProjectUtils.getJettyXmlFile(ProjectUtils.groovy:226)
at org.akhikhl.gretty.ProjectUtils$getJettyXmlFile.call(Unknown Source)
at org.akhikhl.gretty.GrettyStartTask.setupProperties(GrettyStartTask.groovy:264)
at org.akhikhl.gretty.GrettyBaseTask$_closure1.doCall(GrettyBaseTask.groovy:22)
at org.gradle.api.internal.AbstractTask$ClosureTaskAction.execute(AbstractTask.java:499)
at org.gradle.api.internal.AbstractTask$ClosureTaskAction.execute(AbstractTask.java:480)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:80)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:61)

JDK7 works fine

passing jvmArgs doesn't work

When configuring gretty like such:
gretty {
httpPort = 9090
host = "localhost"
jvmArgs = ['-Dtapestry.production-mode=false', '-Dtapestry.execution-mode=qa']
classPath = [integrationTestsClassPath]
integrationTestTask = 'integrationTests'
}
and running the command: gradle integrationTests
there are no system properties passed (eg. System.getProperty("tapestry.production-mode") returns null).

This happens only when using newest gretty plugin with classpath 'org.akhikhl.gretty:gretty:+'

Using older version with classpath 'org.akhikhl.gretty:gretty-plugin:+' everything is correct.

We are using java 1.7 and gradle 2.0

cant reset jvmargs

if jvmargs predefined in gretty closure then there is no way to reset args. Only possible to add new args.

Problem occures when one want to change some args, like changing db config

task('myBeforeIntegrationTest', type: JettyBeforeIntegrationTestTask) {
integrationTestTask 'integrationTest'
jvmArgs = [
"-DDB_URL=${project.ext.TEST_DB_URL}",
"-DDB_USER=${project.ext.TEST_DB_USER}",
"-DDB_PWD=${project.ext.TEST_DB_PWD}"
]

jetty 9 uses thrice more time to start then jetty 8

I do not know if it has to do anything with gretty plugin or jetty itself. When I run jetty 9 as a standalone server it starts almost instantly and deploys my app in about 10 seconds but when I run gradle appRun I have to wait at the step INFO - jetty-9.2.1.v20140609 for about 50 seconds. If I change to servletContainer = 'jetty8' the step only takes about 15 seconds. When I turn on debugging I can see endless messages like [DEBUG] [org.eclipse.jetty.util.Scanner] scan accepted /home/artyom/IdeaProjects/prj1/src/main/webapp/WEB-INF/... with different paths, so I think it is connected with scanning jetty performs. By any chance do you know why there is such a big difference between jetty 8 and jetty 9 and what I can be done about it?

Gretty should be able to specify and run additional war files from differrent sources (download, maven repo) along side the project

Gradle project myApp depends on webServiceApp.war. When running myApp, webServiceApp should also be running on the same app instance. To address this issue:

Option 1. dependency can be specified as a configuration pointing to the maven repo where webServiceApp is. Then a config option for gretty might specify additional war files to be deployed along side the project referencing that config
e.g.:

configurations{
       warDependency
}
dependencies{
       warDependency "edu.umich.med:webServiceApp:1.6@war"
}
gretty{
    otherWars = [configurations.warDependency.singleFile,....]
// Here there might be a config option that would let specify different context path for each war dependency.
}

Option 2. A download task can be specified to fetch war dependency into the destination where the project's war file will be. Then gretty start task may depend on fetch task and load all war files in that destination in addition to running the project

e.g.:

task downloadWarDependency(type: DownloadFileTask) {
    sourceUrl = 'https://myMavenRepoHost/nexus/content/repositories/public/edu/umich/med/webServiceApp/1.6/webServiceApp-1.6.war'
    target = file("${buildDir}/libs/webServiceApp.war")
}

class DownloadFileTask extends DefaultTask {
    @Input
    String sourceUrl

    @OutputFile
    File target

    @TaskAction
    void download() {
       ant.get(src: sourceUrl, dest: target)
    }

task('jettyRunWithCosign', type: GrettyStartTask) {
  dependsOn { [tasks.downloadWarDependency,tasks.prepareWarWebApp] }
// Here there might be a config option that would let specify different context path for each war dependency.
.......
}

Extension Documentation Missmatch

In the documentation, the extension property "jettyXmlFile" is documented as "jettyXml" and "jettyEnvXmlFile" is documented as "jettyEnvXml". I don't know if you want to update the documentation to match the implementation or vice versa. Personally, I would update the documentation because it is an easier change and "jettyXmlFile" is more descriptive than "jettyXml".

Could not find any version :)

So here's the exact error after adding
apply from: 'https://raw.github.com/akhikhl/gretty/master/pluginScripts/gretty.plugin'.

Could not resolve all dependencies for configuration 'classpath'.
Could not find any version that matches org.akhikhl.gretty:gretty:+.
Required by:
unspecified:unspecified:unspecified

Any ideas what's the problem?

A problem occurred evaluating script. > org.akhikhl.gretty.GrettyPlugin

Issue

When using:

apply from: 'https://raw.github.com/akhikhl/gretty/master/pluginScripts/gretty.plugin'

I get this error

FAILURE: Build failed with an exception.
* Where:
Script 'https://raw.github.com/akhikhl/gretty/master/pluginScripts/gretty.plugin'
* What went wrong:
A problem occurred evaluating script.
> org.akhikhl.gretty.GrettyPlugin

Running gradle with stacktrace:

Exception is:
org.gradle.api.GradleScriptException: A problem occurred evaluating script.
    at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:54)
    at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:177)
... truncated rest...
Caused by: java.lang.NoClassDefFoundError: org.akhikhl.gretty.GrettyPlugin
    at gretty_3cssub2t750vfivp1ij8sq9a1r.class$(https://raw.github.com/akhikhl/gretty/master/pluginScripts/gretty.plugin)
    at gretty_3cssub2t750vfivp1ij8sq9a1r.$get$$class$org$akhikhl$gretty$GrettyPlugin(https://raw.github.com/akhikhl/gretty/master/pluginScripts/gretty.plugin)
    at gretty_3cssub2t750vfivp1ij8sq9a1r.run(https://raw.github.com/akhikhl/gretty/master/pluginScripts/gretty.plugin:17)
    at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:52)
    ... 41 more

Environment

• Ubuntu 13.10
• java version "1.7.0_55"
• Gradle 1.11

Work around

I pasted in the script contents into my build file, commented out the 'if' block, then applied the 'gretty' plugin manually:

buildscript {
    repositories {
        jcenter()
    }

    dependencies {
        classpath 'org.akhikhl.gretty:gretty-plugin:+'
    }
}

repositories {
    jcenter()
}

project.apply plugin: 'war'

//if (!project.plugins.findPlugin(org.akhikhl.gretty.GrettyPlugin))
//    project.apply(plugin: org.akhikhl.gretty.GrettyPlugin)

apply plugin: 'gretty'

Jetty should not start if integration test task is up-to-date

I have this scenario and I'm trying to streamline my build so that it would not start jetty and run the integration tests if there's nothing new.
I've done it with the integration tests but now Jetty is starting either way. So my build still takes long starting Jetty even when it won't run the integration tests.
I guess the best approach for this would be to copy the inputs and outputs from the integration test task.

Multiple resourseBase support

In jetty-maven-plugin, multiple resourceBase are supported. I find that this is feature is not hard to implement in jetty because there is a class called org.eclipse.jetty.util.resource.ResourceCollection which implements Resource interface. For tomcat, I do not know whether it is hard to implement.

Running appRun or jettyRun in eclipse automatically stops

The system doesn't keep running. It just automatically stops. Running from the command line works fine.

I saw a similar issue was posted a while back regarding IntelliJ

How to specify jetty-env.xml

Hi I need to setup https along with http for jetty. Like to know how to setup this or specify additional jetty configurations (jetty-env.xml)

jvmArgs seems broken

After updating to 1.1.1 command gradle jettyRun invokes jetty without passing jvmArgs:

gretty {
  port = 8081
  jvmArgs = ['-Dcms.basedir=d:\\elwood\\my-repos\\scala-cms\\scala-cms\\consoleframework']
}

Syntax jvmArg 'arg' doesn't work too:

• What went wrong:
  A problem occurred evaluating root project 'webapp'.
  No such property: args for class: org.akhikhl.gretty.ServerConfig

Works if use plugin from https://raw.githubusercontent.com/akhikhl/gretty/master/pluginScripts/gretty-1.0.0.plugin.

No such property: absolutePath for class: java.lang.String error is thrown on jetty* build

Exception in thread "Thread-12" groovy.lang.MissingPropertyException: No such property: absolutePath for class: java.lang.String is thrown when building with any jetty* task.
Full stacktrace:
http://pastebin.com/kuspgtNm

Setting logbackConfigFile leads to an exception on appRun

Setting logbackConfigFile to any value leads to an exception:

Caused by: groovy.lang.MissingMethodException: No signature of method: java.util.LinkedHashSet.getAt() is applicable for argument types: (java.lang.Integer) values: [0]
Possible solutions: getAt(java.lang.String), getAt(java.lang.String), putAt(java.lang.String, java.lang.Object), wait(), grep(), toSet()
        at org.akhikhl.gretty.FileResolver.resolveSingleFile(FileResolver.groovy:96)
        at org.akhikhl.gretty.FileResolver$resolveSingleFile.call(Unknown Source)
        at org.akhikhl.gretty.ProjectUtils.resolveServerConfig(ProjectUtils.groovy:327)
        at org.akhikhl.gretty.ProjectUtils$resolveServerConfig.call(Unknown Source)
        at org.akhikhl.gretty.AppStartTask.getStartConfig(AppStartTask.groovy:42)
        at org.akhikhl.gretty.AppStartTask_Decorated.getStartConfig(Unknown Source)
        at org.akhikhl.gretty.StartBaseTask.getLauncherConfig(StartBaseTask.groovy:92)
        at org.akhikhl.gretty.StartBaseTask.action(StartBaseTask.groovy:35)
        at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:63)
        at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.doExecute(AnnotationProcessingTaskFactory.java:219)
        at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:212)
        at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:201)
        at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:533)
        at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:516)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:80)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:61)
        ... 46 more

Seems like a LinkedHashSet<File> does not support ordinal indexing.

Update

Actually this code path gets hit whenever logback.groovy is present, regardless whether it's specified in the gradle.properties or is just laying in src/main/resources.

Version 0.0.3 on your maven_repo

Hi,

Can you update your https://github.com/akhikhl/gretty/tree/master/maven_repo with version 0.0.3 (and update README file with the existing version) ?
Are you planned to send a version on maven central ?

Thanks a lot!