As discussed IRL with Wannes, there is no need to build the key. I was better off using the second ToolLocationNodeProperty.ToolLocation constructor, which doesn't need the key but the ToolDescriptor (of which I have an instance at hand)
Op donderdag 9 oktober 2014 13:53:31 UTC+2 schreef Wannes Sels: > > Jenkins.getInstance().getExtensionList(hudson.tools.ToolDescriptor.class) > should do the trick > > On Thursday, October 9, 2014 1:32:09 PM UTC+2, Nico Mommaerts wrote: >> >> Hey, >> >> recently I've added support to the swarm plugin to specifiy >> toollocations. To add ToolLocation to a slave you have to create a >> ToolLocationNodeProperty.ToolLocation. Its constructor takes a key and a >> location. >> I didn't/don't know how to get to that key so I reverse engineered by >> querying the keys from an existing slave. From that info I came to the >> following method of determining a key: >> >> ToolInstallation inst; >> >> String key = inst.getClass().getCanonicalName().toString() + >> "$DescriptorImpl@" + inst.getName(); >> >> This seemed to work but today I found it doesn't for all tools. >> For example, the Maven key should be >> >> hudson.tasks.Maven$MavenInstallation$DescriptorImpl@ >> >> but using my method I get >> >> hudson.tasks.Maven.MavenInstallation$DescriptorImpl@ >> >> For other tools like Groovy and Gradle my way worked because there is no >> extra $ in the name. >> >> Is there a better, 'official' way to get the correct key for a >> ToolInstallation? >> >> -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
