trouble processing "javax/xml/parsers/DocumentBuilder.class":

[xbeta]

I tried to follow the example and build a HelloWorld Android project first, but it fails with the following error when running gradle assemble

build.gradle :

buildscript {
  repositories {
    mavenCentral()
  }
  dependencies {
    //classpath 'org.gradle.api.plugins:gradle-android-plugin:1.2.1'
    classpath files('/Users/xbeta/workspace/gradle-android-plugin/build/libs/gradle-android-plugin-1.2.2-SNAPSHOT.jar')
  }
}
apply plugin: 'android'
apply plugin: 'eclipse'

repositories {
  mavenCentral()
  mavenRepo(url: new File(System.properties['user.home'], '.m2/repository').toURI().toURL())
}

dependencies {
  compile 'com.google.android:android:4.1.1.4'
}

// Configure the filtering of resources with properties from the Gradle's project scope (2)
processResources {
  expand (project.properties)
}

// Configure a dedicated debug build (3)
task configureDebug << {
  jar.classifier = "debug"
}

// Configure a dedicated release build (4)
task configureRelease << {
  proguard.enabled = true
}

Error log

ant:apply] warning: Ignoring InnerClasses attribute for an anonymous inner class
[ant:apply] (org.apache.commons.logging.LogFactory$5) that doesn't come with an
[ant:apply] associated EnclosingMethod attribute. This class was probably produced by a
[ant:apply] compiler that did not target the modern .class file format. The recommended
[ant:apply] solution is to recompile the class from source, using an up-to-date compiler
[ant:apply] and without specifying any "-target" type options. The consequence of ignoring
[ant:apply] this warning is that reflective operations on this class will incorrectly
[ant:apply] indicate that it is *not* an inner class.
[ant:apply] warning: Ignoring InnerClasses attribute for an anonymous inner class
[ant:apply] (org.apache.commons.logging.LogFactory$6) that doesn't come with an
[ant:apply] associated EnclosingMethod attribute. This class was probably produced by a
[ant:apply] compiler that did not target the modern .class file format. The recommended
[ant:apply] solution is to recompile the class from source, using an up-to-date compiler
[ant:apply] and without specifying any "-target" type options. The consequence of ignoring
[ant:apply] this warning is that reflective operations on this class will incorrectly
[ant:apply] indicate that it is *not* an inner class.
[ant:apply]
[ant:apply] trouble processing "javax/xml/parsers/DocumentBuilder.class":
[ant:apply]
[ant:apply] Ill-advised or mistaken usage of a core class (java.* or javax.*)
[ant:apply] when not building a core library.
[ant:apply]
[ant:apply] This is often due to inadvertently including a core library file
[ant:apply] in your application's project, when using an IDE (such as
[ant:apply] Eclipse). If you are sure you're not intentionally defining a
[ant:apply] core class, then this is the most likely explanation of what's
[ant:apply] going on.
[ant:apply]
[ant:apply] However, you might actually be trying to define a class in a core
[ant:apply] namespace, the source of which you may have taken, for example,
[ant:apply] from a non-Android virtual machine project. This will most
[ant:apply] assuredly not work. At a minimum, it jeopardizes the
[ant:apply] compatibility of your app with future versions of the platform.
[ant:apply] It is also often of questionable legality.
[ant:apply]
[ant:apply] If you really intend to build a core library -- which is only
[ant:apply] appropriate as part of creating a full virtual machine
[ant:apply] distribution, as opposed to compiling an application -- then use
[ant:apply] the "--core-library" option to suppress this error message.
[ant:apply]
[ant:apply] If you go ahead and use "--core-library" but are in fact
[ant:apply] building an application, then be forewarned that your application
[ant:apply] will still fail to build or run, at some point. Please be
[ant:apply] prepared for angry customers who find, for example, that your
[ant:apply] application ceases to function once they upgrade their operating
[ant:apply] system. You will be to blame for this problem.
[ant:apply]
[ant:apply] If you are legitimately using some code that happens to be in a
[ant:apply] core package, then the easiest safe alternative you have is to
[ant:apply] repackage that code. That is, move the classes in question into
[ant:apply] your own package namespace. This means that they will never be in
[ant:apply] conflict with core system classes. JarJar is a tool that may help
[ant:apply] you in this endeavor. If you find that you cannot do this, then
[ant:apply] that is an indication that the path you are on will ultimately
[ant:apply] lead to pain, suffering, grief, and lamentation.
[ant:apply]
[ant:apply] 1 error; aborting
:androidPackage FAILED