Node.toString isn't an exact representation of what is saved. Under the covers, each dsl method and configure method just queue's up the closures that need to be run to generate the xml. They are then played back once the whole DSL has been run through. This all happens in Job.getXml(), so you'll want to call that to see exactly is going to be saved. Though you can also turn up the logging in Jenkins to see the output right before it is saved. It's logged at the FINE level from javaposse.jobdsl.dsl.DslScriptLoader. If you want direct access to the node, you run executeWithXmlActions(project), that's what we use in the unit tests heavily
Now, concerning your example, I like how you're calling a utility method inside the job block. I don't see any reason why it wouldn't work. I hope don't mind but I added a unit test to the code base to check for this: https://github.com/jenkinsci/job-dsl-plugin/commit/88e6d1e74e2c172231c7e5292735708b7da31c92 The structure maps to what I would think you're creating. I'm not familiar with the Violation Publisher plugin. Maybe you could send the job-dsl-plugin google group what you think the XML should be. Take a look at the unit test above, does it fit with what you're trying to do? (BTW, the job-dsl-plugin has its own google group. But I'll make sure to monitor this one too now) On Thursday, January 10, 2013 12:13:07 PM UTC-8, Mike Dougherty wrote: > > I have the following script: > > public class DSLHelpers { > public static void violations(out, job, typeName, minNum, maxNum, > unstableNum, filenamePattern = null) { > job.configure { project -> > def violationsConfig = project / publishers / > 'hudson.plugins.violations.ViolationsPublisher' / 'config' > > * /* these are the lines relevant to the discussion */* > * def typeConfigsNode = violationsConfig / typeConfigs* > * def typeEntry = typeConfigsNode / entry* > * /* --- */* > > typeEntry / string(typeName) > def typeConfig = typeEntry / > 'hudson.plugins.violations.TypeConfig' > typeConfig / type(typeName) > typeConfig / min(minNum) > typeConfig / max(maxNum) > typeConfig / unstable(unstableNum) > typeConfig / usePattern(filenamePattern ? "true" : "false") > typeConfig / pattern(filenamePattern) > // out << project > } > } > } > > job { > name "Tools-jshint-dsl" > DSLHelpers.violations(out, delegate, "jslint", 10, 11, 10, > "test-reports/*.xml") > } > > Running a job with this DSL script succeeds and has the following output: > > Existing Templates: > New Templates: > Unreferenced Templates: > Adding jobs: > Existing jobs: GeneratedJob{jobName='Tools-jshint-dsl', templateName=none} > Removing jobs: > Finished: SUCCESS > > > However, the /job/Tools-jshint-dsl 404's and there's nothing on the > filesystem in ~jenkins/jobs/ either. > > Here's the tricky part though: removing the 'typeConfigs' node and making > typeEntry > = violationsConfig / entry results in success *and* the expected > generated job. Using a different name ('foo') in place of typeConfigs also > results in the expected XML (.//config/foo/entry), and placing a > 'typeConfigs' node elsewhere in the document hierarchy also results in > invalid XML. (Of course, all of these yield an incorrect document, they're > merely test cases to figure out what the heck is going on). > > When the document is written to stdout (using, I assume, Node.toString()), > typeConfigs does appear, so it's would appear that it's correctly added to > the Node object. It's possible there's something wrong with Node's > serialization but that seems unlikely. > > All of this leads me to believe that there's something incompatible with > an XML node named 'typeConfigs' when being used with Job-DSL. > > Does anyone have any ideas about what the cause may be, or any suggestions > as to what else I might investigate? > >
