1.) Number of command objects drastically reduced (see https://github.com/powertac-plugins/powertac-common/tree/master/src/groovy/org/powertac/common/command)
For most of our use cases we can use the domain (i.e. database) objects directly, only for incoming requests from brokers (e.g. TariffDoPublish, ShoutDoRevoke) command objects make sense. And exactly these objects are defined. Also these objects now use spring validation framework to ensure object properties to be well defined.
2.) Interace definitions revised (see https://github.com/powertac-plugins/powertac-common/tree/master/src/java/org/powertac/common/interfaces)
The methods now use the database objects directly (before they were provided with database ID references). The new approach is performant as well as grails uses lazy object loading (i.e. a database object is only (transparently) loaded from db once one of its properties is directly accessed. The revised interface definitions make the realization of the different PowerTAC plugins (e.g. customers) even easier.
3.) Throwable declarations added
(Almost) all interface methods now come with throwable declarations, where each throwable inherits from PowerTacException in order to enable centralized exception management (this will be part of the server's job. You just have to through exceptions whenever something goes wrong in your plugin :)
To use the new powertac-common plugin in your own plugin development you have to upgrade the plugin:
1.) On the command line: grails install-plugin powertac-common (you'll be asked if you really want to update the plugin
2.) In you /plugin/root/directory: Update your PowertacXxxPlugin.groovy -> def dependsOn = ["powertacCommon":"0.3"]
...one more thing: John is currently looking into the technical Tariff model. This is the only part of the plugin where major revisions seem possibly. The rest of the plugin's code is rather mature already.
@John: Coming back to our discussion from last week. I ultimately didn't join the methods defined for a customer. We can call all of them each hour (if we find that reasonable) but each method is addressing a different "business need" I would prefer to see plugins that separate their logic accordingly. Having these methods separately encourages this "separated" design.