How to get STS to accept updated grails 2.0.0.BUILD-SNAPSHOT?

[wstidolph]

I am using STS 2.8.0M2 (nightlies) and grails-core from github (building to 2.0.0.BUILD-SNAPSHOT) so I have frequent changes to the items in the grails classpath container ("com.springsource.sts.grails.core.CLASSPATH_CONTA INER") ... and, I often don't seem to get a clean update on that STS classpath container. So, what's the right way to let STS know I've updated the grails installation?

For example, I just updated grails-core and the new install now supplies groovy-all-1.8.3.jar, not the groovy-all-1.8.3-SNAPSHOT.jar, but I get build path errors:

The archive: /home/wstidolph/src/grails-core/lib/org.codehaus.groovy/groovy-all/jars/groovy-all-1.8.3-SNAPSHOT.jar which is referenced by the classpath, does not exist.

Incidentally, that file does not show in the Build Path -> Libraries -> Grails Dependencies list; the new (correct) 1.8.3 shows.

Or sometimes I'll get complaints about missing links:

/home/wstidolph/.grails/2.0.0.BUILD-SNAPSHOT/projects/qdjoint/plugins/jquery-1.6.1.1/grails-app/taglib/JQueryResourceTagLib.groovy

Or:

| Loading Grails 2.0.0.BUILD-SNAPSHOT
| Configuring classpath.
| Environment set to development.....
| Error Fatal error during compilation org.codehaus.groovy.control.MultipleCompilationErr orsException: startup failed:
/home/wstidolph/.grails/2.0.0.BUILD-SNAPSHOT/projects/qdjoint/plugins/resources-1.0.2/./ResourcesGrailsPlugin.groovy: 6: unable to resolve class org.grails.plugin.resource.util.HalfBakedLegacyLin kGenerator
@ line 6, column 1.
import org.grails.plugin.resource.util.HalfBakedLegacyLin kGenerator
^
(followed by a bunch more "unable to resolve" on plugin-supplied classes)

The effects and what works to cure them seem to vary from update to update, but the one this morning is ugly, I haven't been able to recover ... so I'm wondering what's the "right" way to update a grails installation and get STS to abandon the previous grails container?

Things I've tried, without success (in many permutations):

• in grails-core, doing ./gradlew clean as well as ./gradlew install (because I thought the STS classpath container would be dynamically built against the grails installation)
• STS Project clean
• grails clean (both from STS Grails Tools->Grails command prompt context menu and from command line)
• STS Grails Tools -> Refresh Dependencies
• STS Grails Tools disable/re-ennable dependency management and then refresh deps
• restarting STS
• deleting STS project and re-importing (from git, with a working directory not in the Workspace project itself)
• switching between grails installs (BUILD-SNAPSHOT and 2.0.0.M2)
• deleting the ~/.grails/2.0.0.BUILD-SNAPSHOT tree
• deleting grails install in STS Groovy->Grails prefs and re-adding (the same location)
• rebuilding project classpath with 'grails integrate-with -eclipse'
• removing and reinstalled grails extension to STS (presently:STS Version: 2.8.0.SNAPSHOT Build Id: 201110140724 grails plugin 2.8.0.201110140724-SNAPSHOT)

Now, I can start a *new* grails project and it's OK, so I suppose I can start a project and copy/paste everything over ... but that seems silly and not something to do every day as I test the updated STS and/or grails-core - any suggestions, what am I missing?

[Kris De Volder]

Hi,

Unfortunately I don't really have a good answer for you. You have listed just about every possible 'refresh' action conceivable.

From STS point of view, doing a 'Grails Tools >> refresh dependencies' refreshes just about everything classpath related on the STS side. If it works right
that should refresh the dependencies in 'Build Path -> Libraries -> Grails Dependencies' as well as the list of plugins and links to plugin source folders.

However, whether this works right in large part depends on Grails itself returning the right information to STS when we call on it.

Since you are working with a 'snapshot' of grails, you should expect some instability...

One thing you haven't done which may be worth doing is to build a proper grails zip distribution:

./gradlew clean zipDist

Then unzip the produced distribution zip. Then configure that as your grails install in STS (Preferences >> Groovy >> Grails)

I'd always recommend using a distiribution zip as it is that type of distribution STS expects. I don't think an install
produced by ./gradle clean install is quite equivalent (layout not quite the same, some stuff may be missing etc.).

Some specific comments to what you wrote:

For example, I just updated grails-core and the new install now supplies groovy-all-1.8.3.jar, not the groovy-all-1.8.3-SNAPSHOT.jar, but I get build path errors:

The archive: /home/wstidolph/src/grails-core/lib/org.codehaus.groovy/groovy-all/jars/groovy-all-1.8.3-SNAPSHOT.jar which is referenced by the classpath, does not exist.

"Grails Tools >> Refresh Dependencies" should fix that, if it doesn't, it is because Grails itself is incorrectly telling STS to use the wrong jar file.

Or sometimes I'll get complaints about missing links:

/home/wstidolph/.grails/2.0.0.BUILD-SNAPSHOT/projects/qdjoint/plugins/jquery-1.6.1.1/grails-app/taglib/JQueryResourceTagLib.groovy

Same as above "Refresh Dependencies" should remedy this.

| Loading Grails 2.0.0.BUILD-SNAPSHOT
| Configuring classpath.
| Environment set to development.....
| Error Fatal error during compilation org.codehaus.groovy.control.MultipleCompilationErr orsException: startup failed:
/home/wstidolph/.grails/2.0.0.BUILD-SNAPSHOT/projects/qdjoint/plugins/resources-1.0.2/./ResourcesGrailsPlugin.groovy: 6: unable to resolve class org.grails.plugin.resource.util.HalfBakedLegacyLin kGenerator
@ line 6, column 1.
import org.grails.plugin.resource.util.HalfBakedLegacyLin kGenerator
^
(followed by a bunch more "unable to resolve" on plugin-supplied classes)

This is most definitely a grails problem since these are messages printed by Grails itself. If this is in the 'grails compile' command that STS is running in service of its refresh dependencies function, then failure of this command also means that the STS refresh dependencies function will not work. Until the grails compile command can run succesfully, STS cannot update its dependency information.

So in this case you somehow have to make grails own state cleaned up. Stuff like "grails clean" and deleting the ${user.home}/.grails folder are good things to try.

* deleting grails install in STS Groovy->Grails prefs and re-adding (the same location)

I don't think that will do very much. I'd recommend actually making sure you build a fresh distribution (./gradlew zipDist) each time you build a new grails snapshot.

* rebuilding project classpath with 'grails integrate-with -eclipse'

This probably does more harm than good. It will blow away all STS/eclipse configuration replacing them with some stuff generated by Grails itself. This isn't quite equivalent to what STS would produce. The stuff generated there is more intended for use without specific grails tool support in a plain eclipse install.

* removing and reinstalled grails extension to STS (presently:STS Version: 2.8.0.SNAPSHOT Build Id: 201110140724 grails plugin 2.8.0.201110140724-SNAPSHOT)

That shouldn't be necessary, and I'd be very surprised if fixed problems with your project's state. (Grails project state is stored inside your project folder and inside the .grails folder, neither of which will be affected by reinstalling STS tooling.)

If you have more questions about specific errors and suggested course of action... please ask.

[Kris De Volder]

Just adding a quick clarification to my last comment.

Of course, it *is* a good idea to get a recent version of STS 2.8.0 snapshot from the nightly update site. I just meant to say that it probably doesn't do much to uninstall and reinstall the *same* version of the STS grails tooling. Upgrading to a newer snapshot is a different matter.

[wstidolph]

'zipDist fixed it for me; thank you for the answer and the informative/careful responses to my tedious list

One question: if I've generated a grails app outside of STS, what is the way to bring it into STS and get "all STS/eclipse configuration" that isn't provided by integerate-with? Is that handled during an 'import' or do I need to remove the existing .project and .classpath files first?

[Kris De Volder]

If you import the project using the standard eclipse import wizard via

"File >> Import >> Existing Projects into workspace"

that should work.

As soon as a new project appears in the workspace, STS has a workspace listener that detects it 'looks like' a grails project. It will check the project and will offer to configure it for you if it doesn't look correctly configured.

Caveat... this 'fixer' is a bit complex. I wouldn't be totally surprised if it misbehaved. If that is the case (i.e. you find that you import a nice working project and it ends up in some broken state) then please report that as an issue (on this forum or Jira issue tracker) and I will look into how we can make the 'import fixer' better at what its supposed to do (as well as try to help you with a workaround to fix your project manually).

Kris