Grails › Grails - dev

WarExec plugin

Classic

List

Threaded

11 messages Options

DavidTinker

WarExec plugin

Guys can I please publish this plugin?

It is similar to the jetty-standalone plugin but is easier to use (no
need to run separate script), supports different environments, is
configurable via Config.groovy and doesn't double up the size of the
war file.

---------- Forwarded message ----------
From: David Tinker <[hidden email]>
Date: Thu, Jul 26, 2012 at 12:32 PM
Subject: New plugin WarExec for grails.org
To: [hidden email]

I would like to publish a plugin to grails.org:
https://github.com/davidtinker/war-exec

It makes Grails war files executable (java -jar myapp.war) by embedding Jetty.

My grails.org username is david.tinker.

Usage is simple:

BuildConfig.groovy:
plugins {
runtime ":war-exec:1.0.0"
...
}

$ grails dev war
$ java -jar target/com.brandseye.myapp.war

Thanks
David

--
http://twoogleplus.com/ Online service to cross-post tweets to Google+
http://engage.calibreapps.com/ Engage - Web based goal setting and
performance management

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

pledbrook

Re: WarExec plugin

> Guys can I please publish this plugin?

There was an email from Graeme hidden in the last thread about this
saying he'd approved it :)

> It is similar to the jetty-standalone plugin but is easier to use (no
> need to run separate script), supports different environments, is
> configurable via Config.groovy and doesn't double up the size of the
> war file.

I'll be frank and say I still don't like having two plugins. From what
I have read in the emails, it seems to me that the jetty-standalone
plugin should behave like war-exec.

In fact, looking at standalone, jetty-standalone, and war-exec, I'm
really struggling to see what the difference is. For the sanity of our
users, can I please ask yourself, Gert, and Burt to work out how many
plugins we need and whether some of them can be combined?

Thanks,

Peter

--
Peter Ledbrook
Developer Advocate
VMware

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Gert Wohlgemuth

Re: WarExec plugin

i suggested in the first thread to combine them, but at the same time
I do not care if mine is taken down for the sake of simplicity.

The main difference is:

jetty-standalone only include the required libs to run it as jetty if
called in a certain environment. Since quite often you still want to
deploy the same app to an existing application server and I like to
keep my wars small.

war-ex always includes the required libs and so makes the war file a
big bigger, but it's simpler to use and allows specific environmental
based configurations

same result, slightly different approach. Even the run script he used
for his jetty startup looks very similar to mine (which was based on
the official jetty example, so no surprise there)

g.

On Wed, Aug 15, 2012 at 8:38 AM, Peter Ledbrook <[hidden email]> wrote:

>> Guys can I please publish this plugin?
>
> There was an email from Graeme hidden in the last thread about this
> saying he'd approved it :)
>
>> It is similar to the jetty-standalone plugin but is easier to use (no
>> need to run separate script), supports different environments, is
>> configurable via Config.groovy and doesn't double up the size of the
>> war file.
>
> I'll be frank and say I still don't like having two plugins. From what
> I have read in the emails, it seems to me that the jetty-standalone
> plugin should behave like war-exec.
>
> In fact, looking at standalone, jetty-standalone, and war-exec, I'm
> really struggling to see what the difference is. For the sanity of our
> users, can I please ask yourself, Gert, and Burt to work out how many
> plugins we need and whether some of them can be combined?
>
> Thanks,
>
> Peter
>
> --
> Peter Ledbrook
> Developer Advocate
> VMware

--
------------------------------------------------------------
Lead Developer - Fiehnlab, UC Davis

gert wohlgemuth

work:
http://fiehnlab.ucdavis.edu/staff/wohlgemuth

phone:
530 665 9477

coding blog:
http://codingandmore.blogspot.com

linkedin:
http://www.linkedin.com/profile/view?id=28611299&trk=tab_pro

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

burtbeckwith

Re: WarExec plugin

I basically did combine them in the last release of the standalone plugin. I had to rework the way I was working with the Tomcat jar files to not cause classpath issues with a Tomcat plugin that used different versions, and once I did that I realized that it wouldn't be much work to support Jetty too, so I added that in 1.1.

It doesn't do what this plugin does, but I might add that too.

Burt

Gert Wohlgemuth wrote

i suggested in the first thread to combine them, but at the same time
I do not care if mine is taken down for the sake of simplicity.

The main difference is:

jetty-standalone only include the required libs to run it as jetty if
called in a certain environment. Since quite often you still want to
deploy the same app to an existing application server and I like to
keep my wars small.

war-ex always includes the required libs and so makes the war file a
big bigger, but it's simpler to use and allows specific environmental
based configurations

same result, slightly different approach. Even the run script he used
for his jetty startup looks very similar to mine (which was based on
the official jetty example, so no surprise there)

g.

On Wed, Aug 15, 2012 at 8:38 AM, Peter Ledbrook <[hidden email]> wrote:
>> Guys can I please publish this plugin?
>
> There was an email from Graeme hidden in the last thread about this
> saying he'd approved it :)
>
>> It is similar to the jetty-standalone plugin but is easier to use (no
>> need to run separate script), supports different environments, is
>> configurable via Config.groovy and doesn't double up the size of the
>> war file.
>
> I'll be frank and say I still don't like having two plugins. From what
> I have read in the emails, it seems to me that the jetty-standalone
> plugin should behave like war-exec.
>
> In fact, looking at standalone, jetty-standalone, and war-exec, I'm
> really struggling to see what the difference is. For the sanity of our
> users, can I please ask yourself, Gert, and Burt to work out how many
> plugins we need and whether some of them can be combined?
>
> Thanks,
>
> Peter
>
> --
> Peter Ledbrook
> Developer Advocate
> VMware

--
------------------------------------------------------------
Lead Developer - Fiehnlab, UC Davis

gert wohlgemuth

work:
http://fiehnlab.ucdavis.edu/staff/wohlgemuth

phone:
530 665 9477

coding blog:
http://codingandmore.blogspot.com

linkedin:
http://www.linkedin.com/profile/view?id=28611299&trk=tab_pro

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

pledbrook

Re: WarExec plugin

> I basically did combine them in the last release of the standalone plugin. I
> had to rework the way I was working with the Tomcat jar files to not cause
> classpath issues with a Tomcat plugin that used different versions, and once
> I did that I realized that it wouldn't be much work to support Jetty too, so
> I added that in 1.1.

So in effect, standalone with Jetty support does pretty much the same
as jetty-standalone? If so, Gert, do you mind if we deprecate your
plugin and point people at the standalone plugin?

As for war-exec, are there significant differences from the user's
perspective (ones that he or she cares about at least ;) )?

Thanks,

Peter

--
Peter Ledbrook
Developer Advocate
VMware

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Gert Wohlgemuth

Re: WarExec plugin

@peter no not at all. I'm always happy to use better alternatives
aslong as we don't reinvent the wheel to often

On Wed, Aug 15, 2012 at 9:24 AM, Peter Ledbrook <[hidden email]> wrote:

>> I basically did combine them in the last release of the standalone plugin. I
>> had to rework the way I was working with the Tomcat jar files to not cause
>> classpath issues with a Tomcat plugin that used different versions, and once
>> I did that I realized that it wouldn't be much work to support Jetty too, so
>> I added that in 1.1.
>
> So in effect, standalone with Jetty support does pretty much the same
> as jetty-standalone? If so, Gert, do you mind if we deprecate your
> plugin and point people at the standalone plugin?
>
> As for war-exec, are there significant differences from the user's
> perspective (ones that he or she cares about at least ;) )?
>
> Thanks,
>
> Peter
>
> --
> Peter Ledbrook
> Developer Advocate
> VMware
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

DavidTinker

Re: WarExec plugin

In reply to this post by pledbrook

> As for war-exec, are there significant differences from the user's
> perspective (ones that he or she cares about at least ;) )?

War-exec does a couple of nice things not supported by standalone:
- All wars are automatically executable just by adding this plugin to
the project, it couldn't be easier
- The server bind address, port, context path, threads, temp dir etc.
can all be configured in Config.groovy and overridden using system
properties
- The default port is the one from BuildConfig.groovy
(grails.server.port.http) if not set in Config.groovy
- The default dev context path is the same as used by "grails
run-app", production context path is "/"

With war-exec doing "grails dev war && java -jar target/myapp.war"
runs the app listening on the same port and context as "grails
run-app" making it very easy to do performance testing and so on.

I think executable war should be the standard way to package Java web
apps. It gives you much better control over the deployment
environment.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

burtbeckwith

Re: WarExec plugin

How have you deployed wars built this way in the past to "real" servers? It seems like it'd be wasteful to include all those Jetty jars if you're deploying to a non-Jetty server, and since you hard-code the Jetty version you'd be unlikely to be able to deploy to any other version of Jetty than the one the plugin uses.

Also - how is "grails dev war && java -jar target/myapp.war" different from "grails dev run-war"?

Burt

DavidTinker wrote

> As for war-exec, are there significant differences from the user's
> perspective (ones that he or she cares about at least ;) )?

War-exec does a couple of nice things not supported by standalone:
- All wars are automatically executable just by adding this plugin to
the project, it couldn't be easier
- The server bind address, port, context path, threads, temp dir etc.
can all be configured in Config.groovy and overridden using system
properties
- The default port is the one from BuildConfig.groovy
(grails.server.port.http) if not set in Config.groovy
- The default dev context path is the same as used by "grails
run-app", production context path is "/"

With war-exec doing "grails dev war && java -jar target/myapp.war"
runs the app listening on the same port and context as "grails
run-app" making it very easy to do performance testing and so on.

I think executable war should be the standard way to package Java web
apps. It gives you much better control over the deployment
environment.

DavidTinker

Re: WarExec plugin

We deploy our apps as executable wars so we never have to worry about
server xyz having the wrong version of Tomcat or Jetty installed. All
you need is the war and the server will be the same as in dev, test
and production. The war can still be deployed normally to a servlet
container but if thats what you want there is no reason to use
war-exec/standalone in the first place.

"grails dev run-war" runs using whatever version of Tomcat Grails is
using which may not be the same one used in production. This plugin
helps avoid these issues.

If an app wants to use a newer version of Jetty it just have
corresponding dependencies in BuildConfig.groovy.

On Wed, Aug 15, 2012 at 9:48 PM, burtbeckwith <[hidden email]> wrote:

> How have you deployed wars built this way in the past to "real" servers? It
> seems like it'd be wasteful to include all those Jetty jars if you're
> deploying to a non-Jetty server, and since you hard-code the Jetty version
> you'd be unlikely to be able to deploy to any other version of Jetty than
> the one the plugin uses.
>
> Also - how is "grails dev war && java -jar target/myapp.war" different from
> "grails dev run-war"?
>
> Burt
>
>
> DavidTinker wrote
>>
>>> As for war-exec, are there significant differences from the user's
>>> perspective (ones that he or she cares about at least ;) )?
>>
>> War-exec does a couple of nice things not supported by standalone:
>> - All wars are automatically executable just by adding this plugin to
>> the project, it couldn't be easier
>> - The server bind address, port, context path, threads, temp dir etc.
>> can all be configured in Config.groovy and overridden using system
>> properties
>> - The default port is the one from BuildConfig.groovy
>> (grails.server.port.http) if not set in Config.groovy
>> - The default dev context path is the same as used by "grails
>> run-app", production context path is "/"
>>
>> With war-exec doing "grails dev war && java -jar target/myapp.war"
>> runs the app listening on the same port and context as "grails
>> run-app" making it very easy to do performance testing and so on.
>>
>> I think executable war should be the standard way to package Java web
>> apps. It gives you much better control over the deployment
>> environment.
>>
>
>
>
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/WarExec-plugin-tp4633240p4633273.html
> Sent from the Grails - dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

--
http://twoogleplus.com/ Online service to cross-post tweets to Google+
http://engage.calibreapps.com/ Engage - Web based goal setting and
performance management

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

DavidTinker

Re: WarExec plugin

Can we not just publish war-exec and users can choose which one that
want to use?

On Thu, Aug 16, 2012 at 1:57 PM, David Tinker <[hidden email]> wrote:

> We deploy our apps as executable wars so we never have to worry about
> server xyz having the wrong version of Tomcat or Jetty installed. All
> you need is the war and the server will be the same as in dev, test
> and production. The war can still be deployed normally to a servlet
> container but if thats what you want there is no reason to use
> war-exec/standalone in the first place.
>
> "grails dev run-war" runs using whatever version of Tomcat Grails is
> using which may not be the same one used in production. This plugin
> helps avoid these issues.
>
> If an app wants to use a newer version of Jetty it just have
> corresponding dependencies in BuildConfig.groovy.
>
> On Wed, Aug 15, 2012 at 9:48 PM, burtbeckwith <[hidden email]> wrote:
>> How have you deployed wars built this way in the past to "real" servers? It
>> seems like it'd be wasteful to include all those Jetty jars if you're
>> deploying to a non-Jetty server, and since you hard-code the Jetty version
>> you'd be unlikely to be able to deploy to any other version of Jetty than
>> the one the plugin uses.
>>
>> Also - how is "grails dev war && java -jar target/myapp.war" different from
>> "grails dev run-war"?
>>
>> Burt
>>
>>
>> DavidTinker wrote
>>>
>>>> As for war-exec, are there significant differences from the user's
>>>> perspective (ones that he or she cares about at least ;) )?
>>>
>>> War-exec does a couple of nice things not supported by standalone:
>>> - All wars are automatically executable just by adding this plugin to
>>> the project, it couldn't be easier
>>> - The server bind address, port, context path, threads, temp dir etc.
>>> can all be configured in Config.groovy and overridden using system
>>> properties
>>> - The default port is the one from BuildConfig.groovy
>>> (grails.server.port.http) if not set in Config.groovy
>>> - The default dev context path is the same as used by "grails
>>> run-app", production context path is "/"
>>>
>>> With war-exec doing "grails dev war && java -jar target/myapp.war"
>>> runs the app listening on the same port and context as "grails
>>> run-app" making it very easy to do performance testing and so on.
>>>
>>> I think executable war should be the standard way to package Java web
>>> apps. It gives you much better control over the deployment
>>> environment.
>>>
>>
>>
>>
>>
>> --
>> View this message in context: http://grails.1312388.n4.nabble.com/WarExec-plugin-tp4633240p4633273.html
>> Sent from the Grails - dev mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>
>
>
> --
> http://twoogleplus.com/ Online service to cross-post tweets to Google+
> http://engage.calibreapps.com/ Engage - Web based goal setting and
> performance management

pledbrook

Re: WarExec plugin

Hi David,

> Can we not just publish war-exec and users can choose which one that
> want to use?

Yes, and as I said earlier, you already have permission to publish.

I'm sorry if I'm appearing difficult, but one complaint from users
about the plugin repository is that there are often multiple similar
plugins with little guidance as to which one to pick. Users often just
want something that allows them to run a Grails app standalone,
regardless of the finer details. And don't want to have to test
multiple plugins to find the one that works for them.

There is always a tension between competition and freedom on one side,
and user experience and curation on the other. Where we hold the
balance is probably something that needs deciding by the community as
a whole, but for the moment we're trying to rationalise what's in the
plugin repository.

For the war exec plugin, it would be ideal if you could highlight its
distinguishing features in both the description and prominently in the
docs so that users can see exactly why they might want to choose it
over the standalone plugin.

Thanks

Peter

--
Peter Ledbrook
Developer Advocate
VMware

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email