Plugins: application.properties vs BuildConfig.groovy?

[jasenj1]

I've seen several posts advocating putting plugin info into the "plugins" section of BuildConfig.groovy instead of using "install-plugin" which puts an entry in application.properties.

Is there any tutorial or explanation of why one over the other? What are the trade-offs are between the two approaches? If BuildConfig.groovy is the newer, better way to do it, then why isn't "install-plugin" changed to modify BuildConfig?

Trying to understand.

- Jasen.

[Jeff Scadden]

I'm interested in an answer to this as well.

On Fri, Jan 20, 2012 at 7:22 AM, jasenj1 <[hidden email]> wrote:

I've seen several posts advocating putting plugin info into the "plugins"
section of BuildConfig.groovy instead of using "install-plugin" which puts
an entry in application.properties.

Is there any tutorial or explanation of why one over the other? What are the
trade-offs are between the two approaches? If BuildConfig.groovy is the
newer, better way to do it, then why isn't "install-plugin" changed to
modify BuildConfig?

Trying to understand.

- Jasen.

--
View this message in context: http://grails.1312388.n4.nabble.com/Plugins-application-properties-vs-BuildConfig-groovy-tp4313370p4313370.html
Sent from the Grails - user mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email

[aaronzirbes]

There is a section in the Grails 2.0 guide that covers this:

http://grails.org/doc/latest/guide/conf.html#pluginDependencies

Hope it helps!

[Vithun Kumar]

I had the same doubt myself, and learnt this from Peter Ledbrook:

Declaring plugins in BuildConfig.groovy provides us the flexibility in customising the dependencies if we require to do so. For example, we can exclude a jar from the plugin dependency. There is no way to do this in application.properties.

There is nothing wrong in having it in application.properties, but if we move a declaration to BuildConfig.groovy at some point of time for the above reason, then our dependencies would be declared in two places. Having them in a single file is neater.

Also, if you take a look at the plugins' pages now, they have the dependency scope mentioned there (by default all plugins currently show 'compile' until the author updates them). Using this dependency is recommended. For example, plugins with 'build' are not required within the war file generated and will not be included if declared correctly. I'm not sure what scope is assumed when declared in application.properties (mostly 'compile'), but declaring it in BuildConfig.groovy is more explicit.

Vithun

On 20 January 2012 16:37, Jeff Scadden <[hidden email]> wrote:

I'm interested in an answer to this as well.

On Fri, Jan 20, 2012 at 7:22 AM, jasenj1 <[hidden email]> wrote:

I've seen several posts advocating putting plugin info into the "plugins"
section of BuildConfig.groovy instead of using "install-plugin" which puts
an entry in application.properties.

Is there any tutorial or explanation of why one over the other? What are the
trade-offs are between the two approaches? If BuildConfig.groovy is the
newer, better way to do it, then why isn't "install-plugin" changed to
modify BuildConfig?

Trying to understand.

- Jasen.

--
View this message in context: http://grails.1312388.n4.nabble.com/Plugins-application-properties-vs-BuildConfig-groovy-tp4313370p4313370.html
Sent from the Grails - user mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email

[Vithun Kumar]

* correction in previous mail: 

we can exclude a plugin from the plugin dependencies, not jar. I'm not sure if jars can be excluded from plugins as well.

Vithun

On 20 January 2012 16:49, Vithun <[hidden email]> wrote:

I had the same doubt myself, and learnt this from Peter Ledbrook:

Declaring plugins in BuildConfig.groovy provides us the flexibility in customising the dependencies if we require to do so. For example, we can exclude a jar from the plugin dependency. There is no way to do this in application.properties.

There is nothing wrong in having it in application.properties, but if we move a declaration to BuildConfig.groovy at some point of time for the above reason, then our dependencies would be declared in two places. Having them in a single file is neater.

Also, if you take a look at the plugins' pages now, they have the dependency scope mentioned there (by default all plugins currently show 'compile' until the author updates them). Using this dependency is recommended. For example, plugins with 'build' are not required within the war file generated and will not be included if declared correctly. I'm not sure what scope is assumed when declared in application.properties (mostly 'compile'), but declaring it in BuildConfig.groovy is more explicit.

Vithun

On 20 January 2012 16:37, Jeff Scadden <[hidden email]> wrote:

I'm interested in an answer to this as well.

On Fri, Jan 20, 2012 at 7:22 AM, jasenj1 <[hidden email]> wrote:

I've seen several posts advocating putting plugin info into the "plugins"
section of BuildConfig.groovy instead of using "install-plugin" which puts
an entry in application.properties.

Is there any tutorial or explanation of why one over the other? What are the
trade-offs are between the two approaches? If BuildConfig.groovy is the
newer, better way to do it, then why isn't "install-plugin" changed to
modify BuildConfig?

Trying to understand.

- Jasen.

--
View this message in context: http://grails.1312388.n4.nabble.com/Plugins-application-properties-vs-BuildConfig-groovy-tp4313370p4313370.html
Sent from the Grails - user mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email

[pledbrook]

> * correction in previous mail: 
> we can exclude a plugin from the plugin dependencies, not jar. I'm not sure if jars can be excluded from plugins as well.

JARs can be excluded as well.

Plugins declared in application.properties effectively have "compile" scope, meaning that they will be included in the runtime classpath.

I think you will see "quick start" guides using install-plugin because it's so convenient, whereas explaining BuildConfig.groovy is more involved. But once you get past the initial stages you should move plugin declarations to BuildConfig.groovy.

Peter.

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

[antony]

As Peter says, putting plugins in application.properties puts them in
compile scope (the most global scope possible).

This will technically work, but the reason I am so against it - as you
will see from a number of my posts - is that it means you end up
putting, for example; test-only plugins into production code, and in
any non-trivial application this is likely to open huge security holes
on your production servers - for instance fixtures inside those
plugins which tests use to modify the application's state in an
artificial (and unsecure) way (which is useful when functionally
testing your application).

So yeah, technically "There is nothing wrong in having it in
application.properties," as stated by Vithun, but you're going to
really need to think about what you're including on your live servers
and if it really is acceptable/safe/performant to have it there.

Cheers,
Antony

On 20 January 2012 19:26, Peter Ledbrook <[hidden email]> wrote:

>> * correction in previous mail:
>> we can exclude a plugin from the plugin dependencies, not jar. I'm not
>> sure if jars can be excluded from plugins as well.
>
> JARs can be excluded as well.
>
> Plugins declared in application.properties effectively have "compile" scope,
> meaning that they will be included in the runtime classpath.
>
> I think you will see "quick start" guides using install-plugin because it's
> so convenient, whereas explaining BuildConfig.groovy is more involved. But
> once you get past the initial stages you should move plugin declarations to
> BuildConfig.groovy.
>
> Peter.
>
> --
> Peter Ledbrook
> Grails Advocate
> SpringSource - A Division of VMware
>

--
________________________________
ꜽ . antony jones . http://www.enzy.org

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

    http://xircles.codehaus.org/manage_email

[jasenj1]

Thanks. This is good info. The docs explain how to use BuildConfig, but not why and the subtleties mentioned above. This definitely seems like the kind of info that should be captured in a permanent place like a blog post.

- Jasen.

If BuildConfig.groovy is the
newer, better way to do it, then why isn't "install-plugin" changed to
modify BuildConfig?

I am really interested in this one.

Cheers, 

Caio.

On Sat, Jan 21, 2012 at 12:39 AM, jasenj1 <[hidden email]> wrote:

Thanks. This is good info. The docs explain how to use BuildConfig, but not
why and the subtleties mentioned above. This definitely seems like the kind
of info that should be captured in a permanent place like a blog post.

- Jasen.

--
View this message in context: http://grails.1312388.n4.nabble.com/Plugins-application-properties-vs-BuildConfig-groovy-tp4313370p4315183.html

Sent from the Grails - user mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email

[Sebastian Gozin]

Quite honestly I really dislike the idea of a command such as install-plugin messing with my BuildConfig.groovy file.

I'd rather the install-plugin command is removed.

- Sebastian

On 21 Jan 2012, at 18:31, [hidden email] wrote:

If BuildConfig.groovy is the
newer, better way to do it, then why isn't "install-plugin" changed to
modify BuildConfig?

I am really interested in this one.

Cheers, 

Caio.

On Sat, Jan 21, 2012 at 12:39 AM, jasenj1 <[hidden email]> wrote:

Thanks. This is good info. The docs explain how to use BuildConfig, but not
why and the subtleties mentioned above. This definitely seems like the kind
of info that should be captured in a permanent place like a blog post.

- Jasen.

--
View this message in context: http://grails.1312388.n4.nabble.com/Plugins-application-properties-vs-BuildConfig-groovy-tp4313370p4315183.html

Sent from the Grails - user mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email

[pledbrook]

>> If BuildConfig.groovy is the
>> newer, better way to do it, then why isn't "install-plugin" changed to
>> modify BuildConfig?
>
>
> I am really interested in this one.

Because modifying code is difficult at best, and that's what
BuildConfig.groovy is. The declaration might be in an if statement, or
it could all be on one line. Basically, the likely problems that will
occur from trying to do this will outweigh the benefits.

I'd like to see some integration of ConfigSlurper and YAML such that
the two could be used together, with the YAML allowing easy
programmatic modification, with ConfigSlurper allowing variable
substitution, conditions, etc.

Peter

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

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

    http://xircles.codehaus.org/manage_email

[Andrew Todd]

On Mon, Jan 23, 2012 at 4:04 AM, Peter Ledbrook <[hidden email]> wrote:
> Because modifying code is difficult at best, and that's what
> BuildConfig.groovy is. The declaration might be in an if statement, or
> it could all be on one line. Basically, the likely problems that will
> occur from trying to do this will outweigh the benefits.

It sounds like the right thing to do would be to deprecate the
"install-plugin" command entirely, perhaps to output a message telling
people to use BuildConfig.groovy instead.

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

    http://xircles.codehaus.org/manage_email

[John Fletcher-3]

If you deprecate it you could always cause a friendly message giving them a suggestion that might not be ideal for every situation but will at least work, thereby relieving problems for the confused. Eg:

> install-plugin modernizr

> Installing plugins is acheived by editing the "plugins" closure in grails-app/conf/BuildConfig.groovy. Try adding this: 'runtime ":modernizr:2.0.6"'

John

2012/1/23 Andrew Todd <[hidden email]>

On Mon, Jan 23, 2012 at 4:04 AM, Peter Ledbrook <[hidden email]> wrote:
> Because modifying code is difficult at best, and that's what
> BuildConfig.groovy is. The declaration might be in an if statement, or
> it could all be on one line. Basically, the likely problems that will
> occur from trying to do this will outweigh the benefits.

It sounds like the right thing to do would be to deprecate the
"install-plugin" command entirely, perhaps to output a message telling
people to use BuildConfig.groovy instead.

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

   http://xircles.codehaus.org/manage_email

[lucastex]

IMHO,

People should keep in mind that "how" the application manage these kind of dependencies is the less important. What new users really care about, -- and this is what brought me to grails a long time ago and, in theory, keep bringing new people --, is the ease of use.

Talking to a friend this week we saw how is grails just getting bigger and better each day, but unfortunately, more difficult either. This is not *bad*, really it isn't, but we can't forget all that "convention over configuration", and DRY concepts that inspired Grails in the beggining.

So, my personal opinion, should be that we DO NOT deprecate the install-plugin, cause the "install-plugin" shows part of the beauty and the magic on Grails Framework.

Should we change and modify how it works (modifying BuildConfig) or other stuff? Probably yes, but we shouldn't just remove it. 

And yes, I think beginners don't like to open "BuildConfig" and start adding new dependencies, so, just keep install-plugin there.

Or just keep install-plugin adding plugins in "compile scope" by convention, then if you want to use "runtime", "test" or other scope, just declare in your BuildConfig.

And why I don't stop trying to make things easier for new users? Because each day I'm trying to tell people about Grails more and more.  

This is the magic of Grails, this is the beauty of it. :)

[]s,

Lucas Teixeira

On Wed, Jan 25, 2012 at 7:31 AM, John Fletcher <[hidden email]> wrote:

If you deprecate it you could always cause a friendly message giving them a suggestion that might not be ideal for every situation but will at least work, thereby relieving problems for the confused. Eg:

> install-plugin modernizr

> Installing plugins is acheived by editing the "plugins" closure in grails-app/conf/BuildConfig.groovy. Try adding this: 'runtime ":modernizr:2.0.6"'

John

2012/1/23 Andrew Todd <[hidden email]>

On Mon, Jan 23, 2012 at 4:04 AM, Peter Ledbrook <[hidden email]> wrote:
> Because modifying code is difficult at best, and that's what
> BuildConfig.groovy is. The declaration might be in an if statement, or
> it could all be on one line. Basically, the likely problems that will
> occur from trying to do this will outweigh the benefits.

It sounds like the right thing to do would be to deprecate the
"install-plugin" command entirely, perhaps to output a message telling
people to use BuildConfig.groovy instead.

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

   http://xircles.codehaus.org/manage_email