Yesterday Amazon EC2 suffered another outage. More precisely in the East coast datacenter where the Griffon Artifact Portal is hosted. Unfortunately for us this meant the portal was unavailable for some hours. However on the up side only a small number of Griffon developers even noticed (we received a single message on the mailing list). The reason why so few were affected is found in the scheme for handling artifacts, added back in Griffon 0.9.5
In the past we relied on HTTP+SVN to resolve plugins at every time. This meant things went well as long as there was a reliable network connection. When the network was down so was Griffon for all purposes. We also had trouble accepting plugin contributions as SVN is not very social nor did we desired to open up SVN access with a generic user or some other scheme. These ailments plus some other more made us reach the conclusion that a full redesign of the plugin system was needed. And that's precisely what we did.
There are 3 types of artifact repositories under the new scheme: local, remote and legacy. The last one points to the old HTTP+SVN repository (in read-only now) where plugins used to be hosted. We're keeping it alive for a while as not all plugins have been migrated from legacy to new codebase (there are less than 10 if case you're interested to know). The second type is the one that currently serves plugins at http://artifacts.griffon-framework.org. This leaves the local type, which is the secret sauce that avoided lots of headaches for many. Every time a plugin is downloaded from the legacy or remote repositories you get a copy of the release metadata. This metadata plus the plugin itself are uploaded to the local repository. The next time the plugin needs to be resolved the local repository answers first, thus incurring in no penalty for network access as everything is resolved within the same file system.
All of the plugin related commands are aware of the different types of repositories and those configured for a particular environment. Simply type griffon list-repositories in case you'd like to see a list of all currently available repositories in your system.Here's what I get when running the command with default settings:
Local repositories require nothing more than a name and a path in their configuration. Say you'd want to create a second local repository named test, this is what you'd have to place in $USER_HOME/.griffon/settings.groovy to configure such repository
Running list-repositories once more results in
Alright, so the new repository will get asked second whenever plugins need to be resolved. You may be asking, how can I make the new repository be the default one for searching, storing and even publishing. We got you covered. The Griffon Guide describes all the options available at your disposal:
Cool, eh?
Though local repositories greatly reduce the number of times the griffon command line access the network when querying plugins it may still attempt to connect to outside servers when resolving JAR dependencies. If you're pretty certain all dependencies are already available in your local Ivy cache, or if you just want to disable checking for snapshot releases on every single dependency repository configured in BuildConfig.groovy then instruct Griffon to run in offline mode, like this
No remote repository nor the legacy one will be queried as an added benefit of offline mode being active, only local repositories will be able to resolve artifacts. I set this flag all the time I'm on the train or an airplane (which happens more frequently than I would expect). This flag can even be placed inside $USER_HOME/.griffon/settings.groovy, turning Griffon into offline mode for every project until the flag gets disabled. Awesome.
Keep on Groovying!
