Proper plugin installation for 2.2

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Proper plugin installation for 2.2

Scott6666
The plugin pages have both Dependency instructions and Installation instructions.  If you do the install-plugin, the warning comes up to say don't do this.

Is it sufficient to just put in the dependency or do you need to run the installation command line as well?




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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Proper plugin installation for 2.2

rlovtangen
It's sufficient to put in the dependency, then the installation will happen on the next 'grails run-app' or similar commands. If you want to trigger the installation right away, you can run 'grails refresh-dependencies' . Especially if the plugin has some scripts you need to run, like the 's2-quickstart' of spring-security-core, you need to trigger the installation first for the scripts to be available.

'install-plugin' shouldn't be used in conjunction with this preferred way of installing plugins.
I'm in favour of removing the old install-plugin command, to avoid misconception. But I know there are others that wants to keep it around because of the showcase effect.

Ronny

On Dec 27, 2012, at 4:01 PM, Scott Eisenberg <[hidden email]> wrote:

> The plugin pages have both Dependency instructions and Installation instructions.  If you do the install-plugin, the warning comes up to say don't do this.
>
> Is it sufficient to just put in the dependency or do you need to run the installation command line as well?
>
>
>
>
> ---------------------------------------------------------------------
> 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


Reply | Threaded
Open this post in threaded view
|

Re: Proper plugin installation for 2.2

Jeff Brown-4
In reply to this post by Scott6666

On Dec 27, 2012, at 9:01 AM, Scott Eisenberg <[hidden email]> wrote:

> The plugin pages have both Dependency instructions and Installation instructions.  If you do the install-plugin, the warning comes up to say don't do this.
>
> Is it sufficient to just put in the dependency or do you need to run the installation command line as well?
>
>
>
>

We are looking to either yank the command altogether or change its behavior in a future release.  See https://github.com/grails/grails-core/commit/3f106344380652c64f7390015535b24f4a252fc9

I think removing the command is better than what it does now.  Having 2 separate places where plugin dependencies are expressed (application.properties and BuildConfig.groovy) is confusing and potentially problematic.  One benefit of the command is that you only need to know the name of the plugin you are installing.  You don't necessarily need to know a version number and you don't need to know the syntax to express in BuildConfig.groovy.  I don't think either of those 2 things are a big deal but some of our users disagree.

If the command is left in it should be made to modify some file that is well formed and easily modified by software.  BuildConfig.groovy kind of meets that criteria but not perfectly.  One complication is that the uninstall-plugin command.  Having it find and remove code from BuildConfig.groovy is problematic.

One thing we need to decide is how big of a deal is it if this command is removed altogether from Grails 2.3.  My own personal opinion on this is that it really isn't a big deal.  It demos well but for real application development it seems to offer so little.  Of course we welcome everyone's input.

How do you feel about this? (that is directed not just at Scott, but to the whole list)

Thanks for your input.



JSB

--
Jeff Brown
[hidden email]
SpringSource - A Division Of VMware
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Proper plugin installation for 2.2

tomas lin
+1 for shooting it in the back and dumping the body in a nearby river.

How does one go about installing a plugin from a zip file once this command is removed? There doesn't seem to be a parallel mechanism in the BuildConfig.groovy world. 

On Thu, Dec 27, 2012 at 6:51 PM, Jeff Brown <[hidden email]> wrote:
We are looking to either yank the command altogether or change its behavior in a future release.  See https://github.com/grails/grails-core/commit/3f106344380652c64f7390015535b24f4a252fc9

Reply | Threaded
Open this post in threaded view
|

Re: Proper plugin installation for 2.2

Jordon Saardchit
Agree… kill install plugin!

Jordon

On Dec 27, 2012, at 2:50 PM, Tomas Lin <[hidden email]> wrote:

+1 for shooting it in the back and dumping the body in a nearby river.

How does one go about installing a plugin from a zip file once this command is removed? There doesn't seem to be a parallel mechanism in the BuildConfig.groovy world. 

On Thu, Dec 27, 2012 at 6:51 PM, Jeff Brown <[hidden email]> wrote:
We are looking to either yank the command altogether or change its behavior in a future release.  See https://github.com/grails/grails-core/commit/3f106344380652c64f7390015535b24f4a252fc9


Reply | Threaded
Open this post in threaded view
|

RE: Proper plugin installation for 2.2

tacrom

I’d also agree that it’s rather confusing to have two different solutions for one problem and I’d love

to see something like a DependencyConfig.groovy or something like that if it’s not applicable to have

it all done within the BuildConfig.groovy file (because of  uninstall-plugin, as Jeff mentioned).

This would make it a lot easier to maintain the whole dependencies of the project and all configuration

of the dependencies would be in one place – much clearer and better to read.

 

I think the new implementation which kicks the install-plugin command should also be able to give all

the opportunities one had with install-plugin on the one hand and BuildConfig.groovy on the other hand.

Best of both worlds, so to say ;) and a real evolution for the dependency management…

 

But, as always, these are just my 2 cents :D

 

From: Jordon Saardchit [mailto:[hidden email]]
Sent: Friday, December 28, 2012 1:09 AM
To: [hidden email]
Subject: Re: [grails-user] Proper plugin installation for 2.2

 

Agree… kill install plugin!

 

Jordon

 

On Dec 27, 2012, at 2:50 PM, Tomas Lin <[hidden email]> wrote:



+1 for shooting it in the back and dumping the body in a nearby river.

 

How does one go about installing a plugin from a zip file once this command is removed? There doesn't seem to be a parallel mechanism in the BuildConfig.groovy world. 

 

On Thu, Dec 27, 2012 at 6:51 PM, Jeff Brown <[hidden email]> wrote:

We are looking to either yank the command altogether or change its behavior in a future release.  See https://github.com/grails/grails-core/commit/3f106344380652c64f7390015535b24f4a252fc9

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Proper plugin installation for 2.2

Paul Fernley2
In reply to this post by Scott6666
Yep, ditch install-plugin
Reply | Threaded
Open this post in threaded view
|

Re: Proper plugin installation for 2.2

Jeff Brown-4
In reply to this post by tomas lin

On Dec 27, 2012, at 4:50 PM, Tomas Lin <[hidden email]> wrote:

> +1 for shooting it in the back and dumping the body in a nearby river.
>
> How does one go about installing a plugin from a zip file once this command is removed? There doesn't seem to be a parallel mechanism in the BuildConfig.groovy world.
>
>
>

This is one of the issues that has to be resolved before the command could be removed, if we end up deciding to remove the command.



JSB

--
Jeff Brown
[hidden email]
SpringSource - A Division Of VMware
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Proper plugin installation for 2.2

PeterNSteinmetz
In reply to this post by Scott6666
Yes, installing from zip is important. Particularly given the present state of integrating fixes and releases - there are a lot of people who need to use patched plugins.

Perhaps something could be added to the DSL to indicate the use of a local zip file as a source? Thereby simplifying such deployment?

Cheers,
Peter


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Proper plugin installation for 2.2

bdrhoa
In reply to this post by Jeff Brown-4

I'd like to see the command stay as a shortcut to updating buildconfig with the current release of a plugin.

I think it would help people get started with Grails more easily.

On Dec 27, 2012 11:53 AM, "Jeff Brown" <[hidden email]> wrote:

On Dec 27, 2012, at 9:01 AM, Scott Eisenberg <[hidden email]> wrote:

> The plugin pages have both Dependency instructions and Installation instructions.  If you do the install-plugin, the warning comes up to say don't do this.
>
> Is it sufficient to just put in the dependency or do you need to run the installation command line as well?
>
>
>
>

We are looking to either yank the command altogether or change its behavior in a future release.  See https://github.com/grails/grails-core/commit/3f106344380652c64f7390015535b24f4a252fc9

I think removing the command is better than what it does now.  Having 2 separate places where plugin dependencies are expressed (application.properties and BuildConfig.groovy) is confusing and potentially problematic.  One benefit of the command is that you only need to know the name of the plugin you are installing.  You don't necessarily need to know a version number and you don't need to know the syntax to express in BuildConfig.groovy.  I don't think either of those 2 things are a big deal but some of our users disagree.

If the command is left in it should be made to modify some file that is well formed and easily modified by software.  BuildConfig.groovy kind of meets that criteria but not perfectly.  One complication is that the uninstall-plugin command.  Having it find and remove code from BuildConfig.groovy is problematic.

One thing we need to decide is how big of a deal is it if this command is removed altogether from Grails 2.3.  My own personal opinion on this is that it really isn't a big deal.  It demos well but for real application development it seems to offer so little.  Of course we welcome everyone's input.

How do you feel about this? (that is directed not just at Scott, but to the whole list)

Thanks for your input.



JSB

--
Jeff Brown
[hidden email]
SpringSource - A Division Of VMware
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Proper plugin installation for 2.2

Levi Yourchuck
Is this documented?  I was wondering why I get errors...



On Dec 28, 2012, at 12:34 PM, Brad Rhoads <[hidden email]> wrote:

I'd like to see the command stay as a shortcut to updating buildconfig with the current release of a plugin.

I think it would help people get started with Grails more easily.

On Dec 27, 2012 11:53 AM, "Jeff Brown" <[hidden email]> wrote:

On Dec 27, 2012, at 9:01 AM, Scott Eisenberg <[hidden email]> wrote:

> The plugin pages have both Dependency instructions and Installation instructions.  If you do the install-plugin, the warning comes up to say don't do this.
>
> Is it sufficient to just put in the dependency or do you need to run the installation command line as well?
>
>
>
>

We are looking to either yank the command altogether or change its behavior in a future release.  See https://github.com/grails/grails-core/commit/3f106344380652c64f7390015535b24f4a252fc9

I think removing the command is better than what it does now.  Having 2 separate places where plugin dependencies are expressed (application.properties and BuildConfig.groovy) is confusing and potentially problematic.  One benefit of the command is that you only need to know the name of the plugin you are installing.  You don't necessarily need to know a version number and you don't need to know the syntax to express in BuildConfig.groovy.  I don't think either of those 2 things are a big deal but some of our users disagree.

If the command is left in it should be made to modify some file that is well formed and easily modified by software.  BuildConfig.groovy kind of meets that criteria but not perfectly.  One complication is that the uninstall-plugin command.  Having it find and remove code from BuildConfig.groovy is problematic.

One thing we need to decide is how big of a deal is it if this command is removed altogether from Grails 2.3.  My own personal opinion on this is that it really isn't a big deal.  It demos well but for real application development it seems to offer so little.  Of course we welcome everyone's input.

How do you feel about this? (that is directed not just at Scott, but to the whole list)

Thanks for your input.



JSB

--
Jeff Brown
[hidden email]
SpringSource - A Division Of VMware
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Proper plugin installation for 2.2

Jeff Brown-4

On Dec 30, 2012, at 7:19 PM, Levi <[hidden email]> wrote:

> Is this documented?  I was wondering why I get errors...
>


Is what documented?



JSB
--
Jeff Brown
[hidden email]
SpringSource - A Division Of VMware
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Proper plugin installation for 2.2

Giancarlo Angulo
In reply to this post by Jeff Brown-4

Kill the plugin

On Dec 28, 2012 2:51 AM, "Jeff Brown" <[hidden email]> wrote:

On Dec 27, 2012, at 9:01 AM, Scott Eisenberg <[hidden email]> wrote:

> The plugin pages have both Dependency instructions and Installation instructions.  If you do the install-plugin, the warning comes up to say don't do this.
>
> Is it sufficient to just put in the dependency or do you need to run the installation command line as well?
>
>
>
>

We are looking to either yank the command altogether or change its behavior in a future release.  See https://github.com/grails/grails-core/commit/3f106344380652c64f7390015535b24f4a252fc9

I think removing the command is better than what it does now.  Having 2 separate places where plugin dependencies are expressed (application.properties and BuildConfig.groovy) is confusing and potentially problematic.  One benefit of the command is that you only need to know the name of the plugin you are installing.  You don't necessarily need to know a version number and you don't need to know the syntax to express in BuildConfig.groovy.  I don't think either of those 2 things are a big deal but some of our users disagree.

If the command is left in it should be made to modify some file that is well formed and easily modified by software.  BuildConfig.groovy kind of meets that criteria but not perfectly.  One complication is that the uninstall-plugin command.  Having it find and remove code from BuildConfig.groovy is problematic.

One thing we need to decide is how big of a deal is it if this command is removed altogether from Grails 2.3.  My own personal opinion on this is that it really isn't a big deal.  It demos well but for real application development it seems to offer so little.  Of course we welcome everyone's input.

How do you feel about this? (that is directed not just at Scott, but to the whole list)

Thanks for your input.



JSB

--
Jeff Brown
[hidden email]
SpringSource - A Division Of VMware
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Proper plugin installation for 2.2

Nicholas Wittstruck
I would also like to see the command removed.. Changing the BuildConfig is easy enough. 

Since we are already discussing having 2 separate places where things can be declared - is it possible to get rid of the application.properties completely? Besides plugin dependencies, there are other configuration values as well (e.g. servlet version) that occur in multiple places. Is there any config value that can not be declared in (Build-)Config, but has to be in the application.properties?

Nicholas


On 01.01.2013, at 13:58, Giancarlo Angulo <[hidden email]> wrote:

Kill the plugin

On Dec 28, 2012 2:51 AM, "Jeff Brown" <[hidden email]> wrote:

On Dec 27, 2012, at 9:01 AM, Scott Eisenberg <[hidden email]> wrote:

> The plugin pages have both Dependency instructions and Installation instructions.  If you do the install-plugin, the warning comes up to say don't do this.
>
> Is it sufficient to just put in the dependency or do you need to run the installation command line as well?
>
>
>
>

We are looking to either yank the command altogether or change its behavior in a future release.  See https://github.com/grails/grails-core/commit/3f106344380652c64f7390015535b24f4a252fc9

I think removing the command is better than what it does now.  Having 2 separate places where plugin dependencies are expressed (application.properties and BuildConfig.groovy) is confusing and potentially problematic.  One benefit of the command is that you only need to know the name of the plugin you are installing.  You don't necessarily need to know a version number and you don't need to know the syntax to express in BuildConfig.groovy.  I don't think either of those 2 things are a big deal but some of our users disagree.

If the command is left in it should be made to modify some file that is well formed and easily modified by software.  BuildConfig.groovy kind of meets that criteria but not perfectly.  One complication is that the uninstall-plugin command.  Having it find and remove code from BuildConfig.groovy is problematic.

One thing we need to decide is how big of a deal is it if this command is removed altogether from Grails 2.3.  My own personal opinion on this is that it really isn't a big deal.  It demos well but for real application development it seems to offer so little.  Of course we welcome everyone's input.

How do you feel about this? (that is directed not just at Scott, but to the whole list)

Thanks for your input.



JSB

--
Jeff Brown
[hidden email]
SpringSource - A Division Of VMware
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/


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

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Proper plugin installation for 2.2

Jeff Brown-4
In reply to this post by bdrhoa

On Dec 28, 2012, at 12:34 PM, Brad Rhoads <[hidden email]> wrote:

> I'd like to see the command stay as a shortcut to updating buildconfig with the current release of a plugin.
>
> I think it would help people get started with Grails more easily.


This is something that we have to balance.  There are times when something demos well and appears to be helpful for hello world stuff but really isn't the best way to do things for real development.  For this one in particular, it seems to me that the command isn't justified for recent versions of Grails.  It made sense when all you could say about a plugin dependency was a plugin name and a plugin version.  

One limitation of the legacy approach is there is no way to express what scope the plugin dependencies should have.  You also can't express exclusions.  We could add some complexity to the command via arguments and maybe we could come up with a mechanism that can reliably modify BuildConfig.groovy (or similar) for install-plugin and uninstall-plugin but I don't feel like we are really buying much, if anything, with all of that.  

Having to type some stuff into a file isn't always a bad thing.  We don't have a command to make a service non-transactional.  We don't have a command for adding a new persistent property to a domain class.  We don't have a command for indicating which JDBC driver GORM should use.  We don't have a command for adding a new action to a controller. etc.  I don't think we should have a command for any of those things and with recent versions of Grails, that is how I feel about the install-plugin command.  I don't use the install-plugin command and don't think it is sensible at this point.

As always, we welcome everyone's input.

Thanks again.



JSB
--
Jeff Brown
[hidden email]
SpringSource - A Division Of VMware
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Proper plugin installation for 2.2

Ryan Vanderwerf
In reply to this post by Scott6666
One use I have for uninstall plugin command is unrelated to application.properties, but I have to run it sometimes switching from inline plugin mode during dev to artifactory buildconfig mode and vise versa. Would removing this affect inline plugin mode as well, since you can't specify scope there either?


Ryan


From my Android phone on T-Mobile. The first nationwide 4G network.



-------- Original message --------
From: Jeff Brown <[hidden email]>
Date: 01/01/2013 10:00 AM (GMT-06:00)
To: [hidden email]
Subject: Re: [grails-user] Proper plugin installation for 2.2



On Dec 28, 2012, at 12:34 PM, Brad Rhoads <[hidden email]> wrote:

> I'd like to see the command stay as a shortcut to updating buildconfig with the current release of a plugin.
>
> I think it would help people get started with Grails more easily.


This is something that we have to balance.  There are times when something demos well and appears to be helpful for hello world stuff but really isn't the best way to do things for real development.  For this one in particular, it seems to me that the command isn't justified for recent versions of Grails.  It made sense when all you could say about a plugin dependency was a plugin name and a plugin version. 

One limitation of the legacy approach is there is no way to express what scope the plugin dependencies should have.  You also can't express exclusions.  We could add some complexity to the command via arguments and maybe we could come up with a mechanism that can reliably modify BuildConfig.groovy (or similar) for install-plugin and uninstall-plugin but I don't feel like we are really buying much, if anything, with all of that. 

Having to type some stuff into a file isn't always a bad thing.  We don't have a command to make a service non-transactional.  We don't have a command for adding a new persistent property to a domain class.  We don't have a command for indicating which JDBC driver GORM should use.  We don't have a command for adding a new action to a controller. etc.  I don't think we should have a command for any of those things and with recent versions of Grails, that is how I feel about the install-plugin command.  I don't use the install-plugin command and don't think it is sensible at this point.

As always, we welcome everyone's input.

Thanks again.



JSB
--
Jeff Brown
[hidden email]
SpringSource - A Division Of VMware
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Proper plugin installation for 2.2

Ian Roberts
In reply to this post by Nicholas Wittstruck
On 01/01/2013 14:08, Nicholas Wittstruck wrote:
> I would also like to see the command removed.. Changing the BuildConfig
> is easy enough.

The current install-plugin script has two very distinct jobs

1) installing plugins by name from a repository
2) installing locally-built plugin .zip files that are not available in
any repository

I'm all in favour of dropping (1) as long as there is still some way to
do (2), which could be as simple as providing a way to configure a
directory as a suitable repository so you can drop
grails-my-plugin-1.2.3.zip in there and then depend on it in BuildConfig
in the usual way.

You can kind of do this already with a flatDir repository definition
(though you have to rename the zip files to my-plugin-1.2.3.zip instead
of grails-my-plugin-1.2.3.zip), the problem I've always had with that in
the past is that it never seemed to pick up new versions of a -SNAPSHOT
zip (i.e. same version number 1.2-SNAPSHOT but more recent modification
date) unless I cleaned the old zip out of the ivy cache and the .grails
dir.  If SNAPSHOT updates could be fixed for non-Maven repositories then
install-plugin can go.

> Since we are already discussing having 2 separate places where things
> can be declared - is it possible to get rid of the
> application.properties completely? Besides plugin dependencies, there
> are other configuration values as well (e.g. servlet version) that occur
> in multiple places. Is there any config value that can not be declared
> in (Build-)Config, but has to be in the application.properties?

Things like app.version and app.grails.version are very useful to have
in a location that is easily parseable without having to fire up the
whole of Grails, for example in a CI system.  I have several different
Grails applications that use different versions of Grails, and my
"grails" shell script is a wrapper that looks in application.properties
to determine the correct Grails version to use for each app.  Moving
this info into BuildConfig would create something of a chicken-and-egg
problem.

Ian

--
Ian Roberts               | Department of Computer Science
[hidden email]  | University of Sheffield, UK

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Proper plugin installation for 2.2

Owen Rubel
In reply to this post by Giancarlo Angulo
Well IMHO I say one should keep in mind that Grails is Java's answer to 'convention over configuration'... don't start moving backwards towards 'configuration over convention'. I'm for having the command create a proper setup but keep the command.

The command creates a simplified way for people to get 'up and running' but the current approach is broken. Make it so it builds them in the buildconfig properly but stills has a 'convention over configuration' approach' allowing a default way to build and setup but for people who need to 'tweak', they have that available to them.



On Tue, Jan 1, 2013 at 4:58 AM, Giancarlo Angulo <[hidden email]> wrote:

Kill the plugin

On Dec 28, 2012 2:51 AM, "Jeff Brown" <[hidden email]> wrote:

On Dec 27, 2012, at 9:01 AM, Scott Eisenberg <[hidden email]> wrote:

> The plugin pages have both Dependency instructions and Installation instructions.  If you do the install-plugin, the warning comes up to say don't do this.
>
> Is it sufficient to just put in the dependency or do you need to run the installation command line as well?
>
>
>
>

We are looking to either yank the command altogether or change its behavior in a future release.  See https://github.com/grails/grails-core/commit/3f106344380652c64f7390015535b24f4a252fc9

I think removing the command is better than what it does now.  Having 2 separate places where plugin dependencies are expressed (application.properties and BuildConfig.groovy) is confusing and potentially problematic.  One benefit of the command is that you only need to know the name of the plugin you are installing.  You don't necessarily need to know a version number and you don't need to know the syntax to express in BuildConfig.groovy.  I don't think either of those 2 things are a big deal but some of our users disagree.

If the command is left in it should be made to modify some file that is well formed and easily modified by software.  BuildConfig.groovy kind of meets that criteria but not perfectly.  One complication is that the uninstall-plugin command.  Having it find and remove code from BuildConfig.groovy is problematic.

One thing we need to decide is how big of a deal is it if this command is removed altogether from Grails 2.3.  My own personal opinion on this is that it really isn't a big deal.  It demos well but for real application development it seems to offer so little.  Of course we welcome everyone's input.

How do you feel about this? (that is directed not just at Scott, but to the whole list)

Thanks for your input.



JSB

--
Jeff Brown
[hidden email]
SpringSource - A Division Of VMware
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/


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

    http://xircles.codehaus.org/manage_email