@nacx I looked into the tag api documentation and I think, it does **not** fit the jclouds semantic. In jclouds, those are `Map<String,String>`, but in DigitalOcean they have Map<String,Object> where Object is currently always a droplet. (Most likely, it's an Integer-Id, just like with their key API).
I'm going to change make the proposed change in the PR, but while we are here: The private Json member is not needed anymore, but I did not remove it, because I am not shure about the implications of changing the signature of the constructor in line 75. Perhaps **you** can comment on that. Also, Just out of curiosity: The others (meaning: at least openstack-nova and aws-ec2) have a completely different API in jclouds: They implement a separate method in their TemplateOptions specializations: [userData(byte[] userData)](https://jclouds.apache.org/reference/javadoc/1.9.x/org/jclouds/openstack/nova/v2_0/compute/options/NovaTemplateOptions.html#userData(byte[])). So: why is it that the digitaloceans2 provider follows a different approach here? Resulting code in the jenkins plugin: ```java if (!isNullOrEmpty(userData)) { try { if (options instanceof DigitalOcean2TemplateOptions) { options.userMetadata("user_data", userData); } else { Method userDataMethod = options.getClass().getMethod("userData", new byte[0].getClass()); LOGGER.finest("Setting userData to " + userData); userDataMethod.invoke(options, userData.getBytes(StandardCharsets.UTF_8)); } } catch (Exception e) { LOGGER.log(Level.WARNING, "userData is not supported by provider options class " + options.getClass().getName(), e); } } ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/1042#issuecomment-263070203
