I wanted to use org.jdom2.contrib.dom.DOM.wrap as mentioned in an answer to the question Is there any org.w3c.dom wrapper for JDom? on stackoverflow. For that, I required a jar file. I added a (gradle)[http://www.gradle.org/] build file to enable creating a jar (gradle jar) and uploading it to the local maven repository (gradle install). I did not add the Gradle Wrapper, so gradle binaries are required.
Adds support for gradle as build tool for contrib part
Gradle is new to me, so bear with me....
Specifying versions like you have in this config file concern me. I don't want to have additional places where version numbers are set.... the build.xml and build.properties are too many places already.
Also, the versions are not necessarily accurate. Java code versions should be 1.6 but target should be 1.5. What does the 2.0.0 mean?
I am also sceptical about adding content to the contrib folder that need continuous maintenance. Frankly, I would rather bring the DOM wrapper in to the main JDOM core code than add maintenance items in contrib.
Reading wikipedia indicates that Gradle can be used to wrap ant build files. What value does adding Gradle to JDOM add (from JDOM's perspective)? Is there a better way to get that advantage? Can JDOM become different in some other way that would allow you to do your work without having to modify JDOM's build process?
Bottom line.... I am very skeptical about adding a new layer of build process to JDOM.
Instead of offering a solution, can you instead try to describe your problem more completely, and maybe there's a different solution.
You're absolutely right regarding the additional overhead. I thought jdom.contrib would be some kind of a separate project without tight relation to JDOM, even if hosted in the same repository.
For me, just moving the DOM wrapper into the main JDOM core would solve my problem.
Accepting the merge of pull request 105 would also help.