install-plugin vs BuildConfig.groovy

[pledbrook]

Hi,

I'm currently working on an article about the Database Migration
plugin and I decided based on previous discussions to explain the
dependency DSL approach for 'installing' a plugin. That's the
preferred approach now, correct? Well, in explaining the steps
involved I realised that the process is just not as simple as
'install-plugin':

1. Find out what the latest version of the plugin is
2. Work out which scope the plugin should be in
3. Add the plugin declaration
4. Run 'grails compile' to ensure the plugin is installed (you won't
be able to run any plugin commands until you do!)

Compare this to:

1. Run 'grails install-plugin ...'

You might think to use 'latest.integration' for the plugin version and
then step 1 can be eliminated. But now your plugin will automatically
be updated if a new version comes along. Not what you typically want.

So, should we really be pushing the dependency DSL as the better
approach? I can understand the advantages, but those advantages come
with additional complexity. And could we not come up with a syntax
that allows the plugin to remain in application.properties but allow
you to specify exclusions in the dependency DSL? For example:

    plugins {
        spock exclude: "commons-logging", scope: "test"
    }

Cheers,

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

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

    http://xircles.codehaus.org/manage_email

[rlovtangen]

On Aug 9, 2011, at 3:40 PM, Peter Ledbrook wrote:

Hi,

I'm currently working on an article about the Database Migration
plugin and I decided based on previous discussions to explain the
dependency DSL approach for 'installing' a plugin. That's the
preferred approach now, correct? Well, in explaining the steps
involved I realised that the process is just not as simple as
'install-plugin':

1. Find out what the latest version of the plugin is
2. Work out which scope the plugin should be in
3. Add the plugin declaration
4. Run 'grails compile' to ensure the plugin is installed (you won't
be able to run any plugin commands until you do!)

Maybe there should be a 'grails install-plugins' command that ensures plugins declared in BuildConfig.groovy (and application.properties) are installed.

Compare this to:

1. Run 'grails install-plugin ...'

What scope will plugins installed this way have?

You might think to use 'latest.integration' for the plugin version and
then step 1 can be eliminated. But now your plugin will automatically
be updated if a new version comes along. Not what you typically want.

I use 'grails plugin-info ...' to find this information. I wish this command could provide me with the line to copy/paste into BuildConfig.groovy

So, should we really be pushing the dependency DSL as the better
approach? I can understand the advantages, but those advantages come
with additional complexity. And could we not come up with a syntax
that allows the plugin to remain in application.properties but allow
you to specify exclusions in the dependency DSL? For example:

   plugins {
       spock exclude: "commons-logging", scope: "test"
   }

This is a new idea that sounds like a compromise, although I for my own usage will continue to use BuildConfig.groovy only.

If so, I think only plugins you install explicitly should go here, i.e. no lines for plugins that are only dependencies of plugins you have installed (the same way as normal dependencies are handled).

Ronny

[pledbrook]

> Maybe there should be a 'grails install-plugins' command that ensures
> plugins declared in BuildConfig.groovy (and application.properties) are
> installed.

Or 'grails refresh-dependencies'.

> Compare this to:
>
> 1. Run 'grails install-plugin ...'
>
> What scope will plugins installed this way have?

Compile.

> You might think to use 'latest.integration' for the plugin version and
> then step 1 can be eliminated. But now your plugin will automatically
> be updated if a new version comes along. Not what you typically want.
>
> I use 'grails plugin-info ...' to find this information. I wish this command
> could provide me with the line to copy/paste into BuildConfig.groovy

Have you raised a JIRA?

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

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

    http://xircles.codehaus.org/manage_email

[rlovtangen]

On Aug 9, 2011, at 4:08 PM, Peter Ledbrook wrote:

>> Maybe there should be a 'grails install-plugins' command that ensures
>> plugins declared in BuildConfig.groovy (and application.properties) are
>> installed.
>
> Or 'grails refresh-dependencies'.

That's better

>
>> Compare this to:
>>
>> 1. Run 'grails install-plugin ...'
>>
>> What scope will plugins installed this way have?
>
> Compile.

Does that work for plugins like eclipse-scripts, that needs Build scope?

>
>> You might think to use 'latest.integration' for the plugin version and
>> then step 1 can be eliminated. But now your plugin will automatically
>> be updated if a new version comes along. Not what you typically want.
>>
>> I use 'grails plugin-info ...' to find this information. I wish this command
>> could provide me with the line to copy/paste into BuildConfig.groovy
>
> Have you raised a JIRA?

Don't remember. I will have a look and create i JIRA if it doesn't already exist.

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

    http://xircles.codehaus.org/manage_email

[bdrhoa]

I'm sure I just missed the explanation, but I don't know what the advantages of the DSL approach are. To me, install-plugin makes perfect sense. So "if it's not broke, don't fix it."

---------------------------
www.maf.org/rhoads
www.ontherhoads.org

On Tue, Aug 9, 2011 at 7:40 AM, Peter Ledbrook <[hidden email]> wrote:

Hi,

I'm currently working on an article about the Database Migration
plugin and I decided based on previous discussions to explain the
dependency DSL approach for 'installing' a plugin. That's the
preferred approach now, correct? Well, in explaining the steps
involved I realised that the process is just not as simple as
'install-plugin':

1. Find out what the latest version of the plugin is
2. Work out which scope the plugin should be in
3. Add the plugin declaration
4. Run 'grails compile' to ensure the plugin is installed (you won't
be able to run any plugin commands until you do!)

Compare this to:

1. Run 'grails install-plugin ...'

You might think to use 'latest.integration' for the plugin version and
then step 1 can be eliminated. But now your plugin will automatically
be updated if a new version comes along. Not what you typically want.

So, should we really be pushing the dependency DSL as the better
approach? I can understand the advantages, but those advantages come
with additional complexity. And could we not come up with a syntax
that allows the plugin to remain in application.properties but allow
you to specify exclusions in the dependency DSL? For example:

   plugins {
       spock exclude: "commons-logging", scope: "test"
   }

Cheers,

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

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

   http://xircles.codehaus.org/manage_email

[Al Baker]

+1 for install-plugin and DSL for plugin exclusions.  Right now dealing with a plugin with old dependencies sends you down a bit of a rabbit hole.

Al

[Kimble]

+1 for the dependency dsl. If developers are able to specify Maven dependencies that way I don't see why they shouldn't be able to do the same for plugins.

Ronny's idea about printing the required code with relevant shell commands is a good one. The same could be done on the plugin pages on grails.org, similar to mvnrepository.com (for example: http://mvnrepository.com/artifact/ch.qos.logback/logback-core/0.9.29).

[rlovtangen]

The biggest advantage with the DSL approach is probably being able to control dependencies, like Peter now proposed a way to do for application.properties as well. (See http://www.grails.org/doc/latest/guide/3.%20Configuration.html#3.7.7%20Plugin%20JAR%20Dependencies)

This is a must have feature IMO.

Other advantages:

- can use variables, nice for e.g. keeping hibernate and tomcat plugin the same version as the app itself (compile ":hibernate:$grailsVersion")

- can control scope (build, compile, runtime etc)

- can use 'latest.integration' as version, to always have latest version. Although this might not be a good idea in most cases.

- can exclude a transitive plugin

- you get to specify only your direct plugin dependencies, not the transitive ones (although these are added to application.properties at the moment, which I hope they won't in the future). Say you install plugin A with 'grails install-plugin A'. Plugin A also adds plugin B to application.properties. Later you decide to remove plugin A. Most likely will you forget to remove plugin B, which you no longer need. Or maybe it's still needed, because plugin C needs it. It's hard to keep track of.

And probably some more advantages that I didn't think of.

Ronny

On Aug 9, 2011, at 6:51 PM, Brad Rhoads wrote:

I'm sure I just missed the explanation, but I don't know what the advantages of the DSL approach are. To me, install-plugin makes perfect sense. So "if it's not broke, don't fix it."

---------------------------
www.maf.org/rhoads
www.ontherhoads.org

On Tue, Aug 9, 2011 at 7:40 AM, Peter Ledbrook <[hidden email]> wrote:

Hi,

I'm currently working on an article about the Database Migration
plugin and I decided based on previous discussions to explain the
dependency DSL approach for 'installing' a plugin. That's the
preferred approach now, correct? Well, in explaining the steps
involved I realised that the process is just not as simple as
'install-plugin':

1. Find out what the latest version of the plugin is
2. Work out which scope the plugin should be in
3. Add the plugin declaration
4. Run 'grails compile' to ensure the plugin is installed (you won't
be able to run any plugin commands until you do!)

Compare this to:

1. Run 'grails install-plugin ...'

You might think to use 'latest.integration' for the plugin version and
then step 1 can be eliminated. But now your plugin will automatically
be updated if a new version comes along. Not what you typically want.

So, should we really be pushing the dependency DSL as the better
approach? I can understand the advantages, but those advantages come
with additional complexity. And could we not come up with a syntax
that allows the plugin to remain in application.properties but allow
you to specify exclusions in the dependency DSL? For example:

   plugins {
       spock exclude: "commons-logging", scope: "test"
   }

Cheers,

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

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

   http://xircles.codehaus.org/manage_email

[bdrhoa]

>you get to specify only your direct plugin dependencies, not the transitive ones

I like that one for sure...
---------------------------
www.maf.org/rhoads
www.ontherhoads.org

On Tue, Aug 9, 2011 at 2:35 PM, Ronny Løvtangen <[hidden email]> wrote:

ou get to specify only your direct plugin dependencies, not the transitive ones

On 09/08/2011, at 11:40 PM, Peter Ledbrook <[hidden email]> wrote:

> m currently working on an article about the Database Migration
> plugin and I decided based on previous discussions to explain the
> dependency DSL approach for 'installing' a plugin. That's the
> preferred approach now, correct? Well, in explaining the steps
> involved I realised that the process is just not as simple as
> 'install-plugin':
>
> 1. Find out what the latest version of the plugin is

This is a good thing, and not that onerous. Can also be made trivial with commands to generate snippets for copy paste.

> 2. Work out which scope the plugin should be in

Using application.properties just ignores this problem, it doesn't solve it.

> 3. Add the plugin declaration

Yeah, as we've discussed many times there is no easy way out. But editing a file shouldn't be a blocker for programmers.

> 4. Run 'grails compile' to ensure the plugin is installed (you won't
> be able to run any plugin commands until you do!)

This is really a limitation of the build environment more than the DSL.

The same issue applies anyway when using application.properties and another developer installed the plugin and you then check out the source.


As I've said before, having two mechanisms and supporting two mechanisms going forward without deprecating one is horrible. It's confusing.

Install-plugin is broken, so should be deprecated. It's convenience does not trump the extra, necessary, power of the DSL approach so it should go.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Gavin-15]

+1

On 10/08/11 08:50, Luke Daley wrote:

>
>
>
> On 09/08/2011, at 11:40 PM, Peter Ledbrook<[hidden email]>  wrote:
>
>    
>> m currently working on an article about the Database Migration
>> plugin and I decided based on previous discussions to explain the
>> dependency DSL approach for 'installing' a plugin. That's the
>> preferred approach now, correct? Well, in explaining the steps
>> involved I realised that the process is just not as simple as
>> 'install-plugin':
>>
>> 1. Find out what the latest version of the plugin is
>>      
> This is a good thing, and not that onerous. Can also be made trivial with commands to generate snippets for copy paste.
>
>    
>> 2. Work out which scope the plugin should be in
>>      
> Using application.properties just ignores this problem, it doesn't solve it.
>
>    
>> 3. Add the plugin declaration
>>      
> Yeah, as we've discussed many times there is no easy way out. But editing a file shouldn't be a blocker for programmers.
>
>    
>> 4. Run 'grails compile' to ensure the plugin is installed (you won't
>> be able to run any plugin commands until you do!)
>>      
> This is really a limitation of the build environment more than the DSL.
>
> The same issue applies anyway when using application.properties and another developer installed the plugin and you then check out the source.
>
>
> As I've said before, having two mechanisms and supporting two mechanisms going forward without deprecating one is horrible. It's confusing.
>
> Install-plugin is broken, so should be deprecated. It's convenience does not trump the extra, necessary, power of the DSL approach so it should go.
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>      http://xircles.codehaus.org/manage_email
>
>
>
>    

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

    http://xircles.codehaus.org/manage_email

On 10/08/2011, at 2:51 AM, Brad Rhoads wrote:

I'm sure I just missed the explanation, but I don't know what the advantages of the DSL approach are. To me, install-plugin makes perfect sense. So "if it's not broke, don't fix it."

The main reason it's broken is that it's conceptually broken. You don't “install” a plugin, you depend on it. The use of the install concept causes problems.

[bdrhoa]

That makes sense. And I agree there should only be one or the other. 

Could grails-update handle this? Seems like it should.

---------------------------
www.maf.org/rhoads
www.ontherhoads.org

On Tue, Aug 9, 2011 at 5:49 PM, Luke Daley <[hidden email]> wrote:

On 10/08/2011, at 2:51 AM, Brad Rhoads wrote:

I'm sure I just missed the explanation, but I don't know what the advantages of the DSL approach are. To me, install-plugin makes perfect sense. So "if it's not broke, don't fix it."

The main reason it's broken is that it's conceptually broken. You don't “install” a plugin, you depend on it. The use of the install concept causes problems.

On 10/08/2011, at 9:55 AM, Brad Rhoads wrote:

Could grails-update handle this? Seems like it should.

Handle what exactly?

[bdrhoa]

Move the plugin entries from application.properties a dependency entry.

Just so depreciating plugins in application.properties isn't a breaking change.

---------------------------
www.maf.org/rhoads
www.ontherhoads.org

On Tue, Aug 9, 2011 at 6:13 PM, Luke Daley <[hidden email]> wrote:

On 10/08/2011, at 9:55 AM, Brad Rhoads wrote:

Could grails-update handle this? Seems like it should.

Handle what exactly?

[rlovtangen]

On Aug 9, 2011, at 4:18 PM, Ronny Løvtangen wrote:

On Aug 9, 2011, at 4:08 PM, Peter Ledbrook wrote:

You might think to use 'latest.integration' for the plugin version and

then step 1 can be eliminated. But now your plugin will automatically

be updated if a new version comes along. Not what you typically want.

I use 'grails plugin-info ...' to find this information. I wish this command

could provide me with the line to copy/paste into BuildConfig.groovy

Have you raised a JIRA?

Don't remember. I will have a look and create i JIRA if it doesn't already exist.

Created http://jira.grails.org/browse/GRAILS-7914

Ronny