The Griffon Trove: troubleshooting plugin upgrades

Posted by: Andres Almiray on 06/11/2012

Now that Griffon 1.0.0 is available there may be some people experiencing upgrade problems. Say you have an existing Griffon application created with 0.9.5; this application has several plugins installed, some of them have a dependency on swing-0.9.5. All goes well when upgrading this application to Griffon 1.0.0 but any further commands make it fail with an error similar to the following one
What's going on here? The answer lies in stricter upgrade policies enforced since 0.9.5 when the plugin system was redesigned. Previous to 0.9.5 you could upgrade to a newer version in a very "careless" way, that is, just pick the latest number and do it. However this could to unexpected problems if there's a binary incompatibility lurking in the release. Because of this the team decided to enforce the following rules when resolving plugin version

  • split version numbers into major.minor.revision
  • if major number differs then abort
  • if minor number differs, pick the bigger one
  • if revision number differs, pick the bigger one
  • tags should be treated in descending alphabetic order with the exception of -SNAPSHOT which is always last
With these rules we see that miglayout depends on swing 0.9.5 but the application has a dependency on swing 1.0.0. This is treated as a binary incompatible upgrade so the build stops immediately and informs you of the conflict. How do we solve the conflict then? Simply read through the release notes and plugin docs available at Griffon Artifact Portal and check for yourself that the migration path is safe. When convinced issue any griffon command, such as clean for example, with the following flag enabled
This flag will the build to accept plugin upgrades even if there are differences in major numbers.

By the way, in case you're curious about the character ! next to each plugin name/version it means there's a conflict in that plugin or any of its dependencies. Additional characters may be present (one per line)

  • . the plugin is installed
  • + the plugin will be installed
  • - the plugin will be removed
  • ? the plugin could not be resolved
For example, adding a plugin dependency on bogus-0.0.0 results in the following output

Keep on Groovying!


About Andres Almiray

Andres Almiray

Andres is a Java/Groovy developer and Java Champion, with more than 13 years of experience in software design and development. He has been involved in web and desktop application developments since the early days of Java. He has also been teacher of computer science courses in the most prestigious education institute in Mexico. His current interests include Groovy and Swing. He is a true believer of open source and has participated in popular projects like Groovy, Griffon, JMatter and DbUnit, as well as starting his own projects (Json-lib, EZMorph, GraphicsBuilder, JideBuilder). Founding member and current project lead of the Griffon framework. He blogs periodically at http://jroller.com/aalmiray. You can find him on twitter too as @aalmiray. He likes to spend time with his beloved wife, Ixchel, when not hacking around.

More About Andres »

NFJS, the Magazine

May Issue Now Available
  • On the road to learning

    by Raju Gandhi
  • Refactoring to Modularity

    by Kirk Knoernschild
  • RESTful Groovy

    by Kenneth Kousen
  • Getting Started with D3.js

    by Brian Sletten
Learn More »