Jetty vs Gretty Plugin

[Hans Dockter]

I'm wondering what we should do about the core Jetty plugin. The community Gretty plugin by Andrey Hihlovskiy is the much better choice and works with the newest versions of Jetty. But people are often not aware of it and are the disappointed by the stale, core one. As the Jetty plugin is so fundamental for people doing web-development this is not a minor issue.

We have come a long way with the new plugin system and portal. But there is still some way to go when it comes to applying external plugins with the new DSL conveniently in multi-module builds. To explain this for people who haven't been involved with that yet. The idea of the new plugin portal and the new plugin syntax is to make it as easy to apply external plugins as it is to apply core plugins. See: http://www.gradle.org/docs/2.1/release-notes.html#easier-use-of-community-plugins. 

The reason that the Gradle distro is so large is that we bundle so many plugins because having them in core makes them more convenient to apply. With the new plugin system we will eventually be able to make the Gradle distro much smaller as we can move our core plugins to the plugin portal. We will continue to provide standard bundles. But the syntax to apply plugins will be the same, regardless of whether you have them in the local Gradle bundle or you get them from the plugin portal. It will also tear down the wall between the core plugins and external plugins. One thing that is missing with the new plugin mechanism, is a way to conveniently apply plugins in multi-module builds.

You can't do:

subprojects 

   plugins {

       id 'com.company.myplugin' version '1.3'

    }

}

The reason for this is that applying the plugins is a pre-processing step we do before executing the build script. So right now, if you want to use the new plugin syntax, you need to have a plugins { } section for every subproject. We need to provide a convenient alternative, that allows you to define a plugin only once with the new syntax. This will be a part of an improved multi-project build definition which comes with additional advantages.

Back to the Jetty/Gretty plugin. I see 3 things we could do for now:

1.) Leave things as they are until we have finished the new plugin system.

2.) Issue a deprecation warning when people use the core Jetty plugin and refer to the Gretty plugin.

3.) Making the Gretty plugin part of Gradle core.

#1 sucks. We cause frustration and wasted times for our users. That is not what we should continue to do.

#2 It is very straight forward to do. I think we should do this for 2.2. It is also complementary to #3 and #4.

#3 If it would take another year to finish the new plugin syntax we have to consider this. It is a trade off between convenience for our users and making the Gradle distro even bigger. I would not do it considering that we want to finish the new plugin syntax earlier.

Hans 

[Radim Kubacki]

+1 to this. (I do not know what was your #4.)

#3 If it would take another year to finish the new plugin syntax we have to consider this. It is a trade off between convenience for our users and making the Gradle distro even bigger. I would not do it considering that we want to finish the new plugin syntax earlier.

Hans 

--
You received this message because you are subscribed to the Google Groups "gradle-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gradle-dev+...@googlegroups.com.
To post to this group, send email to gradl...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gradle-dev/CAPsC-PKMUjcA63ddttvTntX%2Bs%2B02D2JdzzHUvabJ%3D_nLcDCa3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Hans Dockter]

I forgot to take the reference out. It was not important. 

Hans

To view this discussion on the web visit https://groups.google.com/d/msgid/gradle-dev/CAEpr%3DPykPFZ_LPadU_i%2BvXC2rKpJfryqfGX3zKj-LPSWtr7mcA%40mail.gmail.com.

[Luke Daley]

+1 to #2.

There is no way we can afford to not have multi project support for plugin application in 12 months (I’d even say 6).

To view this discussion on the web visit https://groups.google.com/d/msgid/gradle-dev/CAPsC-P%2BqsgfkmV-P_QVoJigSzGLk4Gp_OhDmbHBhaRbxyDmaxw%40mail.gmail.com.

[davidmc24]

Your proposal (#2) sounds good to me.

[Rene Groeschke]

I would go with #2 too.

It's also a good statement that we trust the community to provide robust plugins ready for the enterprise.
As long as the plugin portal does not provide compatibility checks, I wonder if we should have basic integration tests running against the plugins we reference from gradle core. At least some really basic compatibility checks. We can't release a gradle version referencing a thirdparty plugin that doesn't work with the latest gradle release.

cheers,
rené

davidmc24

11 Sep 2014 02:29

Your proposal (#2) sounds good to me.

On Wednesday, September 10, 2014 10:49:33 AM UTC-4, Hans Dockter wrote:

--
You received this message because you are subscribed to the Google Groups "gradle-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gradle-dev+...@googlegroups.com.
To post to this group, send email to gradl...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gradle-dev/c4d57023-feea-463a-89bb-ecb50f6ee3e3%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Hans Dockter

10 Sep 2014 16:49

[Hans Dockter]

On Thu, Sep 11, 2014 at 1:28 AM, Rene Groeschke <rene.gr...@gradleware.com> wrote:

I would go with #2 too.

It's also a good statement that we trust the community to provide robust plugins ready for the enterprise.
As long as the plugin portal does not provide compatibility checks, I wonder if we should have basic integration tests running against the plugins we reference from gradle core. At least some really basic compatibility checks. We can't release a gradle version referencing a thirdparty plugin that doesn't work with the latest gradle release.

That is a good point.

Hans

 

To view this discussion on the web visit https://groups.google.com/d/msgid/gradle-dev/54115D27.6070007%40gradleware.com.

[Luke Daley]

On Thursday, 11 Sep 2014 at 22:20, Hans Dockter <hans.d...@gradleware.com>, wrote:

On Thu, Sep 11, 2014 at 1:28 AM, Rene Groeschke <rene.gr...@gradleware.com> wrote:

I would go with #2 too.

It's also a good statement that we trust the community to provide robust plugins ready for the enterprise.
As long as the plugin portal does not provide compatibility checks, I wonder if we should have basic integration tests running against the plugins we reference from gradle core. At least some really basic compatibility checks. We can't release a gradle version referencing a thirdparty plugin that doesn't work with the latest gradle release.

That is a good point.

​

Indeed. We should also remember that we don't provide any way to realistically test plugins for compatibility without using internal API.

Hans

 

cheers,
rené

<postbox-contact.jpg>

davidmc24

11 Sep 2014 02:29

Your proposal (#2) sounds good to me.

On Wednesday, September 10, 2014 10:49:33 AM UTC-4, Hans Dockter wrote:

--
You received this message because you are subscribed to the Google Groups "gradle-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gradle-dev+...@googlegroups.com.
To post to this group, send email to gradl...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gradle-dev/c4d57023-feea-463a-89bb-ecb50f6ee3e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

<postbox-contact.jpg>

--
You received this message because you are subscribed to the Google Groups "gradle-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gradle-dev+...@googlegroups.com.
To post to this group, send email to gradl...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gradle-dev/CAPsC-P%2BVhuixuVaECb6VRNzf4YzD5%2BPv%2B%3D%3D1eb%3DW5AUz0tkkSg%40mail.gmail.com.

[Hans Dockter]

On Thu, Sep 11, 2014 at 5:25 AM, Luke Daley <luke....@gradleware.com> wrote:

On Thursday, 11 Sep 2014 at 22:20, Hans Dockter <hans.d...@gradleware.com>, wrote:

On Thu, Sep 11, 2014 at 1:28 AM, Rene Groeschke <rene.gr...@gradleware.com> wrote:

I would go with #2 too.

It's also a good statement that we trust the community to provide robust plugins ready for the enterprise.
As long as the plugin portal does not provide compatibility checks, I wonder if we should have basic integration tests running against the plugins we reference from gradle core. At least some really basic compatibility checks. We can't release a gradle version referencing a thirdparty plugin that doesn't work with the latest gradle release.

That is a good point.

​

Indeed. We should also remember that we don't provide any way to realistically test plugins for compatibility without using internal API.

We should nonetheless go ahead with this as this plugin is so hugely relevant. We can ask Andrey to test manually for the next couple of releases.

Hans

To view this discussion on the web visit https://groups.google.com/d/msgid/gradle-dev/1410438347910.6101f689%40Nodemailer.

[Andrey Hihlovskiy]

On Thursday, September 11, 2014 2:28:47 PM UTC+2, Hans Dockter wrote:

Indeed. We should also remember that we don't provide any way to realistically test plugins for compatibility without using internal API.

We should nonetheless go ahead with this as this plugin is so hugely relevant. We can ask Andrey to test manually for the next couple of releases.

I am ready to test Gretty manually against specific Gradle versions.

Quality of growing gradle plugin ecosystem must be ensured via automation. Let's imagine possible parts of automated plugin test cycle:

1. Check that plugin compiles against certain versions of gradle and JDK.

2. Check that plugin unit tests are successful. No magic here, normal unit tests.

3. Check that plugin integration tests are successful. Integration tests would be driven by gradle scripts, provided by plugin author. Right in the script it should be possible to specify the expected outputs, which will be checked by test harness.

4. Optional: publish plugin code coverage to plugin portal.

 

Hans

--
You received this message because you are subscribed to the Google Groups "gradle-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gradle-dev+...@googlegroups.com.
To post to this group, send email to gradl...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gradle-dev/1410438347910.6101f689%40Nodemailer.

For more options, visit https://groups.google.com/d/optout.

Andrey Hihlovskiy.

[Andrey Hihlovskiy]

Update of today, Oct 27, 2014:

Gretty version 1.1.5 is supplied with 70 integration tests of it's own. The release version was tested against Gradle versions from 1.10 to 2.2-rc-1, all integration tests pass OK.

On Thursday, September 11, 2014 2:28:47 PM UTC+2, Hans Dockter wrote:

[Hans Dockter]

Thank you so much.

Hans

--
You received this message because you are subscribed to the Google Groups "gradle-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gradle-dev+...@googlegroups.com.
To post to this group, send email to gradl...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gradle-dev/0eff1503-c985-4fc2-a02c-eff577787909%40googlegroups.com.

[Daniel Gerson]

Hi Hans! 

What is the status of your suggestion here?

Gretty is still much more configurable and better than the JettyRun plugin, but if you look at 

https://github.com/akhikhl/gretty/issues 

, you'll see that the support is waning since June. It would be a much better solution to bring it under the Gradle umbrella so it doesn't atrophy.

Thanks for all everybody's hard work.

Daniel Gerson.

[Schalk Cronjé]

On Wednesday, 10 September 2014 15:49:33 UTC+1, Hans Dockter wrote:

 One thing that is missing with the new plugin mechanism, is a way to conveniently apply plugins in multi-module builds.

You can't do:

subprojects 

   plugins {

       id 'com.company.myplugin' version '1.3'

    }

}

The reason for this is that applying the plugins is a pre-processing step we do before executing the build script. So right now, if you want to use the new plugin syntax, you need to have a plugins { } section for every subproject. We need to provide a convenient alternative, that allows you to define a plugin only once with the new syntax. This will be a part of an improved multi-project build definition which comes with additional advantages.

Cherry picking out the non-Gretty part of Hans' post:

Thanks for mentioning this, Hans. The new plugin synatt is a good idea, but it definitely is lacking in a number of departments. I still find myself having to use the old style is too many cases, especiallyfor organisations who has restrictions on downloading from external repositories.