Grails dependency hell

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Grails dependency hell

grampajohn
Administrator
I have two plugins, powertac-common and powertac-server-interface. For development, we use an "inline" dependency to say that powertac-server-interface depends on powertac-common. This is expressed in powertac-server-interface through a line in BuildConfig.groovy like
grails.plugin.location.PowertacCommon = "../powertac-common"
In addition, both powertac-common and powertac-server-interface have the joda-time plugin installed.

Now I want to publish these plugins to a maven repository. I have successfully published powertac-common. I then removed the inline dependency of powertac-server-interface on powertac-common and attempted to install the published powertac-common plugin using grails install-plugin. The powertac-common plugin is found, but the install fails because (apparently) of the dependency of powertac-common on joda-time. For some reason, the install process is looking in a number of places for joda-time-1.1.zip. Many of those places contain joda-time-1.1.jar, but apparently that is not acceptable.

I'm stuck on this; it's keeping me from getting a release out. Does anyone know how this is supposed to work?

Thanks.

John
Reply | Threaded
Open this post in threaded view
|

Re: Grails dependency hell

grampajohn
Administrator
After most of another day, I have found the answer to this problem. When you build a plugin, it keeps a cache in ~/.grails/1.3.7/projects. Apparently something in that cache is different when building with local vs. remote dependencies, and when you switch from local to remote it blows up. The solution is to blow away the cache when switching from development mode to packaging/production mode. I have updated the packaging process description to include this workaround.

Nowhere is this documented that I can see, and I think it's a bug in grails.

John
Reply | Threaded
Open this post in threaded view
|

Re: Grails dependency hell

Wolf
Administrator
Great! Congrats on finding this nasty bug! Now we can proceed with the 0.3 release. 

Thanks much,

Wolf

Sent from my iPhone

On Jun 10, 2011, at 18:05, "grampajohn [via Power TAC Developers]" <[hidden email]> wrote:

After most of another day, I have found the answer to this problem. When you build a plugin, it keeps a cache in ~/.grails/1.3.7/projects. Apparently something in that cache is different when building with local vs. remote dependencies, and when you switch from local to remote it blows up. The solution is to blow away the cache when switching from development mode to packaging/production mode. I have updated the packaging process description to include this workaround.

Nowhere is this documented that I can see, and I think it's a bug in grails.

John


If you reply to this email, your message will be added to the discussion below:
http://power-tac-developers.975333.n3.nabble.com/Grails-dependency-hell-tp3042453p3049466.html
To start a new topic under Power TAC Developers, email [hidden email]
To unsubscribe from Power TAC Developers, click here.


Disclaimer
De informatie verzonden in dit e-mail bericht inclusief de bijlage(n) is vertrouwelijk en is uitsluitend bestemd voor de geadresseerde van dit bericht. Lees verder: http://www.eur.nl/email-disclaimer.

The information in this e-mail message is confidential and may be legally privileged. Read more: http://www.eur.nl/english/email-disclaimer.

Reply | Threaded
Open this post in threaded view
|

Re: Grails dependency hell

grampajohn
Administrator
Wolf wrote
Great! Congrats on finding this nasty bug! Now we can proceed with the 0.3 release.
I think congratulations are premature. First, I cannot find a way to get the end-products (broker and server) to resolve plugins correctly. Second, I am now trying to package powertac-visualizer, and it cannot resolve its plugins, even after going through all the steps I thought were working. I have now gotten about halfway through preparing this release in about a week, and I'm starting to think I've been wasting my time - time that could have been more profitably spent on other problems. Worse, if we give up on the plugin-packaging process, I now have to go back through all the release-0.3 packages I've already done and change them back to local dependencies.

Unless someone else will volunteer to finish up this packaging process, I am going to toss it over the side so we can at least make a release. If I don't hear from someone by the end of Monday 13 June, then the plugin packaging will not happen.

John