Managing plugins with Grails 1.3

Posted on May 18th, 2010 by Peter Ledbrook in Groovy/Grails.

For a long time, managing Grails dependencies simply meant putting them in your application's lib directory. Then came Grails 1.2 and the dependency DSL: you could finally declare your dependencies and have Grails automatically download them and make them available to your app. Great!

Now, Grails 1.3 has brought the dependency DSL to the realm of plugins.

So what?

Users have often faced two issues with the plugin system up till now:

setting up a suitable Subversion server to act as a Grails plugin repository is not simple; and
you can't control what dependencies a plugin brings into your application.

The first of these doesn't particularly apply to individual developers, but it's a bigger deal for companies where access to the internet may be restricted or where they want more control over the "latest" versions of libraries and plugins. How much better it would be if they could use a repository manager like Nexus or Artifactory.

As for the dependencies, some plugins include libraries you don't need or (even worse) break your application. With the dependency DSL, you can explicitly exclude problematic libraries.

Those are some of the reasons why this change might be important to you. So how do you use the new feature?

The dependency two-step

To properly demonstrate the utility of Grails' dependency management, we must set up a local repository. For this article, we'll use Artifactory. You could equally use Nexus or any other tool for creating Maven-compatible repositories.

I'll assume that Artifactory is already installed and running – for details of getting to this stage, check out its website and in particular the "One minute Artifactory" screencast. At this point we have a local repository, but it's not serving any artifacts yet. Let's fix that.

I'm going to add the 'db-util' plugin and the 'commons-digester' library. You can try with any plugins or JARs you have available. Simply navigate to the 'Deploy' tab of Artifactory (having logged in with username "admin", password "password"), choose the appropriate files, and upload them. I grabbed the files:

    $USER_HOME/.ivy2/cache/commons-digester/commons-digester/jars/commons-digester-2.0.jar
    $USER_HOME/.grails/1.2.1/plugins/db-util-0.4.zip

and added them via the Artifactory UI:

Note that the UI allows you to specify the target repository for the upload. I chose 'plugins-releases-local' for the 'db-util' plugin and 'libs-releases-local' for 'commons-digester'. Also, before committing the plugin artifact, I set its groupId to 'org.grails.plugins' and its artifactId to 'db-util' (the default values are both 'grails-db-util'). The 'org.grails.plugins' groupId is the one that Grails assumes for plugin dependencies. Note also how the artifactId doesn't include the "grails-" prefix.

Those two artifacts are now available locally to any of your Grails applications. Now we need to configure the repository and dependencies in our Grails application.

The dependency DSL

The next bit is surprisingly straightforward. We need to do two things:

configure Grails to download plugins and JARs from our Artifactory repository; and
specify our dependencies.

Just as with Grails 1.2, this is done in the grails-app/conf/BuildConfig.groovy. Here are the relevant sections in a sample Grails application:

grails.project.dependency.resolution = {
    ...
    log "warn"
    repositories {
        grailsPlugins()
        grailsHome()
        mavenRepo "http://localhost:8081/artifactory/libs-releases-local/"
        mavenRepo "http://localhost:8081/artifactory/plugins-releases-local/"
        grailsCentral()
    }
    plugins {
        build "org.grails.plugins:db-util:0.4"
    }
    dependencies {
        compile "commons-digester:commons-digester:2.0"
    }
}

So, in the repositories section you add a mavenRepo entry for each "repository" exposed by the Artifactory server. Note that in this case, we add both the 'libs-releases-local' repository and the 'plugins-releases-local' one.

The new addition to the DSL is the plugins section, which is (unsurprisingly) for declaring Grails plugins. It has exactly the same syntax as the dependencies section. So, 'db-util' is declared under plugins and 'commons-digester' is declared under dependencies.

That's all you have to do. If you now execute grails run-app, you'll see the some output like this:

...
Resolving dependencies...
Downloading: http://localhost:8081/artifactory/libs-releases-local/commons-digester/commons-digester/2.0/commons-digester-2.0.pom ...
Download complete.
Downloading: http://localhost:8081/artifactory/libs-releases-local/commons-digester/commons-digester/2.0/commons-digester-2.0.pom.sha1 ...
Download complete.
...
Downloading new plugins. Please wait... ...
Downloading: http://localhost:8081/artifactory/plugins-releases-local/org/grails/plugins/db-util/0.4/db-util-0.4.pom ...
Download complete.
Downloading: http://localhost:8081/artifactory/plugins-releases-local/org/grails/plugins/db-util/0.4/db-util-0.4.pom.sha1 ...
Download complete.
Downloading: http://localhost:8081/artifactory/plugins-releases-local/org/grails/plugins/db-util/0.4/db-util-0.4.zip ...
Download complete.
Downloading: http://localhost:8081/artifactory/plugins-releases-local/org/grails/plugins/db-util/0.4/db-util-0.4.zip.sha1 ...
Download complete.
Installing zip /home/pal20/.ivy2/cache/org.grails.plugins/db-util/zips/db-util-0.4.zip...
...

The 'db-util' plugin is installed and the 'commons-digester' JAR included on the classpath. Simple.

If you run into issues with the dependency resolution, then you can dial up the logging by replacing the log "warn" line in BuildConfig.groovy with log "info" or even log "debug".

Of course, sometimes you will want to host your own plugins or customised/patched versions of public one. The existing release-plugin command only works with old-style Subversion repositories, so what can you do?

Publishing plugins to Maven-compatible repositories

Grails core doesn't help here, but then it doesn't need to. There is a Grails plugin dedicated to publishing Grails applications and plugins to Maven-compatible repositories: the Maven Publisher Plugin.

Install this in your plugin project, add the following entry to your BuildConfig.groovy file:

grails.project.dependency.distribution = {
    remoteRepository(id: "pluginSnapshots", url: "http://localhost:8081/artifactory/plugins-snapshots-local/") {
        authentication username: "admin", password: "password"
    }
}

and then run
grails maven-deploy --repository=pluginSnapshots
Voila! Your plugin will be deployed to the local Artifactory 'plugins-snapshots-local' repository with a groupId of org.grails.plugins. Note that the value you pass for the --repository argument should match the 'id' of a remote repository defined in the grails.project.dependency.distribution closure in BuildConfig.groovy.

You can fine tune the deployment, for example by using a pom.xml file with a <distributionManagement> element or by adding a groupId property to the plugin descriptor, but the basic steps are all straightforward.

All that's left to explain is where the dependency information is held. For example, the dependencies for normal artifacts (such as JAR libraries) are stored in a metadata file like pom.xml. Grails plugins are different. Their JAR dependencies are inside the zip package in a dependencies.groovy file. As for plugin dependencies, you define these as before in the dependsOn field in the plugin descriptor. These are then translated into dependency declarations in your plugin's generated pom.xml file (which is stored alongside the plugin zip file in the repository).

And that really is all there is to it. You can now provide your own, easy-to-manage Maven-compatible repository so that your team members no longer have to hit the internet every time they need a plugin or dependency. You can also inject some consistency into your projects by controlling which versions of Grails plugins are available. And you can easily patch public plugins and make those versions available to your team locally, while you wait for the fixes to make it into an official release.

37 responses

Scott Frederick says:
Added on May 18th, 2010 at 11:12 am

This declarative style of plugin management is very nice, and provides much better control than simply listing plugins in application.properties. I think this (along the dependencies management added in 1.2) is a big step forward in managing a Grails app.

There is one area where the documentation on this new feature (http://grails.org/doc/1.3.x/guide/3. Configuration.html#3.7.9 Plugin Dependencies) is not completely clear: how does the new "plugins" section of BuildConfig.groovy interact with the "plugins." entries in application.properties?

As I understand it from inference and some quick experiments, the plugins management in BuildConfig.groovy is a complete replacement for the plugin entries in application.properties. Is this correct?

Taking this further, when converting a Grails app from 1.1.x or 1.2.x to 1.3, you can move all "plugins." entries in application.properties to the "plugins" section of BuildConfig.groovy, correct?. After this, you would add, remove, and upgrade plugins by simply editing BuildConfig.groovy, and never use "grails install-plugin" or "grails uninstall-plugin" again.

Is it possible (or recommended) to mix the two approaches to plugin management? Can the results of mixing the approaches be predicted (i.e. is the code designed to handle this scenario), or might strange things happen?

It would be good if the Grails documentation could be updated to give the full picture of plugin management. As it is, the new Plugin Dependencies section in the documentation makes only fleeting mention of "install-plugin" command, and the documentation for "install-plugin" makes no mention of BuildConfig.groovy and the new way of managing plugins.
dudel says:
Added on May 18th, 2010 at 12:05 pm

It would be *super* if you would let the STS team know about this as well…
Yesterday I spent a few hours trying to convince STS 2.3.2 to get going with grails 1.3.1 and the spring-security-core sample but what a waste of time. Then I popped it into IntelliJ and everything just worked.
Every couple of months I am checking out STS and its quality never fails to disappoint. Such a shame in comparison to the other great components…
Andy Clement says:
Added on May 19th, 2010 at 10:07 am

@Dudel: I'm afraid not enough testing was done around STS and Grails 1.3 and a problem crept through related to dependency management. It has now been fixed and we're looking to push that fix out as soon as possible.

Andy
—-
Andy Clement
SpringSource
dudel says:
Added on May 19th, 2010 at 10:16 am

Thanks. Great to hear!
Andy Clement says:
Added on May 19th, 2010 at 5:10 pm

Me again. Instructions to pickup that fix for grails 1.3 on STS are here:

http://tinyurl.com/342bvba

hope they work for you,
Andy
dudel says:
Added on May 20th, 2010 at 6:38 am

Hi Andy. Getting an error trying to install. I think it wants me to go to STS 2.3.3. Don't really want to 'upgrade' to a milestone from a release right now so I guess will have to wait till the next maintenance release.

Your original request has been modified.
"SpringSource Tool Suite Grails Support" is already installed, so an update will be performed instead.
Cannot complete the install because one or more required items could not be found.
Software being installed: SpringSource Tool Suite Grails Support 2.3.3.201005180035-M1 (com.springsource.sts.grails.feature.group 2.3.3.201005180035-M1)
Missing requirement: SpringSource Tool Suite (required) 2.3.3.201005180035-M1 (com.springsource.sts.feature.group 2.3.3.201005180035-M1) requires 'com.atlassian.connector.eclipse.jira.feature.group [2.1.0,3.0.0)' but it could not be found
Cannot satisfy dependency:
From: SpringSource Tool Suite Grails Support 2.3.3.201005180035-M1 (com.springsource.sts.grails.feature.group 2.3.3.201005180035-M1)
To: com.springsource.sts.feature.group [2.3.3,2.4.0)
Andy Clement says:
Added on May 20th, 2010 at 2:06 pm

Hi – I've updated the instructions at that link with some that will work for 2.3.2. It will do a partial upgrade of your STS to 2.3.3.M1, but should only pick up the minimal set of pieces you need.

Andy
Mike says:
Added on May 25th, 2010 at 7:54 pm

Scott Frederick – you are right, the doco is not clear. I'm surprised more people aren't asking questions about this. I'm fighting with Intellij as it wants the plugins in application.properties but things aren't working so well like that. Are the 2 approaches mutually exclusive?
Peter Ledbrook (blog author) says:
Added on May 26th, 2010 at 1:34 am

@Scott Sorry, I completely missed your comment. The two approaches are interchangeable, as witnessed by the fact that Hibernate and Tomcat are installed in the traditional way while you can add other plugins via the dependency DSL.

Ideally, you would use either one or the other, but you could use install-plugin for public plugins while using the dependency DSL for private plugins on an internal Maven-compatible repository.

I'll take a look at the docs and make some changes to hopefully make things clearer.

@Mike Grails 1.3.1 seems happy with having a plugin declared in the dependency DSL and application.properties. I can't speak for IntelliJ I'm afraid. I would ask JetBrains.
John Rellis says:
Added on June 1st, 2010 at 5:52 am

This post is gold… thanks! Currently I have a project with 2 inline plugins and am thinking about spending some time getting a repo set up.. this will help me a lot.. although I may need to go with the SVN option for now as all our projects are not yet on Grails 1.3.
Thanks again!
Ryan Vanderwerf says:
Added on June 22nd, 2010 at 11:20 am

Hi, I'm trying to follow the example of publishing my plugin to my local artifactory setup.

I for the life of me can't figure out how to get past this 401 error. I tried turning authentication off, allowing anonymous, no dice.

grails.project.dependency.distribution = {
remoteRepository(id: "pluginReleases", url: "http://mylocalrepo.com:8080/artifactory/plugins-releases-local/") {
authentication username: "dev", password:'1234'
}
}

Then I run grails 'maven-deploy –repository=pluginRelease'

I get a 401 error after it tried to upload the file. Also another oddity, I set my plugin version 'grails set-version 0.2'. When I maven-deploy, it still tries to upload the file-0.1.zip to the server. Is that a bug or do I need to do something else to increment the version?
Ryan Vanderwerf says:
Added on June 22nd, 2010 at 12:50 pm

correction on my last comment. Should read:

Then I run grails 'maven-deploy –repository=pluginReleases'
Peter Ledbrook (blog author) says:
Added on June 23rd, 2010 at 2:37 am

@Ryan I can answer the version question easily: set-version only changes the version number in application.properties, but that only applies to Grails applications. To change the version of a plugin project, you must modify the version property in the plugin descriptor, i.e. MyGrailsPlugin.groovy.

The 401 is confusing. I would look at the Artifactory logs. They can be quite helpful and may shed some light on this. What happens if you go to the http://mylocalrepo.com:8080/artifactory/plugins-releases-local/ URL with a browser? Does it prompt for username and password? Also, the Maven Publisher plugin pushes files via WebDAV if I remember correctly, so you could try mounting the Artifactory URL as a WebDAV filesystem.
Ryan Vanderwerf says:
Added on June 23rd, 2010 at 1:38 pm

Thanks for the response Peter! Yes when I go to that url I can access it no passwords. I've given up for that for now, and just manually uploaded my files to artifactory. What I'm really excited about is moving a lot of my common dependencies into a grails plugin, that is served up to our dev's from artifactory. However there seems to be a blocker in grails 1.3.2 that prevents it from finding the plugin from artifactory. If you see my comments I added to the JIRA it seems to not even try to hit Artifactory. I'm curious, what version of grails were you using when you tested this?

Also trying to post here has become a bit wonky – this is my third try, not sure what's going on.
Lee Wexler says:
Added on June 23rd, 2010 at 4:11 pm

Peter:

Isn't it a bug that set-version doesn't change the version property in MyGrailsPlugin.groovy?

Lee
Peter Ledbrook (blog author) says:
Added on June 24th, 2010 at 3:36 am

@Ryan I was using 1.3.1 when I wrote this article. Unfortunately, plugin dependencies via the DSL did break in 1.3.2, but we hope to have that fixed soon.

@Lee Perhaps, although it will likely remain that way for a while. The trouble is, it's difficult to update the text in a source file (*GrailsPlugin.groovy) unless there are rigid restrictions on the formatting or you modify the abstract syntax tree.

It's also confusing for people that the plugin's application.properties file contains a version, but it's simply ignored. Hopefully for Grails 2 things will be more consistent between applications and plugins. One thing we could do is modify set-version to detect whether the user is in a plugin project or not. If he is, then it prints a warning that the *GrailsPlugin.groovy file should be updated manually.
Ryan Vanderwerf says:
Added on June 24th, 2010 at 5:05 pm

I installed 1.3.1, and now the DSL for plugin works! Although I get random errors on not finding plugins every few times I run any command on the project in grails. I think thats a documented JIRA.

I think I found the bug why I can't publish, the maven plugin does not seem to pass the credentials to Artifcatory:

from request logs of artifactory:

20100624165113|0|REQUEST|192.168.168.65|non_authenticated_user|PUT|/plugins-releases-local/org/grails/plugins/mdp-core/0.2/mdp-core-0.2.zip|HTTP/1.1|401|188205

Even though I have my credentials set:

grails.project.dependency.distribution = {
remoteRepository(id: "pluginReleases", url: "http://hudson.blah.com:8080/artifactory/plugins-releases-local/") {
authentication username: "admin", password:'something'
}
}

I tried embedding them into the url like http://admin:something@hudson…. but that doesn't work either. It does seem to be using HTTP rather than webdav to do the publishing.
oriental says:
Added on June 28th, 2010 at 9:58 pm

I have a question when I use the artifactory to manage the lib and plugins.
the details is as flows:
1.I download the artifactory, then do some configures，and execute the command "service artifactory start"
2.I write a test plugin named "grails-hello-plugin-0.1.zip"
download a mysql driver jar named "mysql-connector-java-5.1.6-bin.jar"
Now test begins.
1>lib(jar) test
I use the artifactory manage page to upload the "mysql-connector-java-5.1.6-bin.jar".before deploy the Atifact—-Step 2: Edit Artifact Details,there is a Classifier configure, and the value is "bin".

In my BuildConfig.groovy file,I add
mavenRepo "http://localhost:8081/artifactory/libs-releases-local/"
dependencies {
compile "mysql-connector-java:mysql-connector-java:5.1.6"
}
oriental says:
Added on June 28th, 2010 at 10:47 pm

I have a question with useing the artifactory to manage the libs and plugins.
the details is as flows:
1.I start my local artifactory with the "service artifactory start".
2.I write a plugin named "grails-hello-plugin-0.1.zip"
download the mysql driver "mysql-connector-java-5.1.6-bin.jar"
Now test begins.
1>test the lib.
select the "mysql-connector-java-5.1.6-bin.jar" file, and click Upload.
Step 2: Edit Artifact Details,there is a "Classifier" configure, and the
default value is "bin"
In my BuildConfig.groovy file, I add some code as flows:

mavenRepo "http://localhost:8081/artifactory/libs-releases-local/"
dependencies {
compile "mysql-connector-java:mysql-connector-java:5.1.6"
}
grails run-app
…..
:: problems summary ::
:::: WARNINGS
http://localhost:8081/artifactory/libs-releases-local/mysql-connector-java/mysql-connector-java/5.1.6/mysql-connector-java-5.1.6.jar
the "mysql-connector-java-5.1.6.jar" is not the "mysql-connector-java-5.1.6-bin.jar"
so I to the Step 2: Edit Artifact Details, I change the "Classifier" value, remove the "bin".
grails run-app:
Ok:http://localhost:8081/artifactory/libs-releases-local/mysql-connector-java/mysql-connector-java/5.1.6/mysql-connector-java-5.1.6.jar
The "Classifier" can not works?

2>test the plugins
select the "grails-hello-plugin-0.1.zip" file,and click Upload.
Steo 2:Edit Artifact Details,there is a "Classifier" keep nothing.
In my BuildConfig.groovy file, I add some code as flows:
mavenRepo "http://localhost:8081/artifactory/plugins-releases-local/"

plugins {
build "grails-hello-plugin:grails-hello-plugin:0.1"
}
grails run-app
…..
:: problems summary ::
:::: WARNINGS
http://localhost:8081/artifactory/plugins-releases-local/grails-hello-plugin/grails-hello-plugin/0.1/grails-hello-plugin-0.1.jar.zip

"grails-hello-plugin-0.1.jar.zip", Why not is the "grails-hello-plugin-0.1.zip"
who can give me some idea?
Peter Ledbrook (blog author) says:
Added on June 29th, 2010 at 5:32 am

@oriental Classifiers are not currently supported by the string-based dependency syntax. You can use the map-based syntax instead:

dependencies {
compile group: "mysql-connector-java", name: "mysql-connector-java", version: "5.1.6", classifier: "bin"
}

Your second issue is due to a bug introduced in Grails 1.3.2, so you will have to use 1.3.1 for now. Also, have you specified a group ID in your plugin? If not, then you should use a dependency of

plugins {
build ":grails-hello-plugin:0.1"
}

i.e. remove the group from the dependency.
oriental says:
Added on June 29th, 2010 at 3:46 pm

Have you specified a group ID in your plugin?
Yes, I tried.
I changed the group Id to "oriental" and changed artifact Id to "hello-plugin", and the result was "hello-plugin.0.1.jar.zip". Does I have to change the grails version to 1.3.1?
As you said, if I don not specify a group ID, and just use
plugins {
build ":grails-hello-plugin:0.1"
}
Will it works? I will have a try. Thanks a lot.
Peter Ledbrook (blog author) says:
Added on June 30th, 2010 at 11:54 am

@oriental Yes, the "hello-plugin.0.1.jar.zip" is a symptom of the Grails 1.3.2 issue. Try with 1.3.1.
Peter Ledbrook (blog author) says:
Added on July 8th, 2010 at 8:58 am

Grails 1.3.3 has now been released, which fixes the bug with plugin dependencies.
Amit says:
Added on April 6th, 2011 at 9:53 am

Hi Peter

Thanks for a great post, I hope i'm not too late with writing a response.

Well, it seems to me to be working quite buggy still on 1.3.7

I have followed all steps and got authentication problems, even with full admin permissions to anonymous user.

requests.log says:

20110406164234|4|REQUEST|127.0.0.1|non_authenticated_user|PUT|/plugins-snapshots-local/org/grails/plugins/myPlugin-0.1.zip|HTTP/1.1|405|3261283

while messing around i got also a 409 what seems like a progress but I just couldn't get further. I've read completely your discussion here with Ryan, and tried ofcourse everything mentioned there.

Thanks
Ryan V says:
Added on April 6th, 2011 at 10:35 am

Check that you didn't publish that version already. You have to make a new build number each time you publish – you can't just overwrite the old one, it will get a 405 error. Even if you could, you wouldn't want to: the clients check for a new version, and if it's not new, it won't download it. For plugins, I just add a method call to the buildNumber attribute, that does the dynamic stuff like so:

def version = getBuildNumber()

private String getBuildNumber() {

return someNewBuildNumber
}

If you use hudson it's easy to pass in the build number as an environment variable and use it from there.
Amit says:
Added on April 6th, 2011 at 11:06 am

@Ryan: Hi, Thanks for your reply (;

well… I don't think thats the case, since over the UI i can't find any memory for my plugin, so im pretty much positive that wasent deployed even once. However the trick with the versioning is a nice one, i'll use it!

The point where it all fails, so i beleive, is that Artifactory doens't recieve any authentication, a thing which i couldn't reproduce using CURL or some other hacks.

I just increased the version number manually and did a new maven-deploy on the plugin project, sniffing with Wireshark i got the following response from Artifactory, which i already put on a server:

HTTP/1.1 409 The repository 'plugins-snapshot-local' rejected the artifact 'plugins-snapshot-local:org/grails/plugins/myPlugin/0.2.43/myPlugin-0.2.43.zip' due to its snapshot/release handling policy.

Server: Artifactory/2.3.2

Content-Length: 0

any idea?
Peter Ledbrook (blog author) says:
Added on April 8th, 2011 at 8:03 am

Amit: I take that you're having problems deploying your plugins to Artifactory? If so, this is a function of the Maven Publisher plugin rather than Grails.

The 409 occurs if you attempt to deploy a non snapshot version of an artifact to a snapshot repository. In the above case, you are attempting to deploy 0.2.43 to 'plugins-snapshot-local'. The 409 error will disappear if you _either_ change the version number to 0.2.43-SNAPSHOT _or_ change the repository to 'plugins-releases-local'.

The 405 means "Method Not Allowed", i.e. the URL does not support the HTTP method (PUT in your first example). Perhaps because the name of the repository is wrong? I notice that your first comment includes 'plugins-snapshots-local' but the second refers to 'plugins-snapshot-local' (notice the pluralisation of 'snapshot' in the first).

Hope that helps,

Peter
Brian Folse says:
Added on April 25th, 2011 at 4:49 pm

I think I may have stumbled across a bug in Grails plugin dependency management with grails.project.dependency.resolution in BuildConfig.groovy.

We have a Grails app (our-app) and we have something like this in our Grails app BuildConfig.groovy:

plugins {
runtime "org.grails.plugins:our-plugin:1.1"
}

We run grails run-app or grails war and it picks up the plugin dependency like we expect. The problem comes when we move to a new version of the plugin:

plugins {
runtime "org.grails.plugins:our-plugin:1.2"
}

Now when we do grails run-app or grails war, it still picks up the 1.1 version. We look in the .grails/1.3.6/projects/our-app/plugins and still see our-plugin-1.1. We can work around this by removing this directory prior to running grails run-app or grails war, but it seems like something that Grails should be handling.

I did a quick search of the Issue Tracker but didn't see anything about this. Let me know if you'd like me to submit a new defect.

Thanks,
Brian
Peter Ledbrook (blog author) says:
Added on April 26th, 2011 at 3:45 am

@Brian I can't reproduce with a simple example and the Hibernate plugin, so if you have a reproducible example then do please raise an issue with it attached. Thanks.
Brian Folse says:
Added on April 26th, 2011 at 4:33 pm

@Peter OK, here it is… http://jira.grails.org/browse/GRAILS-7474
Peter Ledbrook (blog author) says:
Added on April 27th, 2011 at 4:47 am

Thanks Brian. I hadn't tested with snapshot versions, hence why I couldn't reproduce.
Nick Martin says:
Added on April 29th, 2011 at 7:24 pm

Is there a way to externalize the remoteRepository config that is stored in BuildConfig.groovy? It would also be nice to externalize this configuration info because if, for example, my repository's url were to change, then I could change it in just one external config file instead of inside every plugin that uses the repository. In addition, I don't like to check passwords into version control.

Plus, copying the same boilerplate remoteRepository into every plugin's BuildConfig doesn't seem very DRY.

As far as I can tell, BuildConfig.groovy doesn't have easy access to the vars defined in Config.groovy and it doesn't have an easy, general purpose external config option like Config.groovy.

Is there some way around this?
Peter Ledbrook (blog author) says:
Added on May 1st, 2011 at 5:44 am

@Nick: support for putting remote repository and plugin portal settings into your '~/.grails/settings.groovy' file was added to version 0.8 of the Maven Publisher plugin. You can find more information on the GitHub page for the plugin – check out the section titled "New to 0.8".

Note that this plugin will be re-released as the Release plugin before Grails 1.4 is out. In fact, 1.0.0.BUILD-SNAPSHOT can already be installed, but I suggest waiting for the M1 release before using it.
Nick Martin says:
Added on May 5th, 2011 at 11:48 am

@Peter,
Thanks for your quick reply. This is exactly the type of mechanism I was hoping existed.

FYI, I did get the settings.groovy file to work, but it was a little different than the Publisher plugin's GitHub page explained. I couldn't figure out a way to get the properties-file style approach to work. It just seemed to be ignored. When I copied the closure as-is from the BuildConfig.groovy into the settings.groovy, though, it did work.

Working example of settings.groovy:

grails.project.dependency.distribution = {

// used for distributing the plugin to Artifactory
remoteRepository(id: "pluginSnapshots", url: "http://myurl:8081/artifactory/plugins-snapshot-local/") {
authentication username: "admin", password: "mypassword"
}
}
Peter Ledbrook (blog author) says:
Added on May 5th, 2011 at 12:09 pm

@Nick The 1.0.0.M1 version of the Release plugin is now available. The standard property notation should work fine, so I wonder whether you had a "grails.project.dependency.distribution" setting in your BuildConfig.groovy. In that case, the BuildConfig option would take have taken precedence.

In other words, you should either use grails.project.repos.* settings or grails.project.dependency.distribution, but not both. Hope that helps.
Andry says:
Added on October 5th, 2011 at 9:15 am

Hi I have a problem with a SVN repo server certificate over HTTPS:

Server access Error: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target url=https://sabrina/svn/GrailsPlugins/org/grails/plugins/grails-testing-repo/0.1/grails-testing-repo-0.1.pom

Server access Error: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target url=https://sabrina/svn/GrailsPlugins/org/grails/plugins/grails-testing-repo/0.1/grails-testing-repo-0.1.zip

Any Help…
Thanks
A
Kimberley Scott says:
Added on November 8th, 2011 at 2:27 am

Andry, pretty sure you need to get the certificate for your svn site in CER form and pop it into your JREs security folder. Can't remember the exact path.
I had a similar problem accessing Redmine from inside IntelliJ.

2 trackbacks

View all pings & trackbacks

Search

Authors

Categories

Websites

Archives