Best practices for Grails plugin management?

[markphip]

I have a Grails application stored in a SVN repository. I want to add the Eclipse .project and .classpath files to the repository to make it easier for team members to checkout the project in STS and get started. The problem is that all of the Grails plugins used by the application are added to the application as Linked Resources with hard-coded paths in the .project file. This makes the file not very useful to share with a team.

I am currently working around the problem by hand editing the .project file to replace references like this:

<location>/users/mphippard/.grails/1.1.1/projects/AppName/plugins/acegi-0.5.1/src/groovy</location>

with this:

<locationURI>GRAILS/projects/AppName/plugins/acegi-0.5.1/src/groovy</locationURI>

In other words, I have created a Linked Resource variable named GRAILS that I can locally point to my home folder and other developers can do the same. Is there any better way to do this? A problem is that whenever a new plugin is added and dependencies are refreshed the hard-coded paths will be written to the file for the new plugin.

Even if this is the best way, couldn't a singled linked resource be added that points to the project plug-ins folder? Then there would only be one entry in the .project file and it would not need to be modified when plugins are refreshed.

The entries in .classpath are not hard coded but they clearly work with the ones in .project. Not sure if they would have problems if there was only a single linked resource. I do not think there would be a problem.

For example, suppose the .project file was changed to have a single entry like this:

<link>
<name>grails-plugins</name>
<type>2</type>
<locationURI>GRAILS/projects/AppName/plugins</locationURI>
</link>

So this links to the plugins folder for the application. In the .classpath file, couldn't you now have entries like this?

<classpathentry kind="src" path="grails-plugins/acegi-0.5.1/src/groovy">
<attributes>
<attribute name="com.springsource.sts.grails.core.SOURCE_FOLD ER" value="true"/>
</attributes>
</classpathentry>

This seems cleaner because now only the .classpath file needs to be modified when new dependencies are added, and the only hard-coding is in the .project file and this can be replaced by a variable.

Thanks

Mark

[Christian Dupuis]

Mark,

can you take a look at the following JIRA and see if that suits your needs:

STS-716: As a Grails STS user, I want that .project (and .classpath) files could be shared with other team members via version control (so that they don't include user specific directory paths)
https://issuetracker.springsource.com/browse/STS-716

Christian

[markphip]

In the issue, you state:

"This is now added. STS will now use the most specific path from the Linked Resources configuration."

I am not sure what that means. Does that mean you now just add a single Linked Resource path so that the user only has to manually convert that single path to use a variable?

Or does it mean something else, like you are looking to see if a user has created a variable, and if they have you use it?

Mark

[Christian Dupuis]

Mark,

sorry for the confusion.

That means that STS will now use a Linked Resource variable from the workspace settings if any is configured and the path is a prefix of the patch of he dependency.

If no variable is defined or matches that path it will continue to use absolute paths in the .project file.

Does that make sense?

Christian

[markphip]

That means that STS will now use a Linked Resource variable from the workspace settings if any is configured and the path is a prefix of the patch of he dependency.

If no variable is defined or matches that path it will continue to use absolute paths in the .project file.

Does that make sense?

It does, thanks. So as long as all users define the same variables then it should continue to use those and the files will not need to be hand-edited.

I still think there would be some value in also looking at my suggestion about how the values could be handled differently. You would still need the variable, but by reducing the Linked Resource to a single entry it would reduce the churn of changes needed when new plugins are added to just modifications to the .classpath file. Given that this is also what an Eclipse Java project has to go through, there would seem to be little objections if it worked that way.

It would also reduce the impact of one team member who does not setup their environment correctly and then commits a change to the .project file that wipes out the variables.

Thanks for fixing the problem.

Mark