I have updated the PR https://github.com/jclouds/jclouds-labs-openstack/pull/139
Thanks for the help! ________________________________________ From: Andrew Phillips [aphill...@qrmedia.com] Sent: Monday, September 08, 2014 8:54 AM To: dev@jclouds.apache.org Subject: RE: Using *Options for domain objects? > I was mostly thinking about what method and class names users see > when they use jclouds apis - we have Options a lot, we have Builders > as well. Well, I think since we're talking here about builders that create domain objects , rather than builders which create options in the current jclouds sense of modifying a call, I would say: createBuilder() // convenience method -> CreateBuilder // Builder class -> CreateObject // domain object and similarly for update. Admittedly, this doesn't take into account Everett's point about these really being method options that happen to inherit from domain objects for convenience (I hope I'm paraphrasing that correctly). If we prefer that slant, I would go for something like: createBuilder() // convenience method -> CreateBuilder // Builder class -> CreateParams or CreateSpec // method args But *Params also isn't ideal because we already have *Params objects in jclouds, and they're something slightly different. We *also* have a *Spec class [2], which seems to come a little closer to the intention here. ap [1] https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/rest/annotations/FormParams.java [2] https://github.com/jclouds/jclouds/blob/master/providers/glesys/src/main/java/org/jclouds/glesys/domain/ServerSpec.java
