Should I (and how do I) permanently get rid of the default Grails web-app files?

[tommarthenal]

When I create a Grails app, it comes with some default files in the web-app directory: 

$ find web-app 

web-app 

web-app/css 

web-app/css/errors.css 

web-app/css/main.css 

web-app/css/mobile.css 

web-app/images 

web-app/images/apple-touch-icon-retina.png 

web-app/images/apple-touch-icon.png 

web-app/images/favicon.ico 

web-app/images/grails_logo.jpg 

web-app/images/grails_logo.png 

web-app/images/leftnav_btm.png 

web-app/images/leftnav_midstretch.png 

web-app/images/leftnav_top.png 

web-app/images/skin 

web-app/images/skin/database_add.png 

web-app/images/skin/database_delete.png 

web-app/images/skin/database_edit.png 

web-app/images/skin/database_save.png 

web-app/images/skin/database_table.png 

web-app/images/skin/exclamation.png 

web-app/images/skin/house.png 

web-app/images/skin/information.png 

web-app/images/skin/shadow.jpg 

web-app/images/skin/sorted_asc.gif 

web-app/images/skin/sorted_desc.gif 

web-app/images/spinner.gif 

web-app/images/springsource.png 

web-app/js 

web-app/js/application.js 

(META-INF and WEB-INF folders snipped from output) 

These files create clutter in my app, and also use the common directory names css, images, and js, that I'm likely to want to use for my own resources. 

In the past I've manually deleted these, but they return by themselves after running grails upgrade, overwriting my own files in the process. 

I can't see any reason to keep these files around. Is there something I'm missing? If not, how can I get rid of them and make sure they never come back?

Tom

[Andrew Todd]

On Mon, Jul 16, 2012 at 7:14 PM, Tom Marthenal <[hidden email]> wrote:
> In the past I've manually deleted these, but they return by themselves after
> running grails upgrade, overwriting my own files in the process.

Thanks for mentioning this -- I had had to clear out the default files
after upgrade a couple of times, but didn't realize they would
overwrite anything else with the same name. Thank goodness for version
control.

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

    http://xircles.codehaus.org/manage_email

[OverZealous]

Andrew Todd wrote:

On Mon, Jul 16, 2012 at 7:14 PM, Tom Marthenal <[hidden email]> wrote:

In the past I've manually deleted these, but they return by themselves after running grails upgrade, overwriting my own files in the process.

Thanks for mentioning this -- I had had to clear out the default files after upgrade a couple of times, but didn't realize they would overwrite anything else with the same name. Thank goodness for version control.

I agree, I think the default Grails web files should not be written (at all) except on creating a new project, or by a special command, like "upgrade-web-app-files".

Luckily, a good VCS lets you see what's added, and remove them in one swoop.

-- 

[Paolo DiCanio]

I'd also be interested to know if there's any way to prevent these from rising from the dead like zombies every time you upgrade to a new version of Grails.

[burtbeckwith]

Don't run 'grails upgrade' and they won't come back.

For small version increases (e.g. 2.0.2 -> 2.0.3 or 2.0.4) edit application.properties and change the version. Then run 'grails clean' followed by 'grails compile' and it'll ask you if you want to upgrade the Hibernate and Tomcat plugins (if they're listed in BuildConfig.groovy). You can also manually delete the old plugins in the work folder under the $HOME/.grails folder.

It's even simpler if you add "grails.project.work.dir = 'target'" to BuildConfig.groovy. Then all your plugins will be there and you can just delete the whole target folder and all the plugins will be reinstalled and/or updated, and all the classes will be recompiled.

For bigger upgrades, e.g. 1.3 -> 2.1, use the 3-way diff approach I've described a few times before:
- create a new empty app in the new version of Grails
- create a new empty app in the old version of Grails
- diff your current app with the empty old-version app - this will tell you what you deleted, added, and changed. Copy new files over, delete stuff that should be deleted, and re-do the changes you made. Be sure to read the release notes and upgrade information for the intermediate Grails versions so you know how to make the new changes - e.g. HSQLDB -> H2 in DataSource.groovy, etc. Don't just blindly make the same changes.

Once you're done with this it probably won't be 100%, but you can run your tests to find remaining issues. Once you're ok with the new app, make it your real app and delete the old one. The old stuff will still be in source control.

Burt

Paolo DiCanio wrote

I'd also be interested to know if there's any way to prevent these from rising from the dead like zombies every time you upgrade to a new version of Grails.

[OverZealous]

Thanks for providing us with a solution Burt.  It does lead me to some thoughts & questions about the upgrade process.

• Why is there a grails upgrade command if it's not the right way to upgrade a project?  Maybe it should be deprecated, or even removed.
• The doc page for the upgrade command is too sparse.  It provides no information what it does, or when it should be called, or that it might overwrite files.  (And I still say it should never overwrite files.)
• Your technique should be documented at the top of the Upgrading from previous versions of Grails page.
• The "small version increases" method seems like a needlessly complicated way to upgrade grails, especially if there is an existing, broken, and ineffective grails upgrade command that could be modified to be better.  If a simple upgrade is merely bump the version, clean and compile, then shouldn't the command line action be changed to do just that?  It could even offer to open the manual to the "Upgrading..." page to help list changes.  It could error out if the upgrade is between major versions.
• You mention 2.0.x and 1.x -> 2.x upgrades, but would 2.0 -> 2.1 be considered minor?  Just a nitpick, but I think a valid one.  Looking at the changes in the docs, it probably is minor, of course.  However, these sorts of things get people into trouble if it isn't clearly defined.

This is right up there with the install-plugin command, which is no longer recommended, but still exists, even though there's no reason for it.  I think these old-but-not-recommended kind of commands are confusing for new developers, especially since they have names that seem like the obvious choice.

- Phil DeJarnett

burtbeckwith wrote:

Don't run 'grails upgrade' and they won't come back.

For small version increases (e.g. 2.0.2 -> 2.0.3 or 2.0.4) edit
application.properties and change the version. Then run 'grails clean'
followed by 'grails compile' and it'll ask you if you want to upgrade the
Hibernate and Tomcat plugins (if they're listed in BuildConfig.groovy). You
can also manually delete the old plugins in the work folder under the
$HOME/.grails folder.

It's even simpler if you add "grails.project.work.dir = 'target'" to
BuildConfig.groovy. Then all your plugins will be there and you can just
delete the whole target folder and all the plugins will be reinstalled
and/or updated, and all the classes will be recompiled.

For bigger upgrades, e.g. 1.3 -> 2.1, use the 3-way diff approach I've
described a few times before:
- create a new empty app in the new version of Grails
- create a new empty app in the old version of Grails
- diff your current app with the empty old-version app - this will tell you
what you deleted, added, and changed. Copy new files over, delete stuff that
should be deleted, and re-do the changes you made. Be sure to read the
release notes and upgrade information for the intermediate Grails versions
so you know how to make the new changes - e.g. HSQLDB -> H2 in
DataSource.groovy, etc. Don't just blindly make the same changes.

Once you're done with this it probably won't be 100%, but you can run your
tests to find remaining issues. Once you're ok with the new app, make it
your real app and delete the old one. The old stuff will still be in source
control.

Burt


Paolo DiCanio wrote

I'd also be interested to know if there's any way to prevent these from

rising from the dead like zombies every time you upgrade to a new version

of Grails.

[burtbeckwith]

All good points. The problem with removing install-plugin is that in general plugin dependencies should be registered in BuildConfig.groovy, there are still uses for install-plugin, in particular installing from a local or remote zip file. It would be ideal in the general case for install-plugin to find the current version of the plugin and edit BuildConfig.groovy for you, but that's a non-trivial problem since it requires creating a parser (simple things like comments greatly complicate a naive implementation).

We've discussed deprecating and eventually removing the upgrade script since this is a very hard thing to automate and do well. We'll likely end up with a couple of smaller scripts that just do the simpler bits like updating the version string and plugin dependencies.

Burt

OverZealous wrote

Thanks for providing us with a solution Burt.  It does lead me to some thoughts & questions about the upgrade process.

Why is there a grails upgrade command if it's not the right way to upgrade a project?  Maybe it should be deprecated, or even removed.
The doc page for the upgrade command is too sparse.  It provides no information what it does, or when it should be called, or that it might overwrite files.  (And I still say it should never overwrite files.)
Your technique should be documented at the top of the Upgrading from previous versions of Grails page.
The "small version increases" method seems like a needlessly complicated way to upgrade grails, especially if there is an existing, broken, and ineffective grails upgrade command that could be modified to be better.  If a simple upgrade is merely bump the version, clean and compile, then shouldn't the command line action be changed to do just that?  It could even offer to open the manual to the "Upgrading..." page to help list changes.  It could error out if the upgrade is between major versions.
You mention 2.0.x and 1.x -> 2.x upgrades, but would 2.0 -> 2.1 be considered minor?  Just a nitpick, but I think a valid one.  Looking at the changes in the docs, it probably is minor, of course.  However, these sorts of things get people into trouble if it isn't clearly defined.

This is right up there with the install-plugin command, which is no longer recommended, but still exists, even though there's no reason for it.  I think these old-but-not-recommended kind of commands are confusing for new developers, especially since they have names that seem like the obvious choice.

- Phil DeJarnett

[OverZealous]

I understand the issue with automatically modifying BuildConfig.groovy — and I'll admit I had a fleeting thought "why can't it just add it to the right place".  This is, of course, one of those give-and-take situations with DSLs — they are usually easier for humans to read and write, but software is effectively limited to read only mode.

I think a great step in "fixing" the upgrade process is documentation on the two pages I noted.  :-)

- Phil DeJarnett

burtbeckwith wrote:

> All good points. The problem with removing install-plugin is that in general
> plugin dependencies should be registered in BuildConfig.groovy, there are
> still uses for install-plugin, in particular installing from a local or
> remote zip file. It would be ideal in the general case for install-plugin to
> find the current version of the plugin and edit BuildConfig.groovy for you,
> but that's a non-trivial problem since it requires creating a parser (simple
> things like comments greatly complicate a naive implementation).
>
> We've discussed deprecating and eventually removing the upgrade script since
> this is a very hard thing to automate and do well. We'll likely end up with
> a couple of smaller scripts that just do the simpler bits like updating the
> version string and plugin dependencies.
>
> Burt

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

    http://xircles.codehaus.org/manage_email

[Ian Roberts]

On 18/07/2012 06:38, burtbeckwith wrote:
> All good points. The problem with removing install-plugin is that in general
> plugin dependencies should be registered in BuildConfig.groovy, there are
> still uses for install-plugin, in particular installing from a local or
> remote zip file.

Maybe the best compromise would be to keep install-plugin working as it
currently does if it is called with an argument ending ".zip" but error
out if called with a plain plugin name, maybe suggesting what you should
add to BuildConfig instead?

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

[Roberto Guerra]

+1 to Ian's suggestion.

On Wed, Jul 18, 2012 at 4:43 AM, Ian Roberts <[hidden email]> wrote:

On 18/07/2012 06:38, burtbeckwith wrote:
> All good points. The problem with removing install-plugin is that in general
> plugin dependencies should be registered in BuildConfig.groovy, there are
> still uses for install-plugin, in particular installing from a local or
> remote zip file.

Maybe the best compromise would be to keep install-plugin working as it
currently does if it is called with an argument ending ".zip" but error
out if called with a plain plugin name, maybe suggesting what you should
add to BuildConfig instead?

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

--
The Journey Is The Reward.

[eeno]

On Wednesday, July 18, 2012 01:44:33 AM Phil DeJarnett wrote:
> I think a great step in "fixing" the upgrade process is
> documentation on the two pages I noted.  :-)
>

Agreed!

Particularly:

* "The doc page for the upgrade command is too sparse.  It provides
no information what it does, or when it should be called, or that it
might overwrite files."

* "Your technique should be documented at the top of the Upgrading
from previous versions of Grails page."

* "This is right up there with the install-plugin command, which is no
longer recommended, but still exists, even though there's no reason
for it.  I think these old-but-not-recommended kind of commands are
confusing for new developers, especially since they have names that
seem like the obvious choice."



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

    http://xircles.codehaus.org/manage_email

[tommarthenal]

I would really like to see better documentation on install-plugin and upgrade; I just started using Grails a few months ago, and have been using those commands at all times. This is the first I've heard that they're not recommended.